On Sat, Aug 16, 2008 at 9:41 AM, Allison Randal <[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() $S0 = foo. bar() $S0 = foo .bar() but this is not: $S0 = foo . bar() > > > or > > $S1 .= "there" > > because it is simple syntactic sugar for the 'concat' opcode, which always > either takes a destination argument, or a self-modifying first source > argument. > 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. > > I like ".." and "~". I also like "+", if we can get IMCC to reliably >> understand that when used on strings it performs concatenation instead >> of some crazy addition. I definitely don't like "." since our best >> practices involves quoting method names such as foo.'bar' which raises >> all sorts of ambiguity. >> > > From common HLLs, '+' is the only one that makes any sense. And, it's > impossible in a low-level language like PIR, because PIR would have no way > of knowing whether to dispatch the following to 'concat' or 'add': > > $P0 = $P1 + $P2 > 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 .. '.) > > > So, proposal rejected. In any case where the dot is unclear, you can always > use: > > $S0 = concat "hi", "there" > > or > > concat $S0, "hi", "there" > > PIR really is just an assembly language with a tiny bit of syntactic sugar. > It's not an HLL. > > Allison I see. I think the confusion is not with the concatenation, the confusion can come with invoking methods. kjs
