DCT use cases - draft

[Roman D. Boiko]

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.