Re: ASTs

On Jan 17, 2013, at 6:05 AM, Hannes Mehnert wrote:

> Hi,
> 
> On 17/01/2013 08:41, mikel evins wrote:
>> I had a little time tonight so I got a simple test harness for the
>> s-expression reader up.
> 
> awesome.
> 
>> Obviously, the goal is to rurn the Bard sketch into a real
>> implementation of a readtable-based reader that generates ASTs in
>> OpenDylan's native format. The obvious question to ask is, "where can
>> I find out more about the native format of OpenDylan's ASTs?"
> 
> The Open Dylan parser/reader creates definitions
> (sources/dfmc/definitions/) out of the tokens, intermingled with macro
> expansion.
> 
> Bruce pointed you already to the hackers guide - I believe I wrote that
> section some years ago...
> 
> I think instantiating classes which are defined in dfmc-definition (like
> <method-definition> etc) from the s-expression reader should be doable -
> these definitions are later fed into dfmc-conversion, which produces the
> control and data flow graphs on which optimizations etc is done.

That sounds to me like the sensible way to go about it.

Sounds like what I should do is write a simple Lisp-style reader that builds s-expressions in the usual way from text. Dylan <pair> and <symbol> objects will serve just fine in the role they served in the original s-expression syntax. 

Given a tree of pairs and atoms, it's easy enough to walk it and generate code for each node encountered--in fact, it's exactly what the existing Bard compiler and interpreter do.

The last remaining question is: exactly what code should it generate for each node? Sounds like the answer is the objects you mention above, which then serve as inputs to the dfmc stuff. Again, I even have code lying around that more or less does that job, though it's written in Bard, not Dylan, and it targets Objective-C (I used it in a contract last year writing games for iOS; we used Bard to write scene descriptions and rules, and a simple compiler, also written in Bard, to generate Objective-C code and resources for XCode to compile). Anyway, porting Bard code to Dylan shouldn't be hard (I may even be able to adapt the compiler to automate some of it), and using the same tools to generate Dylan code for input to dfmc should also be reasonably easy.

There will be some complications--reader macros; rubout handling if we ever get a repl working; deciding how to capture source information for s-expression code, and so on. I don't need to concern myself about those things at the start, though. It should be sufficient to make something simple that can turn a reasonable updated Dylan s-expression language into data suitable for input to dfmc.
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers