Stephane Le Dorze wrote:
Indeed, for a language/framework to break throught, it needs to get momentum with a big/growing community and to play with current/hypped technologies, take advantage of working with existing librairies and getting a decent tooling.
I'm not sure I buy into the importance of integration with "hyped" technologies. Perhaps you could be more specific about some project that you feel can't be implemented adequately with Ur/Web as it stands today? I'm asking for a description of the user experience you're aiming for; requiring integration with some specific technology that the end user doesn't see is "cheating." ;)
I also want to emphasize that I'm not trying to maximize adoption of Ur/Web. Rather, I'm trying to maximize the effectiveness of people who do choose to use it. This means that I'm completely happy if basic features of Ur/Web mean that 90% of programmers will never be able to use it.
(a FFI via C only does not target the right community).
There's been a JavaScript FFI since well before the first Ur/Web beta release.
When I think about it, I immediatly see a JS backend. Just being able to integrate this community and run on NodeJS for instance or take advantage of existing JS APIs and Tools.
Which benefits do you see from server-side JavaScript? I'll be really surprised if any such system can get over the inherent costs of the JavaScript language, to match the performance and security of Ur/Web.
Would a JS backend be hard to integrate with the current compiler which is already targetting the JS frontend?.
There wouldn't be anything technically interesting to do. It would probably be a significant amount of mostly-boring work.
Another question: are there other reasons than timing not to have targeted a LLVM backend instead of the current one?
Since the Ur/Web compiler works via generated C code, I have a feeling it would be trivial to just drop in LLVM's clang as an alternate compiler to call in the last stage of compilation. To me, the engineering benefits of going via C rather than a lower-level language are clear, so I wouldn't want to output LLVM bytecodes directly, just like I don't output assembly directly now.
_______________________________________________ Ur mailing list Ur@impredicative.com http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
