Mirror of forum.nim-lang.org

479 :: What is the plan for javascript support in the standard library?

• gradha (orginal) [2014-06-21T01:16:47+02:00] view original

  As mentioned in the nimrod compiler user guide the javascript target doesn't support file management. For example trying to import strtabs will then fail since it depends on the os module which includes file procs.

  While such files could be sprinkled with when not defined(js) blocks, maybe such modules should use a subset define like when not fsAvailable which would be more generic and also of use in embedded environments? The same document mentions defines for embedded systems but is javascript an embedded target or just one which lacks file management?

  Also, what would be the correct way to patch the standard library, remove the problematic procs or provide dummy procs or wrappers which may do similar things to the original (eg: echo in js does append strings to the HTML body, while I thought it would just log to the debug console somehow).

---

• Araq (orginal) [2014-06-21T12:57:44+02:00] view original

  • strtabs really shouldn't import os. We should get rid of this dependency.
  • when defined(js) has been attempted in the times module and it sucks for maintenance. So let's not repeat this mistake.
  • JS is a weird target, but not embedded.
  • The correct way to do is to explicitly mention in the module's docs when it works with the JavaScript target and all other modules are not supposed to work. In addition to that we should have JavaScript specific wrappers and modules. It is completely unrealistic that the average Nimrod program compiles to JavaScript cleanly, so application level code needs to have special when defined(js) sections anyway. It might as well import platform dependent modules then.

  Also, what would be the correct way to patch the standard library...?

  Depends on the particular patch, but don't bother to make the whole stdlib "JS compatible". It's not feasible. What should be made to work however are the collection and string handling libraries.

---

• gradha (orginal) [2014-06-21T16:08:27+02:00] view original

  A module like rstgen depends on IO for certain procs. If a dummy javascript wrapper is provided for TFile, modules like rstgen and others will work out of the box and won't require tweaking, even if using those procs doesn't make sense at all in js. But if you say that patching the stdlib to be JS compatible is not feasible, should I fork rstgen instead and make a js specific version? Or maybe move the IO related procs to a submodule breaking current code, so in the future rstgen only works on memory and rstgen_io has the additional js incompatible procs?

---

• Araq (orginal) [2014-06-21T17:00:43+02:00] view original

  Ah that's what you're after. Well a dummy wrapper for TFile looks like a good idea. We could even go further and provide a small file system emulation layer so that writeFile("foo.txt", "test"); echo readFile("foo.txt") produces "test". But then we end up emulating os.getEnv for strtabs and perhaps createDir for the compiler ... I don't know. Could be great for porting, could be horrible. But if we go that route, symbols like fsAvailable or emulateFS make sense.

  Or maybe move the IO related procs to a submodule breaking current code, so in the future rstgen only works on memory and rstgen_io has the additional js incompatible procs?

  We can also make rstgen work on streams and provide a streams implementation for JS. I think it can be done without breaking code when you provide a new rstgen_streams module that rstgen uses (use export perhaps?).

  So the essence is: I don't know. Emulation surely makes lots of sense when we're after porting Nimrod's tooling.

---

• Bumbles (orginal) [2014-06-21T17:45:53+02:00] view original

  Why do you guys not just compiled to C -> use emscripten, skip the whole writing the JS backend yourself?

---

• Araq (orginal) [2014-06-21T19:03:00+02:00] view original

  The JS backend already exists, it is hard to skip something that happened in the past. Also the existing JS backend targets JS+DOM, whereas emscripten and asm.js treat JS as if it was some low level interface. I have no idea how to access the DOM from C+emscripten, for instance, nor do I want to know... Also running our own GC as a hack on top of a runtime (if it's even possible with emscripten) that already provides a GC is just madness.

---