From: David Gibson <david@gibson•dropbear.id.au>
To: Scott Wood <scottwood@freescale•com>
Cc: jdl@jdl•com, linuxppc-dev@ozlabs•org
Subject: Re: [PATCH] Add support for binary includes.
Date: Wed, 4 Jun 2008 14:13:04 +1000 [thread overview]
Message-ID: <20080604041304.GD29085@yookeroo.seuss> (raw)
In-Reply-To: <48404D83.4070108@freescale.com>
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
next prev parent reply other threads:[~2008-06-04 4:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-20 19:19 [PATCH] Add support for binary includes Scott Wood
2008-02-22 5:34 ` David Gibson
2008-02-22 18:12 ` Jon Loeliger
2008-02-25 3:38 ` David Gibson
2008-02-22 6:05 ` Grant Likely
2008-02-22 8:34 ` Bartlomiej Sieka
2008-02-22 9:02 ` David Woodhouse
2008-02-22 15:50 ` Grant Likely
2008-02-22 16:08 ` Scott Wood
2008-02-22 16:24 ` Jon Loeliger
2008-02-22 16:28 ` Scott Wood
2008-02-26 0:39 ` David Gibson
2008-02-26 17:26 ` Scott Wood
2008-05-27 15:27 ` Kumar Gala
2008-05-27 17:59 ` Jon Loeliger
2008-05-28 23:58 ` David Gibson
2008-05-29 0:02 ` David Gibson
2008-05-30 18:54 ` Scott Wood
2008-06-04 4:13 ` David Gibson [this message]
2008-06-04 12:36 ` Bartlomiej Sieka
2008-06-04 14:26 ` Jon Loeliger
2008-06-05 3:11 ` Josh Boyer
2008-06-11 1:58 ` dtc: " David Gibson
2008-06-12 16:43 ` Scott Wood
2008-06-13 0:01 ` David Gibson
2008-06-13 0:46 ` Jon Loeliger
2008-06-13 3:41 ` David Gibson
2008-05-29 14:04 ` [PATCH] " Jon Loeliger
2008-05-30 1:34 ` David Gibson
2008-06-02 20:22 ` Jon Loeliger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080604041304.GD29085@yookeroo.seuss \
--to=david@gibson$(echo .)dropbear.id.au \
--cc=jdl@jdl$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=scottwood@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox