Thoughts on Exegesis 7

[dragonchild]

I have never used Perl5's formats, except for once to see what they did. So, frankly, moving format to Perl6::Form is something I applaud.

The most interesting part of Ex7, imho, was a little gem buried about a third of the way down the page. Options look like really neat syntactic sugar.

The fact that I can write some_option => 1, as :some_option makes me very happy. Turning something on or off is, often, over half the parameters passed to some function or constructor.

Now, I'm not so certain about the usefulness of :some_option[1, 2, 3] or the almost impenetrable :some_option«Some Text» (How on earth are you supposed to make those characters in vi, anyways?!? When was this decided, and by who?) I know I'll like them after the first few months, but I'm just not seeing it right now ...

Now, the formatting stuff, while the actual topic wasn't interesting to me, did further illustrate some of the very neat things we'll be allowed to do. By treating Perl6 as Lisp-ish as possible, the vistas that are opening seem endless. (And, I thought Perl5 had endless vistas ...)

[TimToady]

Now, I'm not so certain about the usefulness of :some_option[1, 2, 3] or the almost impenetrable :some_option«Some Text» (How on earth are you supposed to make those characters in vi, anyways?!?

If you don't like vim's ^K<< approach, Perl 6 will support ASCII lookalikes for anything non-ASCII. Though really, we're intentionally restricting ourselves to Latin-1 characters for builtins, so it shouldn't be that hard to get used to. Anyway, you can always write :some_option<<Some Text>> if you're an ASCII supremacist.

When was this decided, and by who?)

The idea of variable option brackets first occurred to me on Feb 16, and Damian extended it to include the qw-ish «» quotes. I decided on it very shortly before E7 was sent off to O'Reilly, because Damian was hankering to use them. As you may have noticed...

I know I'll like them after the first few months, but I'm just not seeing it right now ...

That's my job in a nutshell: to foresee what people will like after their initial period of disgust... :-)

Part of what causes the initial distress is that one doesn't know how the new feature fits in as a whole. It's certain that :some_option«Some Text» would not be in there if there wasn't already a meaning for «Some Text» by itself. And by itself, even that wouldn't be enough to justify the new :some_option syntax. However, it's also going to let us toss out the special exception for autoquoting hash subscripts that frequently confuses Perl 5 programmers.

In Perl 6, %hash{shift} will always be a call to the shift function, and if you want a constant string as a subscript, you can use, guess what, %hash«shift». (As long as your constant string doesn't contain whitespace, of course.) Plus it generalizes to a slice of constant strings, which Perl 5 can't do at all without a bazillion quotes. So we fix a special case, introduce a pretty syntax for qw//, and get constant slices for free, in addition to omitting the parens from :some_option(«Some Text»), along with the other bracketing composers.

And, over the long term, it will turn out to be much more readable, I think.

Edited by theorbtwo: Fixed HTML mis-nesting.

[dragonchild]

Ok. So, how does the Perl6 compiler distinguish << and >> between their bitshift and quoting modes?

[TimToady]

The bitops have all been re-Huffman-coded because they're not as frequently used as the things we'll be using their operators for. Plus we've resolved the ambiguites by regularizing all the bitops with a prefix that indicates whether you mean a numeric bitop, and string bitop, or a boolean bitop. So << has been respelled +< and >> is now +>.

As for here docs, those now require quotes, so the only amibguity is if you happen to want to use something like <<"stuff">>, in which case you'd have to say << "stuff" >> instead.

Much work has gone into re-engineering the operators for Perl 6. You might be interested in Synopsis 3, which is coming out real soon, by Luke Palmer. (In fact, it would have been out already except that Damian's E7 nudged it aside.) Luke's been doing us the favor of going back and writing Synopses for those earlier Apocalypses that didn't ever have one. And the intent is to leave the Apocalypses "as is" as historical documents full of my old speculations and goofs, while we keep the Synopses up-to-date with my latest speculations and goofs.

[BUU]

Wait a second, I thought (from reading those nifty perl mailing list summaries on perl.com) that the «Some Text» operators would be used as nifty list operators (of some sort). Did this change or is this just another abuse of those funky characters?

[TimToady]

Hasn't changed. That's just another abuse of those characters. The qw// thingies are spelled like French quotes, «Some Text», while the hyper operators are spelled like German quotes, »+« and such. In both cases the underlying visual and psychological metaphor is "there's something potentially plural on the big side of these double angles." I say "potentially", since «SomeText» is actually the single element array ['SomeText'], and 1 »+« 1 would still equal two, since neither side wants to raise the stakes.

[gmax]

How on earth are you supposed to make those characters in vi, anyways?!?

Using vim in any operating system, you can generate those special charachers with the so called "digraphs":

CTRL-K <<

and

CTRL-K >>

For an explanation, and for more strange characters, look at vim's help

:h :digraphs
:h digraph-table

You know, we speakers of exotic languages (with strange characters such as accented vowels) need to learn those tricks. :-)

[theorbtwo]

Where K, of course, stands for Kompose.

It's worth noting that on at least the german keymap, « and » are available on altgr-y and altgr-x.

[TimToady]

The fact that I can write some_option => 1, as :some_option makes me very happy. Turning something on or off is, often, over half the parameters passed to some function or constructor.

I should also point out that this was intentionally modelled both on the Unix command line's use of '-' (without the negative connotations of '-'), as well as the existing option syntax for I/O layers in Perl 5, which we've generalized from working only inside the mode string to working in any argument list. We can also probably extend it to work as an adverbial syntax on operators:

$a .. $b :by(3)

And it still just comes in as an optional parameter, just as if you'd said:

infix:..($a, $b, by => 3)

In a sense, the colon marker on the front serves a similar function to the -ly suffix in English, or the -ku/-ni suffixes in Japanese.

[BrowserUk]

After my initial pass through Ex7, I had 2 thoughts:

1. The depth of thought and analysis that is going into the Perl 6 design.

   Given that formats are (or rather were) seen as a little-used, oft-deprecated, obscure & archaic feature of perl 5, that the redesign should have produced such a comprehensive replacement says something.

2. The Perl 6 Language Reference Manual may need to come on a DVD rather than a CD:)

[Albannach]

I've actually used Perl5's formats qute a lot (probably because I used Perl4's formats quite a lot...) but I'm generally ambivalent about whether they are implemented as a module or not. All the new features and capabilities are very pleasing, but I was begining to wonder if they were getting out of control since the output is still plain text which has frankly limited audience these days. However I am very pleased by the closing thoughts which mention alternate output for formats. Now I don't think Perl6::Form needs to evolve into TeX, but this could certainly give new life to a lot of old code that I still use.

[ysth]

While form() makes sense if its used without print, I can't help thinking print using "..." reads better than print form "..."

(though I haven't programmed basic in almost 20 years)

[theorbtwo]

Eeep! print using is an operator with a space in it in BASIC. That's the sort of thing that makes a syntax ugly, ugly, ugly. Alternatively, you make using a synonym of format, in which case you're using up the rather nice name "using" for something very specific, which you can already write another way.

(Using would make a rather nice statement-modfier form of given, but I can't help thinking that there's something larger it could be used for.

[dragonchild]

Would it be something similar to with in VB or Javascript? While we have that idea in for-aliasing, it certainly would be nice to have that concept a little more elaborated. I could see the benefit as such:

# $object1 has the interface foo
# $object2 has the interface bar and baz
with ($object1)
{
    with ($object2)
    {
        bar;
        foo(baz);
    }
}

and have it be interpreted as:

$object2->bar;
$object1->foo($object2->baz);

Obviously, this is a contrived example, but it could be kinda neat ...

[Aristotle]

I'm sure it'll be easy to retool things so you can say

print
             $foo,  $bar,
    :using("|{>>>>}|{<<<<<<<}|\n|------+---------|"),
             $baz
    :using("|{||||||||||||||}|")

or some such and have it magically transform into what you wanted behind the scenes.

[gmpassos]

:some_option«Some Text»

I just wan't to know how I will type that in my keyboard?

I was looking here and can't find a way to type that! « and » are not normal inputs of a keyboard in any part of the world! And based in what I know, any programing language is built to be typed in a keyboard.

By the way, the idea for :foo rox!

[Aristotle]

If you even read the thread at all you'd find that a) Vim lets you enter such characters even if they're not on your keyboard and b) Perl6 will accept plain-ASCII replacements for all of these. Also, I'd be careful to make a bold statement like "no keyboard layout has these!!" — are you sure even the French don't have them?

[gmpassos]

I don't use Vim! And yes, even the French keyboard haven't it!