my new article, "A Romp Through Infinity"

[John M. Dlugosz]

This weekend I wrote A Romp Through Infinity which explains the Inf features of Perl 6, but drills down each example to reach the most fundamental language features, which it then explains.

It should be interesting to those just taking the plunge to Perl 6 because so many features are present in the smallest code fragment. I'm hoping this concept will make it less obscure. I'm experimenting with literary style too: since it's stream of consciousness, I'm using standouts in the text rather than breakheads, so you can still find something again when skimming but not introduce artificial organization.

For experts, look at the final section where I point out things in the ongoing design that need work. These examples identify things missing from the Synopses, etc.

Please let me know if you see any coding errors, and of course any feedback is welcome.

—John

[Anonymous Monk]

Do you have encoding issues?

You could also use something like ⁅>⁆ or a myriad of other
+s that do not have built-in meanings at all, if you like.

in firefox3, i see two square boxes, like

 __  __
|20||20|
|45]|46|

[John M. Dlugosz]

No, it's encoded correctly. It looks like your browser read it OK, but used a "fallback font" that contains little squares with hex numbers in them instead of what that character really looks like.

Try installing the Code 2000 font, which you can find and download for free. I see it is also covered by DejaVu (all varieties), MS Gothic, MS Mincho, MS PGothic, MS PMincho, MS UI Gothic

But you saw ∞ and ℵ OK?

--John

[mr_mischief]

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.

[John M. Dlugosz]

Interesting. Perl has a legacy of putting modifiers afterwards, unlike many contemporary languages:

foo($x,$y)  if verbose;
$handle= open($fname) or die;

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 { ...

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

[mr_mischief]

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 ) { #... }

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 } { # ... }

or this:

if :authority<AKC> { $name1 > $name2 && $name1 > 0 } { # ... }

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> { #... }

or is this necessary:

if $name1 > $name2 :authority<AKC > $name3 :authority<AKC> {
#...
}

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?
}

That bug wouldn't be possible if the adverb controlled a block context.