3 ms·

I would be very interested to understand how the translation to C was done. I would love to prototype like that. The CL to C translators that I know produce cod

I would be very interested to understand how the translation to C was done. I would love to prototype like that. The CL to C translators that I know produce code that is much more complicated. This is extremely clean in comparison.

ygra 6y ago
I guess with a one-off translator you can spend more time on the patterns you know you have to translate well instead of having to handle every single possibility that could potentially come up in code. At work we can do something similar with our C#-to-everything-else compiler which handles a subset of C# 5, since for many things it's easier to just change the single line in C# than spending a day implementing a complicated feature. The other reason the code is somewhat clean (albeit long) is probably that there's been 20 years of work on it. And it probably wasn't that long in the beginning.
- register 6y ago
  I already knew that but defining such a subset that it is at the same expressive and flexible enough is a challenge by itself. More even so if it is used to build a GC. Now I am curios: can you provide some more details about what C# subset are you using?
  - ygra 6y ago
    Well, it's perhaps not only the language subset, but also part of the standard library you have to provide or re-implement. I don't know Lisp too well, but I'm sure there are parts of it that are not necessarily mandatory for creating a prototype of a garbage collector. As for C#, the things we don't support are: - yield statements: codegen for that is not fun to do on your own and hand-writing an IEnumerator is annoying, but not too bad. And back when we started we couldn't get the generated code from Roslyn, maybe there's a way by now to do that. - async/await (could nowadays be converted into pretty much the same in JS at least, but Task/Promise/CompletableFuture work slightly differently anyway and there aren't that many places in the codebase that need this, so they can be patched) - dynamic (no reason to use it, thus no reason to support it). - Some generic constraints, e.g. new(): We currently emit JS, TypeScript, Java, and Python, along with a number of internally-relevant output formats like documentation – and .NET generics already don't map well to Java generics (or vice-versa), and are mostly useless for JS and Python, anyway. - goto, unless for fall-through in switch Most “normal” things like types/members/statements/expressions do work properly and the subset isn't too bad working in (it's also not a particularly small subset, of course). A lot of additional work comes in getting the necessary parts of the BCL to work on the other side of the conversion, of course, but that is a separate concern next to language features.
nwsm 6y ago
Apparently the conversion was used for a prototype and then it was rewritten. [0] [0] https://twitter.com/Suchtiman/status/1265152818131894272 https://twitter.com/Suchtiman/status/1265152818131894272
- nineteen999 6y ago
  Never let the truth get in the way of a tall LISP story. Not to cast shade on the original feat which is a great achievement, but let's face it, there are many LISP proponents somewhat prone to hyperbole.

ygra 6y ago

I guess with a one-off translator you can spend more time on the patterns you know you have to translate well instead of having to handle every single possibility that could potentially come up in code. At work we can do something similar with our C#-to-everything-else compiler which handles a subset of C# 5, since for many things it's easier to just change the single line in C# than spending a day implementing a complicated feature. The other reason the code is somewhat clean (albeit long) is probably that there's been 20 years of work on it. And it probably wasn't that long in the beginning.

register 6y ago
I already knew that but defining such a subset that it is at the same expressive and flexible enough is a challenge by itself. More even so if it is used to build a GC. Now I am curios: can you provide some more details about what C# subset are you using?
- ygra 6y ago
  Well, it's perhaps not only the language subset, but also part of the standard library you have to provide or re-implement. I don't know Lisp too well, but I'm sure there are parts of it that are not necessarily mandatory for creating a prototype of a garbage collector. As for C#, the things we don't support are: - yield statements: codegen for that is not fun to do on your own and hand-writing an IEnumerator is annoying, but not too bad. And back when we started we couldn't get the generated code from Roslyn, maybe there's a way by now to do that. - async/await (could nowadays be converted into pretty much the same in JS at least, but Task/Promise/CompletableFuture work slightly differently anyway and there aren't that many places in the codebase that need this, so they can be patched) - dynamic (no reason to use it, thus no reason to support it). - Some generic constraints, e.g. new(): We currently emit JS, TypeScript, Java, and Python, along with a number of internally-relevant output formats like documentation – and .NET generics already don't map well to Java generics (or vice-versa), and are mostly useless for JS and Python, anyway. - goto, unless for fall-through in switch Most “normal” things like types/members/statements/expressions do work properly and the subset isn't too bad working in (it's also not a particularly small subset, of course). A lot of additional work comes in getting the necessary parts of the BCL to work on the other side of the conversion, of course, but that is a separate concern next to language features.

nwsm 6y ago

Apparently the conversion was used for a prototype and then it was rewritten. [0] [0] https://twitter.com/Suchtiman/status/1265152818131894272 https://twitter.com/Suchtiman/status/1265152818131894272

nineteen999 6y ago
Never let the truth get in the way of a tall LISP story. Not to cast shade on the original feat which is a great achievement, but let's face it, there are many LISP proponents somewhat prone to hyperbole.