On Tuesday, 22 May 2012 at 16:55:46 UTC, Dmitry Olshansky wrote:
On 22.05.2012 20:47, Roman D. Boiko wrote:
On Tuesday, 22 May 2012 at 16:03:49 UTC, Dmitry Olshansky
wrote:
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.
And likely the only feasible in D. It doesn't support lazy
evaluation
for immutable data structures, and immutability is necessary
for most
use cases.
Watch out for some mind-bending data structures :)
Do you mean not to overcomplicate? Or use classic data
structures? Or
something else?
Prefer simple for prototype. Good old nested hash table is fine
for starters.
Unfortunately, hash tables don't play nicely with immutability of
data - although interface could be restricted to prevent
mutation, they would not be able to reuse memory space, and thus
would require copying.
So far I think immutable red-black trees will be central in DCT
architecture, as well as some others.
Cool ;) Though why not Tries then if the data is immutable?
Those too :) For different purposes than the former.
