3 ms·

That is one thing I sorely miss in languages that aren't lisps. The first optimizer pass is source->source. In guile I do ,opt expression And it prints th

by bjoli 7y ago

That is one thing I sorely miss in languages that aren't lisps. The first optimizer pass is source->source. In guile I do ,opt expression And it prints the source code after a first basic pass of the expander and optimizer. It does constant folding, inlining, dead code elimination and partial evaluation (and some other things). Being able to inspect what guile does helps a lot with macro writing, and is just a generally handy tool. It beats reading assembly (which is also available) any day of the week.

nothrabannosir 7y ago
Scala has well documented compiler passes which act on the full AST, so they're also source -> source. You can print the AST after any pass, using a command line flag. It's not as easy as a Lisp, but useful when you're working on a compiler plugin or extension.
- bjoli 7y ago
  The thing with guile is that it is already an AST, so the code ,opt outputs is still valid guile.
chrisseaton 7y ago
How does it do source-to-source while maintaining debug-ability? If the result of your partial evaluation is source code that is run then what happens when I set a breakpoint on a line that has been partially evaluated away? Is there some metadata that is produced alongside the source to allow that breakpoint to be applied to the code that has been optimized away and how does that work? This is why optimisations aren't usually source-to-source - they need to include in the output extra information that isn't normally representable in source code. Another reason is that compiling to a lower-level representation gives you more power - when I partially evaluate I gain extra information such as that an add operator will not overflow, and I want to include that valuable information in my output even if there is no no-overflow add operator in the source language.
- bjoli 7y ago
  This is not done over regular lisp lists, but over scheme syntax objects that retain the original source info. Those syntax objects are also the basis of the hygienic macro systems in many schemes (at least ones using syntax-case) so that macros also benefit from that information. The lisp source representation is already an AST, so these kinds of transformations are trivial.
- wtetzner 7y ago
  Just having support for a textual representation of the intermediate languages that is easily human readable would probably be good enough. It would let you inspect the intermediate steps. The source info that's tracked could be omitted in the printed representation, even though it still exists in the in-memory representation.
LessDmesg 7y ago
In normal languages you don't need any fancy "macro writing". Lisp helps solve a problem that it created.

by bjoli 7y ago

nothrabannosir 7y ago

Scala has well documented compiler passes which act on the full AST, so they're also source -> source. You can print the AST after any pass, using a command line flag. It's not as easy as a Lisp, but useful when you're working on a compiler plugin or extension.

bjoli 7y ago
The thing with guile is that it is already an AST, so the code ,opt outputs is still valid guile.

chrisseaton 7y ago

How does it do source-to-source while maintaining debug-ability? If the result of your partial evaluation is source code that is run then what happens when I set a breakpoint on a line that has been partially evaluated away? Is there some metadata that is produced alongside the source to allow that breakpoint to be applied to the code that has been optimized away and how does that work? This is why optimisations aren't usually source-to-source - they need to include in the output extra information that isn't normally representable in source code. Another reason is that compiling to a lower-level representation gives you more power - when I partially evaluate I gain extra information such as that an add operator will not overflow, and I want to include that valuable information in my output even if there is no no-overflow add operator in the source language.

bjoli 7y ago
This is not done over regular lisp lists, but over scheme syntax objects that retain the original source info. Those syntax objects are also the basis of the hygienic macro systems in many schemes (at least ones using syntax-case) so that macros also benefit from that information. The lisp source representation is already an AST, so these kinds of transformations are trivial.
wtetzner 7y ago
Just having support for a textual representation of the intermediate languages that is easily human readable would probably be good enough. It would let you inspect the intermediate steps. The source info that's tracked could be omitted in the printed representation, even though it still exists in the in-memory representation.

LessDmesg 7y ago

In normal languages you don't need any fancy "macro writing". Lisp helps solve a problem that it created.