[Newcompiler] Properties for AST

Stéphane Ducasse stephane.ducasse at univ-savoie.fr
Mon Apr 9 15:06:41 UTC 2007


I would really like to know whether the compression model of theo  
d'hondt is effective in fact :)


On 9 avr. 07, at 16:41, Marcus Denker wrote:

>
> On 09.04.2007, at 15:51, Andrew Tween wrote:
>
>
>>
>> Ok. Thanks.
>> I remember a discussion after a UK smalltalk User group meeting  
>> last year where
>> the question of whether it was better to store source or an AST  
>> came up. From
>> what I remember, most people thought that storing an AST was  
>> better. I made the
>> point then that if an AST can be transformed into source, and if  
>> source can be
>> transformed into an AST, then the two are equivalent, and it  
>> doesn't matter
>> which is stored except for considerations of memory/disk space,  
>> the overhead of
>> performing each transformation, etc.
>>     If one of these transformations is not ~always~ possible, then  
>> some
>> information has been lost that it might be beneficial to retain,  
>> possibly by
>> storing the other representation instead (or store both  
>> representations, or a
>> third representation).
>>
>>>
>>> I need an AST-like representation, possibly compressed later, for  
>>> the
>>> whole image.
>>> Currently the image is 204MB large, our of which way over 100MB are
>>> tokens, which are not
>>> needed... some information of these is needed, but not the tokens
>>> themselves.
>>
>> Could the source itself be considered to be a compressed  
>> representation of the
>> AST? ;)
>>
>
> Yes... but not when you annotate the AST nodes with things that are  
> inherently
> non-textual.
>
> Of course you could do some serialization into (non-human-readable)
> text, but the question is if it's not better to then searialize the  
> objects without caring
> about text.
> It's a bit a "point of view" question: How do I think about the  
> system, and
> do I restrict my thinking by forcing myself to be text only?
>
> As I said: maybe in the end, people will not like it. In most  
> languages Classes
> are not objects, too, as you can parse the code on demand like  
> eclipse does....
> And people love it.
>
> Same problem, same solution. Smalltalk opted to model Classes as  
> object, with
> no source level representation at all. I think we should do the  
> same for methods.
>
> 	Marcus
>
>



More information about the Newcompiler mailing list