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"
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.
Space is never allowed around the method-call dot.
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
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
