So you know another of my intentions,
I've added another semi-major TODO item for the Muldis D language spec, whose
details in the form of a ramble can be seen here:
http://github.com/muldis/Muldis-D/commit/676f688
For context, Muldis D fundamentally supports only named routine arguments, and
not either of: 1. only positional arguments, like most languages; 2. mixed
positional and named arguments, like a few languages including Perl 6.
So the normal generic way to invoke any routine is like these:
f1( source => foo, filter => bar )
f2( topic => foo, other => bar )
I determined this to be the best default choice, versus say positional only,
partly because it makes code more self-documenting, and partly because it raises
internal consistency of the language in the face of constructs for say lists of
attributes and values, of tuples or relations or some scalars.
Currently, Muldis D has a couple of related contrivances designed to let users
write generic routine calls more tersely by avoiding argument names in common
situations where they aren't needed so much for self-documentation.
The first contrivance: The general case which works for user-defined routines
is that up to 2 arguments may be given positionally, and then the parser will
interpret those as if they had the names 'topic' and 'other'; those 2 names are
treated as special.
For example, this parses into the same as the second example above:
f2( foo, bar )
... but the first example has no such shortcut.
The second contrivance: For system-defined routines only, if the routine is
invoked with just a single argument, that argument may be positional, because
the parser knows already what the argument name is. This doesn't apply to
user-defined routines because Muldis D code parsers are supposed to be able to
parse a routine or type etc without any context, including the definition or
signature of other user-defined routines.
The first main change is that Muldis D will no longer treat parameter/argument
names of "topic" or "other" as being special, but will instead treat numeric
names of "0" or "1" etc as being special. And it will do this consistently for
both user-defined and system-defined routines, for any number of positional
arguments.
And so, the following 2 items will then be parsed into the same thing:
f2( foo, bar )
f2( "0"=>foo, "1"=>bar )
The second main change is that declaring aliases for parameter names would be
supported. That is, a parameter could be declared to bind with several
alternate argument names. This is useful if a different name is more useful
inside a routine from one that reads better when invoking it. But this same
mechanism would be used to support the positional parameters, and the numbers
must be explicitly declared, as params don't get positional aliases
automatically, for various reasons including flexibility and correctness.
For example, f2 could be declared like this now:
function f2 (Int <-- topic|"0" : Int, other|"1" : Int) {...}
... and then all of the above calling examples would work with it.
The idea of having aliases like this was inspired by a Perl 6 feature:
http://perlcabal.org/syn/S06.html#Named_parameters
... which has examples like:
sub formalize($text, :case($required_case), :justify($justification)) {...}
sub globalize (:g(:global($gl))) {...}
... but specifically I support that all names are available on the argument
side.
My current plan is to apply the ideas in this email prior to the ones I
mentioned before, concerning meta-operators.
-- Darren Duncan
_______________________________________________
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
