DCT use cases - draft
Dmitry Olshansky
dmitry.olsh at gmail.com
Tue May 22 09:03:08 PDT 2012
On 22.05.2012 19:36, Roman D. Boiko wrote:
> On Tuesday, 22 May 2012 at 15:15:49 UTC, Roman D. Boiko wrote:
>> On Tuesday, 22 May 2012 at 14:56:42 UTC, Dmitry Olshansky wrote:
>>> I suggest to go with such kind of improvised notation with more
>>> examples until you fell that semantics are crystal clear.
>>
>> This is a possible, although not the only, option. Anyway I'm not
>> ready for designing the details yet. There is a lot to do before
>> that.
>
> After thinking a bit more, I decided to investigate the topic
> early, although not immediately :) It should help deciding which
> indices are needed, where are rough edges of API, etc.
Yeah I still think you tried to dismiss it too early.
In my mind it's encountered rather soon:
lex/scan -> postprocess (may be combined with lex) -> populate symbol
tables (ditto - with next step/previous step) -> parse to AST -> ...
That symbol table should contain all of the rich hierarchy of modules.
That is the actual compiler is able to have a single stack of scopes
that it pushes/pops as it processes code. Your DCT on the other hand
should have all of local scopes (of every entity) at once.
It may be possible to simulate it with some deal of laziness, but I
guess keeping the whole symbol table is the easiest and the fastest way
still. Watch out for some mind-bending data structures :)
--
Dmitry Olshansky
More information about the Digitalmars-d
mailing list