- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
the Java-source backend, one inch closer
Wed, 2010-01-20, 11:54
Hi,
I've been getting familiar with the ultra-basics of the "TransMatch" code in
the compiler. I need to use a variation of it as the Java-source generator
cannot cope with the forward jumps generated for efficient pattern matching
(btw, great code there, but time presses me to leave that for later :-)
To get something going I've come up with a strawman implementation [2] and
report [1] that describes the current status.
No, the Java generator is *not* there yet. But for compiler fans the
attached PDF should be a good read.
Miguel
http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerCorner/
[1]
http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerCorner/FirstC...
[2]
http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerCorner/code/p...
Wed, 2010-01-20, 18:07
#2
Re: the Java-source backend, one inch closer
Paul,
As soon as I get my TransMatch-lookalike to generate cascading if's I'll
stay clear from the real one. Want to help with that? ;-)
But if you really want to hear "This makes no sense at all!", what 'bout
this: how come matchTranslation() gets activated on a Match node that is
already a plain switch? I mean, why not traverse down leaving the outer node
as is?
I'd better finish the Java-source backend soon ...
Miguel
Wed, 2010-01-20, 19:27
#3
Re: the Java-source backend, one inch closer
On Wed, Jan 20, 2010 at 06:01:14PM +0100, Miguel Garcia wrote:
> As soon as I get my TransMatch-lookalike to generate cascading if's
> I'll stay clear from the real one. Want to help with that? ;-)
Sure. I'm a huge fan of the work you've done organizing the compiler
information. Best case, your investigations shine clearer light on the
pattern matcher, allowing me to see it well enough to both fix it and
structure it to make your life easier.
> But if you really want to hear "This makes no sense at all!", what
> 'bout this: how come matchTranslation() gets activated on a Match node
> that is already a plain switch? I mean, why not traverse down leaving
> the outer node as is?
It's in matchTranslation() that it discovers that it's a plain switch.
It doesn't know anything about it before that time. Maybe you mean if
it has a @switch annotation? But it can't infer anything from @switch
except to fail, it doesn't actually know it's a valid switch.
Every pattern match arrives as a Match node, but only switches emerge as
a Match node.
On Wed, Jan 20, 2010 at 11:54:33AM +0100, Miguel Garcia wrote:
> I've been getting familiar with the ultra-basics of the "TransMatch"
> code in the compiler. I need to use a variation of it as the
> Java-source generator cannot cope with the forward jumps generated for
> efficient pattern matching (btw, great code there, but time presses me
> to leave that for later :-)
Watch out, if you keep going down this road you will soon be fixing
pattern matcher bugs, and then where would we be?
I will read your pattern matcher pdfs with great interest, looking
especially hard for those magic words:
"This makes no sense at all!"
I'm glad you chose to include what has to be the most attractive
function in the entire pattern matcher (the Pattern apply), as you can
look at it in isolation and innocently envision a bastion of elegance
providing its underpinnings. It's a bastion of something, anyway.