in reply to Apocalypse 5 and regexes

In this apocalypse, I read:
In real life, tokens are more recognizable if they are separated by whitespace.

The culture is biased in the wrong direction. Whitespace around tokens should be the norm, not the exception. It should be acceptable to use whitespace to separate tokens that could be confused.

and then I remembered than in the previous apocalypse, Larry decided to make Perl whitespace sensitive and disallowed using whitespace between an aggragate and its index. %hash {key} doesn't index the hash in perl6.

Not even Python has such idiotic whitespace rules.

I've been programming for 20 years. I cannot recall ever using a language that disallowed whitespace between an aggragate and its index. I've been programming Perl for a mere 7 years, less than half of my programming life. I ain't going to break a good habit of twenty years.

But then, perl6 is still vaporware and its progress is slow. I'll keep using perl5 and if its development ceases, I'll learn a new language.

Abigail

Replies are listed 'Best First'.
Re: Re: Apocalypse 5 and regexes
by Anonymous Monk on Jun 06, 2002 at 16:45 UTC
    Given that the penultimate style rule in perlstyle is 'Be consistent', it does seem odd that Larry would remove whitespace sensitivity from one part of the language but add it to another.
[reply]
Re: Re: Apocalypse 5 and regexes
by ignatz (Vicar) on Jun 06, 2002 at 16:56 UTC
    The open way that development is being done on around Perl 6 is completely new in the history of programming languages. Considering how much money has been invested in its development, I'm rather impressed with it's progress. 
    ()-()
 \"/
  `
[reply]
(ichi) 2.times('Re: ') Apocalypse 5 and regexes
by ichimunki (Priest) on Jun 06, 2002 at 17:47 UTC
    I can't imagine why I would want to put a space between an aggregate and its index (personally, YMMV). That makes it appear as if there are two entities there, when in fact it is one. I can imagine why I would want whitespace in a regex though (and the proposed RE system looks really great). I'm also under the impression that disallowing a space between %hash and {key} allows %hash {block} to perform a block action. The big mistake here is not a whitespace issue, though-- or an inconsistency WRT whitespace. It's a symbol issue.

    Apparently Larry has a {} fetish. There is not a single reason why %hash[key] is less acceptable than %hash{key} in Perl6, yet it looks as those the latter will be the way to go. If you kick out %hash{key} in favor of %hash[key], you immediately open up the possibility that %hash [key] can be allowed (unless I've missed something that indicated [key] on its own to mean something the way {key} on its own means something).
[reply]
[d/l]
[select]
      There is not a single reason why %hash[key]? is less acceptable than %hash{key} in Perl6

      You're perfectly correct. There's not a single reason; there are (at least) five:

      1. We're trying to retain at least some backwards compatibility in the syntax for variable accesses,

      2. Not distinguishing statically between hash and array look-ups severely limits opportunities for fundamental optimizations,

      3. Not distinguishing statically between hash and array look-ups reduces our ability to do compile-time error detection,

      4. Even without error checking, programmers are much less likely to make mistakes if there is three characters' difference between a hash look-up and an array look-up, rather than just a single sigil (that's why we inflect both noun and verb when making plurals in English),

      5. Unless we distinguish hash and array look-ups, there's no way to create objects that can be used as both, according to need (e.g. we can't fix caller to allow named return elements, and we can't allow regexes to simultaneously return their numbered captures as an array and their named captures as a hash.
[reply]
[d/l]
[select]
        I'm not certain I'm concerned about consistency, if ever there were a time to make a change, this is it (1).

        I'm also not sure I understand the motive for optimization at this point (2,3)-- it seems premature... but I will defer to your experience.

        I am certain I haven't had any problems keeping my Ruby hashes and arrays separate (4)-- and those don't even have sigils (of course, a simple naming convention might keep them straight, but what a pain if you decide to switch an object from one class to another-- indeed, the Perl sigils have this same annoying property).

        As to 5, I think I'll wait for Ex5, since I've not yet internalized A5, but I don't see how the brackets/brace is a problem if you are assigning a series of key/values to a hash. Larry appears to be proposing / %hash{key}:=(val) %hash{key2}:=(val2) / I don't think that / %hash['key']:=(val) %hash['key2']:=(val2) / would be any less acceptable or readable once the programmer gets used to brackets (and using literals instead of bare words). I certainly like the notion of having something like %hash = ($x =~ /key:=(val) key2:=(val2) / ) available, but I didn't see that in A5 (maybe I missed it?).

[reply]
[d/l]
[select]
       $fullname = $fullname{$id};
 $email    = $email   {$id};

      [download]

      We are using here a powerful strategy of synthesis: wishful thinking. -- The Wizard Book

[reply]
[d/l]

      Actually this has been hashed (I say, I say, that's a joke there, boy) out pretty thoroughly on the language list. The braces are neccessary because otherwise anonymous hash constructors seem to have no syntactic justification, and we need the brackets for anonymous array constructors. Plus there are strong historical reasons at work.

      As for Larry's braces fetish, this is absolutely not true. Having designed a few mini languages myself, I can tell you that there isn't anything else to use. Braces already mean code, parens mean args, brackets mean array ref, and angles are ugly, so filehandles got the diamond and hashes got the braces because in early Perl it was pretty clear what they meant. The only reason Larry seems to have a braces fetish is that alot of the Apocalypses have dealt with blocks - closure, special CAPITAL blocks, switch statements, embedded code.

      Cheers,
      Erik

      Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet

[reply]
      {I}{like}{to}{put}{a}{space}{between}{an}{aggregate}{and}{its}{index}{
+because}{if}{you}{do}{not}{things}{get}{very}{hard}{to}{read}{Remembe
+r}{that}{Larry}{used}{to}{use}{English}{as}{an}{inspiration}{when}{he
+}{designed}{Perl}{Too}{bad}{he}{has}{choosen}{German}{as}{the}{way}{f
+or}{Perl6}{I}{fail}{to}{see}{why}{you}{think}{it}{is}{just}{one}{enti
+ty}{Unlike}{Perl1}{hashes}{are}{first}{class}{citizens}{A}{hash}{is}{
+something}{but}{a}{hash}{element}{is}{something}{else}{Just}{like}{an
+}{object}{is}{different}{from}{a}{method}{and}{a}{method}{is}{differe
+nt}{than}{its}{arguments}{Abigail}

      [download]
[reply]
[d/l]
        { I }{ do }{ not }{ see }{ why }{ it }{ is }{ a }{ problem }{ when }{ you }{ can }{ choose }{ to }{  break }{ with }{ whitespace }{ inside }{ of }{ the }{ braces }
[reply]
[d/l]

In Section Meditations