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