PL Pedagogy Poll:

For teaching purposes, what would you call the process of converting a surface syntax tree into a core syntax tree, in an implementation of an interpreter for a programming language?

Compiling
0%
Elaboration
50%
Desugaring
45.5%
Other (comment)
4.5%
Poll ended at .

Gah. Fixed a spelling mistake and it wiped out the responses.

For reference, the process isn't done using racket macros. It's after two layers of parsing (String to SExp, SExp to SurfaceTree). The implemented language is totally untyped, though the implementation language is typed. And the result of elaboration is still ultimately interpreted.

@joey Is it typed and if so are the types used at all in the conversion/translation? Is the core syntax more or less a sublanguage of the surface syntax or are they related but clearly different languages?

@joey (for me:

  • it's elaboration if it's at all type-directed - that could include an H-M surface language to a rank-1 System F fragment in a pinch
  • it's desugaring if the core is a sublanguage of the surface syntax, so that the output could be thrown through a different language implementation with no notion of "core language"
  • both are technically compiling and this isn't a bad notion to introduce, but precision is a good thing

)

@joey in particular, there are good reasons in general for an efficient interpreter to do something that is very intentionally conceptually compilation and it's worth distinguishing "and we compile to this bytecode for efficiency" from the sort of compilation stages that move through intermediate languages to eg provide a clearly semantics-preserving pipeline even if the last of them does in fact spit out a bytecode
@joey Ah, I at first wanted to say "parsing" concrete to abstract syntax but I misread; so my actual answer is elaboration I think
@joey Desugaring would be more for untyped, elaboration more for a typed core syntax

@joey the results of this poll are extremely Type Theory-brained.

I think all are appropriate but it’s important (pedagogically!) to keep the “school of thought” in mind.

@joey also, when searching through the `gcc` codebase to see how they use the term 'elaborate' I found this fun line:

https://github.com/gcc-mirror/gcc/blob/9c694b3ecd0eb5308e85a0eac69c4b2d008ca83e/libstdc%2B%2B-v3/configure.ac#L280

@jmct @joey I assume you know, but for others that might stumble into this thread, that flag indicates weather a "canadian cross-compile" is happening.

A cross compile is when your compiler is generating binaries for a different architecture than it is running on. For example a compiler running on x86_64 and generating ARMv8 binaries

A "canadian cross compile" is when you are cross compiling a cross compiler. So, the compiler is running on x86_64 and outputing (the binaries for) a compiler that will run on ARMv8 but when it runs on ARMv8 it will output PPC64 binaries.

(Here in particular, I think it is try to see if it can run a linker to match the compiler, but you couldn't run a ARMv8 binary in the existing x86_64 environment, so no linker output available.)

I have no idea how "canadian" got in that name, but I assume it was just to have another hard-c word, for the consonance and `ccc` abbreviation.

"Source": https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html (toward the bottom)

Cross-Compilation (automake)

Cross-Compilation (automake)

@BoydStephenSmithJr According to a Wikipedia footnote:

Citation
[1]"4.9 Canadian Crosses". CrossGCC. Archived from the original on October 9, 2004. Retrieved 2012-08-08. "This is called a `Canadian Cross' because at the time a name was needed, Canada had three national [political] parties.

CC @jmct @joey