On Mon, Aug 18, 2008 at 10:31 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> 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.
I'm sorry, but this is not the case. It is in fact valid:
running:
==========
.sub main
newclass $P0, "foo"
$P1 = new "foo"
$P1 .hi() # note the space before the dot
$P1. hi() # note the space after the dot
.end
.namespace ["foo"]
.sub hi :method
print "hi\n"
.end
==========
prints "hi\n" twice on my system and always has since I've worked on pir..
(this is because, in imcc's lexer a '.' is always returned as DOT (for
object/method separation) and a '.' is only returned as a concatenation
operator iff it is surrounded by whitespace on both sides; the actual
reg.expr for this in imcc.l is {WS}'.'{WS} )
>
> 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.
I see where you're coming from, and makes your previous argument more valid.
However, IMHO, in this aspect, PIR is just parsed as any HLL language; for
instance in C, you can write something like:
int x=1; return x;
No space needed when it's clear what tokens are meant; but in order to be
able to parse 'int' or 'return', both must be followed by a space.
>
> 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'. :)
I wouldn't go as far as that, but then again, it's not my call :-)
>
>
> Allison
In all, I don't want to make too big an issue out of this, just trying to
clean up the peculiarities and have them documented :-)
kjs
