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