Shift.js: Swift to JavaScript Transpiler | Hacker News Reader

Shift.js: Swift to JavaScript Transpiler

github.com

85 pointsDnld46 comments

It is a cool idea but I don't understand why you don't write your compiler in Swift so at some point you can compile your compiler with your own compiler.

Unfortunately, it is far from usable. It is unable to parse even basic Swift code.

Thanks. The project is still in active early development, so there are still a lot of bugs that need to be worked out. We have a good portion of the core language features covered so far, and are working on adding more.

It looks like you're using built-in collection types in the resulting JavaScript without accounting for the fact that Swift collections are value types, not reference types. Do you plan to address this? There's another third-party Swift implementation out there focusing on Android which does the same thing and buries this drastic language change in the fine print, which is rather unfortunate.

This is on the radar. The differences between the languages, especially regarding collections, are tricky. For example we're finalizing a data structure to mimic tuples that would allow value lookup by index and/or element name.

Great! It must be pretty tricky to translate that across without destroying performance and interoperability. I just wanted to check, because the other one seemed to think it was no big deal to leave it this way.

> I don't understand why you don't write your compiler in Swift so at some point you can compile your compiler with your own compiler

Is there a solid technical or user requirement for that to be done? If there isn't, why do it?

Well, getting a compiler to be self-hosting means it has to be good enough to compile a large, complex, real-world application: itself.

Whats the benefit of this compared to using https://github.com/kripken/emscripten ?

In short: fewer steps in the conversion process so it is easier to debug the output, which inevitably happens when using a transpiler.

Can you compile Swift programs on Windows with LLVM ?

This word, "transpiler", must die. Call it a translator or a compiler; there's no need for a new word in this case.

Looks like an interesting project, though. I'll keep an eye on it.

(transpiler) I think it's pretty useful. It signifies that the translation is "fairly" simple, as in the case of CoffeeScript, as opposed to traditional compilers targeting assembly or byte code, or even something like Emscripten. It implies that the translation is hand tuned to the target language to be minimal. (I believe Jeremy pretty much coined the term). See https://en.m.wikipedia.org/wiki/Source-to-source_compiler

Except that anyone with background in compiler design knows that compilation to another language is just yet another way to implement the language.

It is a common design pattern to make the compiler output code in one of the OS SDK languages as a means to speed up development and ease prototyping.

That's quite the point, for a transpiler targeting another language is not just "a way to implement it". It is a conscious decision with many pros and cons and an impact on the transpiled language itself.

Except no one ever spoke of transpilers when C compilers generated Assembly, C++, Objective-C and Eiffel generated C and so forth.

It was just the output of the compiler.

A transpiler is specifically a "source-to-source" language translator.

So a C compiler is a transpiler, given that classical C compilers just outputted Assembly that was processed further by the Assembler.

Eiffel compilers are also transpilers as they use C as intermediate language.

Scheme compilers are also transpilers as many use C as intermediate language.

....

So, a compiler.

I am already waiting to see someone say that C transpiles to Assembly.

Concept of compiling things is awesome. But I refuse to understand how making compiled language -> interpreted language is a thing... It should be other way around. I'd love to see something solid like js -> c compiler so my js code runs quick and efficient.

A js -> c compiler would actually be much, much slower than current JITs because of the lack of type information.

Just declare a C union of an int, float, string, etc. All functions take these unions as function parameters.

Have one field be an enum of its actual type. Or something along these lines.

I don't see why this is any more difficult than a normal jit that also doesnt have type information.

Because JITs are able to generate code that optimistically assumes variables have certain types (with appropriate deoptimization checks), which is much less expensive than performing full dynamic lookups on every single operation.

It's easier to chuck away type information than mystically conjure it out of thin air.

An ahead-of-time compiler can't make JS fast because it lacks the type information needed to do so. That's why you need just-in-time compilation for JS: you can only discover what types go where by running the code.

Meant to say JS -> binary so you can have a node/express server compiled and running. Browser JS is another story of cource

With modern languages the line between compiled and interpreted is blurred, and can almost be thought of as an implementation detail.

Most modern JavaScript engines incorporate a JIT compiler, for example.

If something can be written in or for js, it will be.

This is cool, but once swift is open sourced I'd imagine that you'll be able to use emscripten to generate JavaScript code instead of native asm. In fact you can probably do that today by havin swiftc emit llvm IR and imputing that into the emscripten backend like that guy did to get swift running on his android phone.

Hmmmmm

There's a pretty big difference between emscripten and compilers that specifically target JS. The ones that target JS will generally use JS memory management and attempt to use JS language features whereas emscripten targets asm.js and manages memory itself within byte arrays.

Does this support classes or protocols yet?

Not yet, classes and structs are planned for the next big push. Protocols shortly after that.

Not got time to look at this in depth right now, but glad to see somethibg like this.

Is it swift to ES5, 6 or 7?

Update: looks like ES5.

Yes, right now, it converts to ES5.

We decided to stick with ES5, since there are still many browser compatibility issues with ES6.

Have you looked into Babel?

Why not transpile down to ES6/2015 and rely on Babel for transpilation to ES5?

You're asking why he doesn't want to add yet another compilation step? Isn't that obvious?

swift -> es6 -> es5

If you need code written in Language X but insist on using Language Y "yet another step" probably isn't the deal breaker you imagine it to be.

I don't see why you'd need that intermediary step. Babel transpiles to ES5. I imagine this in an alternative to Babel, not a companion.

Awesome project, I hope to make some contributions to it on Github in the future!

This is a very awesome project, how can I get in..

make commits, issue pull requests.

Why not just learn swift? I never understood this random language -> other random language...

I'm guessing so you could use swift to write web front end code. And this goes from Swift -> JS, so you would still need to learn Swift

yeah, but that seems ridiculous

In this case you would have to learn JavaScript, since it compiles to JavaScript.

Reply on news.ycombinator.com