On Sat, 26 Oct 2002, fearcadi wrote:
: * are stream separators ";" "&" "|" in the "for" loop - operators
: in the usual sence ( like "," ) or they are pure grammar ?
If ";", probably operator, though behaving a bit differently on
the left of -> than on the right, since the right is essentially
a signature. Ordinarily a ; in a signature would be taken to
mean optional arguments, but "for" would hide that meaning.
If we used & and | they'd have to be pure grammar, since they're
not really doing superpositions.
: * is prototype of the subrotine more regexp then expression ?
: to what extent it is a regexp ? where it is stored , can we inspect it
: or even change .
I have been resisting the notion that the signature can be generalized
into a regex. I'd rather have it separate, so that parsing is a
separate concern from the list of input arguments. In my tome last
night I was actually putting regex-ese into the name rather than the
signature, like this:
sub term:qa<quotestr> (str $quotestr) { ... }
which would presumably define a qa// term. But maybe that's putting
too much load onto the term: notation. Maybe it should be
sub term:qa (str $quotestr) is parsed /qa<quotestr>/ { ... }
Or maybe it should be something else entirely. In any event, all
the information should be stored somewhere where it can be inspected,
almost certainly in ordinary properties. In fact,
my int sub foo (int $x) { ... }
is really syntactic sugar for something like:
my &foo is retsig (int) is sig (int $x) is body { ... }
which may in turn be syntactic sugar for:
my &foo ::= new Code(retsig => (int),
sig => (int $x),
body => { ... });
: * do we have have an axcess to the signature of the
: subroutine if we have been passed only its reference .
: that is , for exemple , can
:
: process( @x , &step )
:
: guess how many arguments &step expects ?
I don't see why not, if a sub ref is pointing at its descriptor as
it does in Perl 5.
: * how one can write function analogous to "for" loop that will be able to
: handle multiple streams ?
That depends on whether ; is an operator or pure grammar. :-)
In either case, the body of the function is going to get in the
separate streams as an array of lists. The signature will also have
to come in as a sequence-separated list, so that the routine can match
up the streams. I expect that "for" might have an immediate component
(read "macro") that analyzes the number of streams at compile time
so as to call an efficient looping algorithm for the common cases.
: * how one can call subroutine "in place"
: sub (str $x , int $n ) {
:
: $x ~ ["one, "two", ... , "hundreed"][$n]
:
: } . ( "/home/temp/", $f ) ;
:
: or
:
: given ( "/home/temp/", $f )
: -> ( str $x , int $n ) {
: $x ~ ["one, "two", ... , "hundreed"][$n]
: };
:
:
: it seems that the last does not work because given take only one argument.
But that argument can certainly be a list, and it seems like it would
not be too terribly difficult to make it do the signature binding
just the same as if they were function arguments.
In fact, I'm thinking about a Haskellish way to take any argument
that's a list reference and map it against a sub-signature.
Something like:
sub foo ([$head, *@tail], *@other) { ... }
foo( [1,2,3], 4,5,6 );
with the result that the parameters are bound like this:
$head := 1
@tail := 2,3
@other := 4,5,6
Or maybe the declaration of a sub-signature just uses parens like the
outer ones:
sub foo (($head, *@tail), *@otherargs) { ... }
That's less distinctive but more consistent. On the other hand,
there are perhaps reasons to distinguish a sub-signature that
parses multiple args from a sub-signature that parses a single
list arg.
In that frame of mind, your latter case might just work right out of the
box. The "given" supplies a scalar context to its left argument, so
the ("/home/tmp/", $f) is taken to mean ["/home/tmp/",$f]. And that
is a valid list to feed to the sub-signature on the right. At worst,
you might have to use [] on the right instead of (). If so, it'd probably
be better to use it on both sides:
given [ "/home/temp/", $f ]
-> [ str $x , int $n ] { ... }
Note that the topic in the given is an array ref in this case, not the
the first element of the list.
Larry
