On Fri, May 30, 2008 at 01:54:59PM -0500, Scott Wood wrote:
> David Gibson wrote:
>> What I don't like is the combination of the two. Using the /word/
>> form in (1) suggests that each /word/ is a lexically distinct symbol
>> with functions in different contexts: consider /dts-v1/, /include/,
>> /memreserve/ - they're all used only in their own distinct context.
>> Use of /word/s in (2) would suggest that each /word/ is just an
>> identifier for a different function, and should all be usable in a
>> similar grammtical context - which won't be true of /memreserve/,
>> /dts-v1/ and any other truly lexically distinct symbols we need to
>> add.
>
> I don't understand this conclusion -- I wouldn't expect to be able to
> use "for" or "while" at file scope of C code, just because I can use
> "struct", "int", or "sizeof" there. The slashes are simply a way of
> creating reserved words, some of which happen to be function-like.
Heh, when I started revisiting this after my long hiatus doing other
things, I was thinking the same way. I still have a few misgivings,
but then the nice thing about the slash-delimited reserved word thing
is that even if we come up with a new, nicer syntax it's not going to
hurt to keep the slash-form around for compatibility.
sizeof is an interesting example. As you point out it's an example of
a function-like reserved word, which given our existing approach to
reserved words supports your syntax. On the other hand, we may well
want a sizeof operator in dtc itself as part of our expression
support, and in that case, the "be like C" principle suggests it
should be rendered as "sizeof" rather than "/sizeof/".
But as I said that can be dealt with in the future without breaking
compatibility. Objection withdrawn.
Sorry it's taken this long :(.
>> So, I like the notion of functions like this, but with identifiers
>> that aren't /word/s. Re-invoking the "least surprise to C
>> programmers" principle, in general I think the identifiers should be
>> as C identifiers (i.e. [a-zA-Z_][a-zA-Z0-9_]*).
>
> That would make it difficult to have function-like syntax outside of
> properties.
Not really. The only thing such identifiers are ambiguous with is
node and property names, and we've already headed down the path of
making lexical contexts in which node/property names are recognized be
the exception.
My plan for the future here was to have { } always be the thing that
introduces a node/property name context. That's roughly right for the
existing node syntax - obviously there's a bit more complexity there,
since we switch back to normal/expression context after a node/prop
name, then back to node/prop name context after ';'. Then for any
expression operators that take node/prop names, I suggest we also use
{ }, so if 'foo' is a node expression, then maybe 'foo{reg}' to
extract the 'reg' property from the node represented by foo.
I'll need a little finessing, but I think using a lexer context stack
it shouldn't be too hard to handle.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
