A..Z alternatives
Larry Wall wrote: Somebody needs to talk me out of using A..Z for the simple cases. Larry The Turing programming language uses splat to stand in for the length of the array, so in Turing *a[*-1]* means what Perl 5 programmers mean when they say *$a[-1]*. However, splat is already quite heavily loaded in Perl 6. So I got to thinking of Ada's empty box operator, **. Maybe it would be a good stand-in for the temporary it that represents a dimension's length. So [EMAIL PROTECTED]-3..-1]* could be the syntax to grab the last 3 three elements of [EMAIL PROTECTED] That might confuse users of languages that were not C-syntax-influenced, who think that '**' means not equal. But surely old Modula hacks like me are in a minority in the Perl world (and Pascal programmers would never do Perl, would they? Algol, anybody?) So maybe I'm the only one who runs the risk of that particular confusion. :-) 'Course, I don't pretend to understand all the possible existing meanings that '**' and '**' already have in Perl 6, either. =thom Q. How many Malkieri does it take to screw in a light bulb? A. Well, it better not be more than one.
Re: backticks
Luke Palmer wrote:
That said, I have mixed feelings about the idea. I am thoroughly
convinced that ` can leave it's current job. Removing qx// would be
going a leap too far.
But I really hate the idea of removing `...` and leaving qx/.../. That
would leave qx// in the unenviable position of being the only
quote-like operator that doesn't have a corresponding quote-like
syntax. After all, the only real point of having qx[], qx(), qx{}, qx//,
et. al. is so you can get the effect of `...` without having to quote
your backticks.
Well, maybe that's not the only point. Some people really prefer
bracketing punctuation marks that are reflections of each other.
I am not particularly fond of the idea of abolishing the established
role of `...`. Nor do I like the %hash`keyval syntax; it gives me the
Eat at $joe's willies. But *please* either keep *both* of qx// and
`...`, or eliminate *both* of them. Either one without the other doesn't
make much sense to me.
In defense of `...`, I suspect it is used most heavily in one-liners at
a command prompt -- where saving keystrokes is most important, and where
its uses aren't cataloged anywhere (so my suspicions can't be easily
verified or falsified).
However, I really do like the idea of having a special syntax for
%hash{'keyval'}. As I've said, I don't like ` for the purpose. But OTOH,
I don't have any better suggestion for a syntax. Except to point out
that if you're frequently accessing a hash via constant strings, you're
probably using it like a record. And in Perl 6, that's better spelt as
$obj.keyval.
=thom
Smile, they said,
it could be worse.
So, I did...
And it was.
Re: Compatibility with perl 5
Matthew Walton wrote:
Mark J. Reed wrote:
On 2004-04-13 at 13:16:02, David Cantrell wrote:
Perl 6, we are promised, will try to run legacy code unchanged. How
will it spot such legacy code?
My understanding has been that perl6 will assume a program is Perl 5
unless
it sees a Perl 6 keyword such as 'module' or 'class'.
That could be problematic, because if Perl 6 sees something like:
my %myhash;
%myhash{'foo'} = 'bar';
Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?
It's going to think 'ahah', perl 5'. Because it doesn't contain any Perl
6 keyword (such as 'module' or 'class'), as Mark said.
=thom
Reality is that which, when you stop believing it, doesn't go away.
-Philip K. Dick
Re: Compatibility with perl 5
Matthew Walton wrote:
Thomas A. Boyer wrote:
Matthew Walton wrote:
That could be problematic, because if Perl 6 sees something like:
my %myhash;
%myhash{'foo'} = 'bar';
It's going to think 'ahah', perl 5'. Because it doesn't contain any
Perl 6 keyword (such as 'module' or 'class'), as Mark said.
But then trying to process that as Perl 5 will result in an error.
This doesn't seem particularly sane to me. Will we have to say
use 6;
on all Perl 6 programs to avoid this kind of thing?
Forgive me if I'm missing something obvious here.
The original question was how do I label my code as Perl 5? The
correct answer, according to Apocalypse 1, is to start your source with
package. If you didn't want to put your code in a package, then start
it with package main.
The other question was how do I label my code as Perl 6? The correct
answer, according to Apocalypse 1, is to start your source with module
or class.
Here is the relevant paragraph from the apocalypse:
I hereby declare that a |package| declaration at the front of a
file unambiguously indicates you are parsing Perl 5 code. If
you want to write a Perl 6 module or class, it'll start with
the keyword |module| or |class|. I don't know yet what the exact
syntax of a module or a class declaration will be, but one
thing I do know is that it'll set the current global namespace
much like a |package| declaration does.
=thom
A lot of people become pessimists from financing optimists.
Guillemets: innies or outies?
Damian Conway wrote: Correct. Although presumably this: my @d = @x »but« Foo; Damian, somewhere in the conversation on hyper-ops you switched over from this syntax: my @sum = @a «+» @b; to this syntax: my @sum = @a »+« @b; (Since those two statements use non-ASCII characters, let's just say that on my screen those two statements look a lot like: my @sum = @a + @b; and my @sum = @a + @b; respectively, but the doubled angle brackets are single characters [guillemets].) I saw one post from someone who said that the French use the outward-pointing convention for quoting, and the Germans use the inward-pointing convention. I never saw anything else along these lines, but you've used the outward-pointing convention since then. I like the outward-pointing convention better (why *else* would I be whinging? :-) because parentheses and brackets are both used with the outward-pointing convention. Would you care to share your thoughts on why you've gone with inward-pointing guillemets? And, please, let's spawn no threads talking about how parentheses in font Foo on platform Bar look like they point outwards. Ulk. =thom
Re: Guillemets: innies or outies?
And, please, let's spawn no threads talking about how parentheses in font Foo on platform Bar look like they point outwards. Ulk. Er... I meant to say inwards. Else that sentence makes NO sense. Double Ulk. =thom You live and learn. Or you don't live long. --Lazarus Long
Re: Multimethod/multisub thought...
Dan Sugalski wrote: There's also the fun of: Dog bar(int); Cat bar(int); and xyzzy(Dog); xyzzy(Cat); with the call of: xyzzy(bar(1)); Just one of the many brain-benders that I'm glad Larry has to deal with, not me. (Though this may be one of the reasons A6 is taking so long...) -- Ada handles this kind of problem. This is what used to be called operator overloading, before the phrase was coopted by C++ (before C++ came along, the limited version of operator overloading used in C++ was called *operand* overloading, since you're only allowed to overload based on operand types). To disambiguate a call in the presence of full operator overloading, two full complete passes over the expression tree are required. The first pass is a bottom-up pass to collect all the potential return types; the second is a top-down pass that uses the context to eliminate some (hopefully all but one) of the available return types computed in the first pass. In Ada, if the second pass doesn't completely disambiguate the expression, it's considered an error. I studied this stuff for my masters thesis, for which I added (Ada style) operator overloading to a Modula-2 compiler. When it was all over, I decided that I much prefer (C++ style) operand overloading. The computation to decide what the programmer meant is too complicated. For the user, not the compiler. Although the compiler can do it [the code is bulky, but not difficult to understand], I think that the programmer will be left in the dust. And I think that's a bad thing. In all but the simplest cases, the coder will have a very difficult time figuring out what the compiler's actually going to do. As a matter of fact, I always thought that Cwantarray was a nice compromise: let the programmer decide exactly what to do in the small number of cases where it's really useful. So here's *my* vote against return-type multi-method disambiguation. =thom Don't use that word [fantastic] to a lawyer; straining at gnats and swallowing camels is a required course in law school -- _Stranger_in_a_Strange_Land_
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
Michael Lazzaro wrote:
*Now*, what to do about the fantastic magic that pointy-sub provides?
The _spectacular_ win would be if we could just recognize an optional
parameter list as part of a block.
map @a : ($a,$b) {...} # params + closure = closure with params?
for @a : ($a,$b) {...}
So that anywhere you had a closure, you could put a paramlist in front
of it. Not likely we could get that to work, since best-case scenario
it would probably barf on $a and $b being undefined before it ever got
to the closure. But it might be possible, at the expense of some
parser complexity.
I agree that it might be difficult to recognize the ($a,$b) as a parameter list rather
than a list expression. Smalltalk marks block parameters this way:
b := [:a :b | a b]. Assign a two-paremeter block to b
^b value: 1 value: 2. Return the value of invoking b on 1 and 2
The [ makes it clear that a block is next; the : marks parameters and the | ends
the list. A literal translation to Perlish syntax would be
map @a { :$a :$b | $a + $b }
but then we get into discussions about Larry's 2nd law of colons. Besides, we perl
mongers already use | for a sufficient multitude of other things.
But my point is: just because C-ish programmers think (...){ ... } feels
parameterish doesn't mean that the parameter declaration has to come *before* the
opening curly brace. And no, despite two Smalltalk-related posts in the last three
days, I don't want to turn Perl into Smalltalk; I just think that Smalltalk has a nice
syntactic solution to the problem we're talking about here.
The problem is, I can't think of any syntaxes better than
map @a { $a $b: $a + $b } # hey, buddy, can you lend me a colon?
map @a { args $a, $b; $a + $b }
map @a { - ($a, $b); $a + $b }
map @a { $a, $b -$a + $b } # can't coexist with A4-style pointy subs
map @a { my^ $a, $b; $a + $b } # the ^ is reminiscent of map @a { $^a + $^b }
map @a {{$a, $b} $a + $b } # all other uses of consecutive curlies require
space: { {
map @a { EXPLICIT_ARGUMENTS_TO_FOLLOW $a $b ARGUMENTS_STOP_HERE $a + $b }
and they all look uglier than... well, um, uh... I want.
I have a strong suspicion that this possibility was carefully considered by {LW, DC,
...} (that's set notation, not a code block :) before the Apocalypse 4 pointy sub
syntax (and the for-loop syntax using it) was promulgated. And that it was rejected
because it's hard to come up with something that looks right. Even the Smalltalk
syntax is a tad awkward-looking to me, and the warpage that is necessary to make it
Perlish just compounds the problem.
Hmmm. I guess I didn't really say anything here, did I? Do I post these ruminations,
or should I just hit that cancel button before I open my mouth and remove all doubt?
Nah. I'm goin' for it: maybe somebody else will think of a syntax that looks right!
=thom
Must be a yearning deep in human heart to stop other people from doing as they
please. Rules, laws--always for the other fellow. A murky part of us, something we had
before we came down out of the trees, and failed to shuck when we stood up. Because
not one of those people said: 'Please pass this so I won't be able to do something I
know I should stop.' Nyet, tovarishchee, was always something they hated to see their
neighbors doing. Stop them 'for their own good'--not because the speaker claimed to be
harmed by it.
Manuel Davis O'Kelley
The Moon is a Harsh Mistress
Re: Paren madness (was Re: Regex query)
David Whipp wrote: $b = 7, 6, 5 b = 7, 6, 5 I understand that C's *interpretation* of the comma operator will be expunged from Perl 6. But unless comma's *precedence* is also changing, neither of those statements would build a list with three elements. It seems to me that $b = 7, 6, 5; is the same as ($b = 7), 6, 5; not $b = (7, 6, 5); because '=' binds tighter than ','. So it will assign 7 to $b, and then effectively evaluate the statement 7, 6, 5; which might build a list and then discard it. I.e., it is akin to these statements: [7, 6, 5]; 3 + 4; 7; (and equally feckless). =thom
declaring if and while (was: rule, rx and sub)
Larry Wall wrote:
: In summary: assuming Perl 6 allows user-defined while-ish structures, how
: would it be done?
I think the secret is to allow easy attachment of regex rules to sub
and parameter declarations. There's little point in re-inventing
regex syntax using declarations. The whole point of making Perl 6
parse itself with regexes is to make this sort of stuff easy.
Larry
Ah. I'd been wondering how Damian's
sub if (bool $condition, block);
was going to be extended to handle if-else, if-elsif, if-elsif-else, if-elsif-elsif,
if-elsif-elsif-else, etc.
I *think* what you're saying is that user defined while-ish and if-ish constructs
should really be created by altering the Perl 6 parser at compile time. Of course,
that's not really news: you already said that in Apocalypse N (for some value of N
(I'm to lazy to determine which, since it doesn't matter (and besides, laziness is one
of my cardinal virtues :-) (parse *that* if you can -- don't smileys just play havoc
with parenthesis-counting?.
I was provoked to ask my question about Cwhile by Damian's message which said, in
part:
So Cif's signature is:
sub if (bool $condition, block);
Now, if I'm understanding correctly, *that* turns out not to be the case. Of course,
Damian's point was to talk about semicolons after blocks, not Cif structures in all
their glorious complexity. Nonetheless, the signature of Cif in Perl 6 will have to
be more complicated than that, or it wouldn't be able to handle zero-or-more elsif's
and zero-or-one else's.
Again quoting Damian:
Likewise I could write my own Cperhaps subroutine:
sub perhaps (bool $condition, num $probability, block) {
This, on the other hand, would be true. The simplicity of this hypothetical control
structure makes it possible to use the built-in syntactic features of Perl 6
(especially the rules concerning blocks and how they interact with commas and
semicolons), so it wouldn't be necessary to extend the grammar to implement Cperhaps.
Am I getting this straight?
=thom
Re: Perl6 grammar (take V)
Aaron Sherman wrote:
An example:
$pid = fork() // -1;
if $pid 0 {
# error ...
} else unless $pid {
# Parent
} else if $pid 0 {
# Child
} else {
# Huh? Can't happen
}
Of course, your indentation implies a different syntax than the parser actually sees.
The parser sees it more like this:
$pid = fork() // -1;
if $pid 0 {
# error ...
} else
unless $pid {
# Parent
} else
if $pid 0 {
# Child
} else {
# Huh? Can't happen
}
Now, as you point out, the dangling-else ambiguity isn't a problem in Perl, since the
curly braces are required. Nonetheless, _I_ want to keep the 'elsif' because it means
that I and the parser are seeing the same thing. When my mental model of something
doesn't match the way that thing really works, the opportunities for screwing up are
dramatically increased. Now, I don't see _how_ I can screw it up in this case, but I
also don't see any reason for gratuitously removing the ability have my mental model
match the actual model.
There's really no good reason to continue treating conditionals this
way. A simple
cond: ('if'|'unless') expr block [ 'else' (cond|block) ]
solves the whole thing; is easy to write and parse; and reduces the
number of keywords in Perl.
Why does it matter how many keywords there are in Perl? I thought that a major
motivation for having the sigils was that it makes language extension easier, since
variables are effectively in a different namespace than keywords. The only downside I
can see in having the extra keyword is that it makes it problematic *if* I want to
name a subroutine elsif. And I *don't* want to. :-)
=thom
