Hi,

I was poking at the idea of implementing that coroutine system I discussed and I noticed that that Parser class has a lot of private methods. I was hoping to just tell the parser to start parsing a code fragment but the parser as it is would only support parsing a whole compilation unit (as best I can tell).

Any thoughts? My current idea is to try wrapping my snippet of code in a fake class and method just to get things going. Not sure what sorts of major roadblock I might encounter doing it that way, though.

How about for now, you just rebuild the Compiler Pod with the methods you want exposed?

That would let you continue with the experimentation... API changes could then be discussed later in the day when you have a clearer idea of what works...?

I was poking at the idea of implementing that coroutine system I discussed and I noticed that that Parser class has a lot of private methods.

If you notice something obvious you think you'd like to see public, I can look at changing. The key issue to keep in mind is that things like closures require keeping track of their curType and curSlot. So parsing snippets could turn out to be very complicated.

brian,

Yeah I was just running into that exact problem (not having access to the current type, slot, and closure in the DSL). Also I found that a DSL runs after the InitClosures() compiler phase so if the code has a closure in it I'll be in trouble.

Any likelihood that the DSLs could be processed during the Parse() phase instead? That would mean that whatever Expr I return or other code generated will be processed "in the usual way" as if the code were actually written in there.

As it is now, the Expr returned by the DSL is missing a few phases and that means there's a few things that won't work in a DSL (like closures).

It would also be great if the DSL could have access to the current type, slot, and closure so that it is possible to construct a ClosureExpr within a DSL.

SlimerDude,

I tried copying a large portion of Parser for now to make it work to see if its workable and what methods I might want to have exposed. However, it's not the end of the story as I mentioned above.

I may have to abandon the DSL approach and try it as an actual modification to the Compiler. Or at least modify the Compiler to make it feasible to implement this as a DSL.

Another thing I've noticed that prevents me from returning a closure from a DSL is that in ResovleExpr, resolveDsl() returns the generated Expr node, but doesn't call resolveExpr() on that result which means that if you return an expr that needs to be resolved by resolveExpr() it won't be happy (based on what I'm seeing).

So a DSL couldn't return a ternary operator, a dynamic function call, and some other things.

If it were me I'd probably invoke the DSL compile method as soon as I found it in the Parse compile phase.

I think the DSL resolution really should be done either during or immediately after the Parse phase. Any tips on why it isn't or shouldn't be done that way?

The problem with exploding a DSL at parse time is that we haven't yet resolved the DSL type. But we might be able to work around that.

Although in general we do expression replacement at ResolveExpr time and it should work ok since then everything inside the expression will be resolved.

that result which means that if you return an expr that needs to be resolved by resolveExpr() it won't be happy (based on what I'm seeing).

Can you manually just call that?

Ah, you are right I can directly construct my own ResolveExpr() and call visitExpr() directly.

I'll try making my own copy of InitClosures() that has public access to process(ClosureExpr c).

Then all I'm missing is a sane way to determine which class, slot, and closure I'm in. Currently I think I can find that by looking at my source code location and scan all the compilation units to see what I'm inside of based on that, but it seems like quite the hack.

If I can get it all to work I'll definitely be putting in a feature request to give the DslPlugin access to its current scope.

Also I now see that inside resolveExpr() it calls result.walk(this) which will call visitExpr() on the Expr returned by the DSL so this isn't necessary. Sorry I missed it the first time.