Replies: 5 comments
-
|
Looking at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types, it looks like a fair start would be to take the current Raku grammar / actions, strip it of unsupported syntax, and start adding/adapting Javascript specific tokens / rules / methods. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this is really a Raku problem to solve. Sounds like a module. Especially given the stated goal of interoperability with existing Javascript libraries. Parsing is by far the easiest part. The hard part is the runtime semantics. None of the existing Raku building blocks will be re-usable for that. Neither the RakuAST nodes, nor anything at all from the setting. |
Beta Was this translation helpful? Give feedback.
-
Very likely. But is that a reason to not discuss this here? If it is, where else?
Yes, I know. Still I think it would have better chance than a slang for Perl, as JS doesn't have XS, right?
I got the impression that it actually would be possible to re-use a large part of it. Would you care to elaborate on why it wouldn't be possible? |
Beta Was this translation helpful? Give feedback.
-
A lot of people are watching this repo because they want to participate in topics about Raku's language design or community issues but may not be interested in how to write module X.
Just about all semantics you could think of are different between Javascript and Raku. E.g. variables in Javascript are function scoped while in Raku we are as lexical as possible. Everything about OO is different including method resolution. You'd think there is a lot of common ground, e.g. most basic things like simple addition of numbers, right? No, it isn't. Same goes for string handling. On a first glance it's just the same. I mean string concatenation is string concatenation, right? But then you get into Unicode details and you start reimplementing all our primitives with no help from the VM. It's easy to get something that looks and feels some 80 % like Javascript. That's often good enough if you e.g. want to provide some scripting interface to your language, i.e. users writing simple scripts using your APIs. But for real interop you need to nail down 100 % and that means even supporting the differences in NaN handling between Javascript and IEEE 754-2019. |
Beta Was this translation helpful? Give feedback.
-
|
Closing as Off-Topic here. |
Beta Was this translation helpful? Give feedback.
-
#395 (reply in thread) brought up the idea of having an Inline::Javascript grammar that would convert a Javascript program / library to a RakuAST tree, and thus be able to execute Javascript as native raku code.
It was suggested to give this its own discussion. This is it.
Beta Was this translation helpful? Give feedback.
All reactions