Extension talk:WikiScripts

It would be so nice if extension authors would put up a summary that told us something more than the title of the extension, and if they would take the time to put an actual example in place.

Keywords in and contains.

These are important and I think you should add definitions and maybe examples. Also, is there a way to remove a key/value pair from an array?

--AJim 22:10, 17 August 2011 (UTC)

Yes, delete( a['key'] ). I'll add that. VasilievVV 22:11, 17 August 2011 (UTC)

numeric functions

I think there have to be at least a few numeric functions defined. Perhaps floor, ceil, round, sign, abs at least. If the underlying language supports them then also log, exp, sqrt maybe max and min maybe rand and maybe even trig? Or do we just assume that if they are in js then they are here? --AJim 22:56, 17 August 2011 (UTC)

Coming soon. VasilievVV 15:46, 18 August 2011 (UTC)

date/time datatype and functions

I think there will be a need for date/time operations and I think it would be a mistake not to have them well-defined, paricularly in light of how much pain they have caused me in the past. --AJim 22:55, 17 August 2011 (UTC)

I will add datetime type when the date/time functions are added. This is not high priority issue however, so I will probably focus on that later. VasilievVV 15:46, 18 August 2011 (UTC)

short-circuit evaluation

I assume that logical evaluation (& |) short circuits, but it would be nice if the description said so. --AJim 22:59, 17 August 2011 (UTC)

escaping a for construct

Is there a way to terminate a for evaluation if the program discovers that it should not go on? --AJim 23:07, 17 August 2011 (UTC)

Added break/continue into documentation. VasilievVV 15:46, 18 August 2011 (UTC)

Named parameters

One thing I like about MediaWiki templates relative to real programming languages is that you can use named parameters very easily, and therefore that you don't have a fixed order of the parameters. It looks to me like it will be a pain to implement something like {{Cite web }} fully in the current version of this extension, because you really need the flexibility of named parameters. I suppose this problem could be solved by making Template:Cite web into a wrapper that calls Module:Cite web with all the parameters in the right order, but that's ugly. Ucucha 00:45, 18 August 2011 (UTC)

Well, as for templates, if you #invoke a function from template, the function (as well as all the other functions it calls) have access to the parser frame of the template, i.e. to all the arguments in it. See "Template library" in "Built-in functions". VasilievVV 15:46, 18 August 2011 (UTC)

Sorry, I missed that. That's very useful; still, named parameters (as further suggested below) may be useful. Ucucha 23:10, 18 August 2011 (UTC)

some thoughts

hmm, I like the looks of this. Some thoughts (This is after only about half an hour of looking at it so some of these might be stupid thoughts or they might be already implemented and i just don't realize):

• more complex argument handling: It might be nice to have named arguments to functions, like you can do in C# (Ucucha also mentioned that above). It'd also be nice to be able to do variable number of arguments (Maybe an arguments array like in js, or some function to get an array of arguments)
• I think the yield statement should maybe be named something else - It does something kind of different from what yield does in other languages. You wouldn't be able to make a generator that generates an infinite list with yield like you could in other langs. (although given we don't have loops other than looping over an assoc array, I guess you wouldn't be able to use yield in that fashion anyways even if it worked like in other langs).
• Minor issue - it seems like it doesn't hook into update.php properly.

Bawolff 03:06, 18 August 2011 (UTC)

For first issue — can you propose alternative syntax? Same for the second issue. I will fix the third one today or tomorrow. VasilievVV 07:26, 18 August 2011 (UTC)

Possibly a separate keyword:

 function name( argument1, argument2, named named1, named named2) {
   if( named1 ) {
      // do stuff
   }
 }

Invoked with: {{#invoke:Module|name|foo|bar|named2=baz}}

Ucucha 12:24, 18 August 2011 (UTC)

The C# way would look something like this (I've never programmed C# so i don't know how it works in practise, but it looks cool. This is based on [1])

someFunc(arg1, arg2, arg3 = "3") {
// do stuff

}
// and all the following would be equivalent way's to call the func:
// self::someFunc( 1, 2, 3);
// self::someFunc( 1, 2 );
// self::someFunc( arg1: 1, arg2: 2, arg3: 3);
// self::someFunc( arg2: 2, arg1: 1, arg3: 3);
// self::someFunc( arg2: 2, arg1: 1);
// self::someFunc( 1, arg3: 3, arg2: 2);
//
// In Wikitext it would be like {{#invoke|module|someFunc|1|arg2=2}}, etc 

In that scheme I think it'd make sense to require that positional non-named arguments must come first if being used (so self::someFunc(arg2: 2, 1) would be illegal ) and in the function deceleration, any optional args would have to be last ( so someFunc( arg1 = 1, arg2 ) {} would be illegal)

I also think it'd be good to have an equivalent to tpl_named_args() and tpl_numbered_args() for the function (func_named_args() or whatever) that would return the functions arguments (in order to be able to do variable number of arguments. If one specifies more arguments than the function accepts you could get the other args with func_named_args()). It also might be nice to have a tpl_all_args() to be like tpl_named_args(), but also have all the numbered arguments have keys like "1", "2" etc.

Another thing that might be interesting is to have a concise syntax for making ranges. For example have [1..3] be equivalent to [1,2,3] and perhaps [0,2,..6] be the same as [0,2,4,6]. I imagine end users are going to want to emulate standard c-style for loops (although I do really like the fact this language doesn't have such loops). for (i in [1..10]) makes nice syntax imho.

As for the yield thing - I unfortunately can't think of a better name for it. Maybe push (because it's kind of like pushing a new value on to the stack of things to return from the function).

Cheers. Bawolff 17:14, 18 August 2011 (UTC)

understanding finished example

I think it would help to show the invocation of the module as well as the output, so that the source of the last line in the table was evident.

I also do not understand the significance of adding true to the return value of main().

--AJim 16:54, 18 August 2011 (UTC)

Whoops. That was the test code which I forgot to remove. VasilievVV 17:07, 18 August 2011 (UTC)

namepaced stdlib functions

Rather than first classed str_* tpl_* considered making these more library like with something like str:: or str: or std:str:*?

Also considered a oop-like syntax? I don't mean full-opp, not even oop at all, that might be a little heavy to implement, but wiki users are not php programmers, the only other languages template users may be using right now are WikiText and JavaScript, and JavaScript is oop. Our editors are already used to str.toLowerCase() and str.replace(a, b), not str_lowercase( $str ) and str_replace( $str, $a, $b ); In particular things like split can be quite confusing to read. As a compromise between readability of oop and the simplicity of functions how about something like $str.str::split( "," );, maybe some tweak to make it easier to read $str.str:split( "," ); or $str.[str::split]( "," );. Basically the idea is functions with a concept of a self or maybe simply some sugar that would make the $str the first arg. It's a function rather than a method of the var so there's no issue with needing to make sure the var is of the right type, but it's easier to read. Then again if we ever find out we really do need oop I don't know how nice that'll be.

Dantman 07:27, 6 September 2011 (UTC)

Some ideas

I think the build in functions should work on lists, associate arrays and strings, not just strings. I think integers and floats should be converted to string when passed.

Some examples:

• lowercase( [ 'String', 'List', [ 'Integer', 'Float' ] ] ) → [ 'string', 'list', [ 'integer', 'float' ] ]
• replace( { a: 'John Doe', b: 'John Smith' }, 'John', 'Jane' ) → { a: 'Jane Doe', b: 'Jane Smith' }
• split( 11000, 0 ) → [ '11', '0', '0', '0' ]
• split( 1.5, '.' ) → [ '1', '5' ]

I think the functions should take an optional length argument to indicate how many should be effected and allow negative values:

• lowercase( 'STRING', 1 ) → 'sTRING'
• replace( [ 'ab', 'ac' ], 'a', 'b', 1 ) → [ 'bb', 'ac' ]
• lowercase( 'STRING', -1 ) → 'STRINg'

I think the functions should take optionally two additional arguments in which case the first argument is the starting position and the second is the stop position.

• lowercase( 'STRING', 3, 4 ) → 'STRinG'

replace() should be able to take a function as a second argument in which case the remaining are the optional arguments length, or start and stop positions.

• replace( [ '1', '2', '3', '4' ], function(c) { return int(c) + 1 }, 2 ) → [ 2, 3, '3', '4' ]
• replace( [ '1', '2', '3', '4' ], function(c) { return int(c) + 1 }, 1, 2 ) → [ '1', 3, 4, '4' ]

I think there should be a map(), filter(), sort(), each(), and unique() function that works on any type. Each of these functions should take a function as a second argument. An optional third and forth argument for length, or start and stop positions.

Python allows all passed unnamed arguments or named arguments that weren't explicitly defined in the argument list to be collected in two special arguments which in this language would be lists and associated arrays. I think this language should support it too:

function example( one, two, named = 'example', *arg_list, **arg_hash ) { }

example( 1, 2, 3, 4, named = 'foobar', test='123', another_test='456' );

In this example:

• one → 1
• two → 2
• named → 'foobar'
• arg_list → [ 3, 4 ]
• arg_hash → { test: '123', another_test: '456' }

I notice there is both length() and str_length(). I think there isn't a need for both.

delete shouldn't require parentheses, languages people are likely to be familiar with don't require it. Also would be nice if multiple variables could be deleted at once:

• delete some_var, some_other_var

I think the Template library should use another syntax to make clearer it is a library like:

• Template::Arg( 'name'[ , default ] )
• Template::Named_Args()
• Template::Numbered_Args()
• Template::In()

I think there should be Template::Args() for returning both named and numbered arguments as an associated array. I think there should be an expand function like Template::Expand() for passing arbitrary wiki markup to the parser and returning it as a string. With this it would be possible to do:

Template::Expand('{{FULLPAGENAME}}') → 'Extension talk:WikiScripts'

--Darklama 14:05, 8 September 2011 (UTC)