Mark Waddingham mark at
Tue Jul 4 10:18:51 CEST 2017

On 2017-06-29 21:13, Mark Wieder via use-livecode wrote:
> Don't know about the 'less confusing' part, but otherwise ruby lets
> you interleave them: if there's an associated name with a parameter
> then that parameter gets assigned to that variable. Otherwise you have
> to work with the parameter position, which IMO is less intuitive, more
> error-prone, and harder to read and maintain. I wouldn't object to
> using python's restriction, but I don't think it's necessary. Given
> that parameters are comma-separated, it's a simple change to the
> script parser to allow this (not that I expect this will ever happen).

Just to point this out but 'just' changing the script parser does 
absolutely nothing at all beyond meaning that a piece of text of the 
form now accepted by said modified parser does not throw a syntax error. 
Said change would actually *do* absolutely nothing.

Syntax is just sugar - you need to implement the feature at all levels 
underneath for it to work... Like most things (unfortunately), there's 
usually a great deal of depth involved - usually directly proportional 
to the generality of the change... In this case (as it is dealing with 
parameter passing) it is quite general indeed.

In regards to named parameters. Python views functions as (essentially) 
taking two abstract parameters - a sequence (the positional parameters) 
and a dictionary (the named parameters). You can see this directly when 
you look at the 'dynamic' invocation form... Which (I think) is:

   function(*listOfArgs, *dictOfArgs)

Here, this invokes 'function' with the positional args from the list 
'listOfArgs' and the dictionary of args 'dictOfArgs'. i.e. it is 
equivalent to doing:

   function(listOfArgs[1], ..., listofArgs[n], firstKey of dictOfArgs: 
dictOfArgs[firstKey], ...)

Indeed, as has already been noted Python does not allow you to mix the 
two. Although I think you could relax that just by re-ordering all named 
args to the end of the parameter list before invocation e.g.

       function 1, foo: bar, 2


       function 1, 2, foo:bar

You might even be able to make it so that named parameters also have a 
position - however I suspect the necessary rules underlying that would 
end up being so obtuse as to make it a somewhat pointless exercise in 
semantic uniformity, and probably not worth the effort.


Mark Waddingham ~ mark at ~
LiveCode: Everyone can create apps

More information about the use-livecode mailing list