Klaas-Jan Stol wrote:
On Sat, Aug 16, 2008 at 9:41 AM, Allison Randal <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Klaas-Jan Stol wrote:
On Wed Aug 06 05:53:07 2008, kjs wrote:
My proposal would be to change the concatenate dot into
"..", which looks
like it, but is more explicit, and will prevent such mistakes.
I agree that there should be some change. I've run into this problem
myself in the past, and it's very frustrating. I don't like
having to
take into account whitespace to resolve syntactic ambiguities,
especially not in something which is basically an assembly language.
The example in the original ticket is an IMCC parsing problem. The code:
foo . "bar"()
should absolutely never be parsed as a CONCAT operation. The dot
should only be parsed as CONCAT when it's accompanied by an '=':
$S0 = "hi" . "there"
having a '=' around is not enough. This is valid PIR:
$S0 = foo.bar()
Yes.
$S0 = foo. bar()
$S0 = foo .bar()
No, these are both syntax errors and always have been.
but this is not:
$S0 = foo . bar()
Pardon, I wasn't clear enough. I was explaining why the following is
never a valid statement
foo . bar()
(there is no syntactic sugar for concatenation without a destination for
the result of the operation)
The only '.' statements that are valid syntax are:
Concatenation:
$XN = "hi" . "there"
$XN .= "there"
or Method Call:
$XN = foo.bar()
They all include an '=' sign, but I didn't mean to imply that all
possible variations on statements that include a '.' and '=' are valid
syntax.
Is this statement:
Space is never allowed around the method-call dot.
the general rule, or is this merely the current situation? I mean, it's
how IMCC now implements the difference between the methodcall dot and
the concatenation dot. So, if not allowing space around a method-call is
the way to distinguish, well then there's no problem.
Except for the reason I sent this proposal in the first place: it can
confuse newcomers, because it's a special case where whitespace is
significant.
It's the spec. Whitespace is often significant in PIR. Newlines
terminate statements. Spaces are currently allowed around hash/array
keys, but really shouldn't be. In fact, you can currently do:
$P0=new'ResizablePMCArray'
$P0[1]="foo"
$S1=$P0[1]
print $S1
print"\n"
The only place you can't remove the space is between 'print' and the
register variable. Blech. We should make spaces obligatory in a few more
places.
to be clear: my proposal was not to use '+', and I disagree on that '+'
is the only thing that makes sense: Perl 6 uses '~'. (Or maybe I
misunderstand the phrase 'From common HLLs .. '.)
I know you weren't proposing '+'. By "common HLLs" I meant I can name 10
languages off the top of my head that use '+' and that's not an
exhaustive list. But, they're all HLLs with a large number of more
advanced features than PIR has.
Perl 6 is the only language that uses '~'. Any other alternate
concatenation operators ('&', '||', '$+') are equally rare. Even '.' is
only Perl 5 and PHP, so it's soon-to-be rare.
Inventing new syntax for concatenation isn't particularly helpful for
newcomers, and neither is using rare concatenation operators that
newcomers will have likely never seen before.
I see. I think the confusion is not with the concatenation, the
confusion can come with invoking methods.
If you really don't like '.' we can remove the syntactic sugar for
concatenation entirely and only use 'concat'. :)
Allison
