Re: my new article, "A Romp Through Infinity"

This is more a comment on something you wrote about rather than about your writing itself. I'm trying to get my head around some Perl 6 design ideas because I find it helps me to program in a language (or in fact use any program) if I understand more about how the developers view the interface and concepts in their project.

Since Perl 6 is supposed to be largely about context, I find it surprising that one would put an adverb after an operator. It seems to me as if most adverbs are going to be used such that they can be thought of as setting a context for the expression. It seems some bracketing construct around the expression or a prefix adverb are either one clearer then a postfix adverb.

Placing the adverb after the operator reads more naturally if one is converting the phrase to English as one reads, as in "if fido is greater than scooter by the authority of the AKC" vs. "if, according to the AKC, fido is greater than scooter". I'm just not sure it makes the visual impact in the code that I'd want it to make.

I can understand that putting the optional parameters first is an unusual thing. It's often more difficult to parse, too. The parsing difficulty seems to arise more from the rarity of it than vice versa, though. I'm wondering if putting the optional "adverb" parameters last was fully considered or done from force of habit.

Comment on Re: my new article, "A Romp Through Infinity"

Replies are listed 'Best First'.
Re^2: my new article, "A Romp Through Infinity" by John M. Dlugosz (Monsignor) on Aug 06, 2008 at 19:04 UTC
Interesting. Perl has a legacy of putting modifiers afterwards, unlike many contemporary languages: `foo($x,$y) if verbose; $handle= open($fname) or die;` [download] But the `if` can certainly be written first, also. If an operator were being programmed/adjusted by setting contextual variables, then you would have to put those first. `$+case_sensitive = False; if $name1 gt $name2 { ...` [download] Using ordinary function call syntax, the recommendation is to put the positional parameters first and the named parameters last, but you don't have to. You could write a macro to put operator adverbs first, using a keyword or something. That would be consistant with the syntax for 'if' used as a statement, and with 'given'. Something like: `under :authority<AKC> { if $fido after $scooter { ... } }` Ah, but that moves it out from the whole statement, not still attached to the expression. I'm sure some syntax could be devised. If you want to continue to muse about it, I'll collect it as a use case for what macros need to be capable of, and will try it as an example when that part is being fleshed out. —John	[reply] [d/l] [select]
Re^3: my new article, "A Romp Through Infinity" by mr_mischief (Monsignor) on Aug 06, 2008 at 19:32 UTC
I'm afraid to dirty this thread too much more with my ramblings, but this is what I had in mind looks much like the syntax you presented. It's just that the adverbial part would come closer to the beginning so the programmer would start thinking about the special case before doing the comparison mentally. `if ( :authority<AKC> $name1 > $name2 ) { #... }` [download] I'm not sure if just any bracket should be allowed, or if a special set should be necessary. The parsing for an infix operator could collect all the named parameters up front, though, starting from the opening of the context. It could continue until it sees the operator, then use the previous value and the following value as the operands/positional parameters. With this: `if :authority<AKC> { $name1 > $name2 > $name3 } { # ... }` [download] or this: `if :authority<AKC> { $name1 > $name2 && $name1 > 0 } { # ... }` [download] the list of optional parameters could be used for every infix operator in the context. Since Perl6 supports chained comparisons, the syntax you report is either ambiguous or cumbersome from what I can tell. Does this place both operators in the context: `if $name1 > $name2 > $name3 :authority<AKC> { #... }` [download] or is this necessary: `if $name1 > $name2 :authority<AKC > $name3 :authority<AKC> { #... }` [download] Furthermore, if you're comparing things does it even make sense that all the comparisons are not done in the same way? How often do you compare the EBCDIC ordinal for the letter 't' to the ASCII ordinal for 'd'? Who wants to know if the before-tax income of one employee is higher than the after-tax income of another? These things should be possible for the sake of flexibility in case someone really needs to do something requiring that. However, what's the syntax for that now? Is it even smart in that situation to connect the adverb to the verb instead of an adjective to the noun? If one needs two different contexts, they should be able to use methods on their objects to get the values. It only makes sense to use the adverbial form when they're all going to be in the same context. This example has a bug in it if the latter syntax above is correct: `if $letter_1 > $letter_2 :lc > $letter_3 { # what if $letter_3 is a capital? }` [download] That bug wouldn't be possible if the adverb controlled a block context.	[reply] [d/l] [select]
Re^4: my new article, "A Romp Through Infinity" by John M. Dlugosz (Monsignor) on Aug 07, 2008 at 10:02 UTC
You would need a keyword or other syntactic marker, since a literal pair before anything else would not know its to be taken as an adverb. Larry said that :lc would refer to the single use of the operator only, not the whole chain. The parser just could not work to apply it to the whole chain. But putting it first somehow would avoid that problem, so I like the idea in general. Basically, establish the options in a lexical scope and then use the operators as many times as you want. For strings in particular, contextual variables might be good for controlling the default options. This is not a case of using different accessors -- you would want to compare strings using whatever rules rather than transforming (and copying) the whole string first. Especially when the comparison may decide after only a few characters, and not need to look at the whole string. In your last example, :lc won't do anything to the numeric comparison. You have a more serious bug of using > where you meant gt. —John	[reply]