I've removed the trampoline arity restriction to accomodate curried object constructors with many arguments. I've also added caml_mod_float and fixed a string literal printing bug (the native caml_is_printable returns true for 127-255).
Let me know if there are changes you find unpalatable and I can revert them. Feel free to comment inline.
Minor revs for closure-compiler support
make target for reinstall
Is this function for debugging or closure support?
This is to define the print symbol that print_token below relies on. Closure doesn't have a problem with 'print' being undefined unless you turn warnings on VERBOSE at which point it becomes an error. o_O
I defined this function here to satisfy both c-c's normal and strict checking.
Does this change have to do with ocamljs representing ints as js numbers? Js numbers (being doubles) can represent ints up to 2^52 exactly, so I don't understand the intention here.
Also, changes to stdlib should be changed across all OCaml versions.
The difference in the bit shift operators may also belie a translation bug between the native shift operations and the JS shift operations.
When we nail down these diffs, I will look into porting them to the other OCaml versions. For now, I only have 3.11.2 installed on my machines and restricting it to this version only makes testing faster. Is this reasonable? Do you have suggestions for a better workflow?
Got it. Not sure I understand your 2nd paragraph... you mean we should try to emulate OCaml int semantics in ocamljs? js_of_ocaml does this, at a heavy performance penalty. I am not very interested in getting the semantics to match, since nobody is going to port bit-banging code to ocamljs.
No problem working just on the 3.11.2 branch for now, but I don't want to take patches that don't cover all versions. For something small like this it would be OK to just make the change on the other versions and hope for the best. I'd rather have a version be broken but include the change than to forget a change which should be applied to all versions; that would be confusing.
I see what you mean re: js_of_ocaml. We certainly can't introduce conditionals that check for wrapping onto every integer op. Logical left shift, arithmetic left shift, and logical right shift should perform consistently with addition/subtraction, multiplication, and exponentiation, however.
To maintain correctness, something has to change to harmonize the integer representation. Even a warning about different bit-shifting semantics might suffice so that users know their ocaml has not been translated faithfully. This is a hard problem. Thanks for talking about it.
Yes, maybe it would be best to provide correct int32s (following js_of_ocaml) but let ints be weird. (One hassle is that ocamljs compiles from the lambda code, which is not typed; however in this case I think it is only the operators that need to be special, and we know in lambda code what the int32 operators are.)
I like the approach of providing correct but slow int32 and leaving int with native semantics. After all, it's fine in UNIX/OCaml for native ints to be 31/63-bits and a little strange towards the edges as a result...
If int stays at native precision, native int bitwise ops need to operate at that precision. Right now, arithmetic ops run with 52 bits of precision but bitwise ops run with 32 bits.
(5*(1<<30)) | 0;
(5*(1<<30)) | 0;
Int32 will only need "<<0" or "|0" appended to most operations to mimic 32-bit precision machine ints, I believe.
If this is copasetic, I'll start work on it in the next few days.
How about we just report the width as 32 bits in pervasives.ml? We are no worse off with arithmetic ops, which can overflow to floats anyway.
The point of these defs is to support OUnit (running in a patched Spidermonkey, see ocamljs/src/ounit/README). Maybe it would be better to modify OUnit to call through some other primitives and leave these unimplemented.
I see two issues with these defs:
I tried to, again, do the simplest possible thing and mimic the other unimplemented runtime functions.
What feature of OUnit requires a patched Spidermonkey?
Take a look at that README; print_verbatim is a new primitive added by the patch. The problem is that regular print() always adds a newline (in Spidermonkey at least) so there is no way to implement stdout. But as I said above perhaps it would be better just to hack OUnit not to use stdout at all, and leave these functions unimplemented to avoid confusion.
Is there any way to tell closure-compiler that a particular function is actually defined? The only way to output in Spidermonkey is this print() function that adds newlines, so I don't see how to avoid the patch. (Well, maybe this OUnit-specific output channel could collect output until it sees a newline then print() it at once.)
I see. It is possible to declare functions as external to c-c's working set which would get around this issue, at least temporarily.
It seems to me that the output channel semantics you want are OCaml's which in turn are POSIX's? You suggested something like line-buffering. Obviously this doesn't solve the unbuffered write problem but perhaps that is done through a callback? Then you can make an HTML div into something like a terminal with innerHTML or innerText or what-have-you. Do we need page-buffered mode? Like for the filesystem?
I don't think output channels are very useful in ocamljs, although I guess they could be for porting existing code (to a web-based console as you suggest). For OUnit I just use the command-line Spidermonkey though.
Merge branch 'master' of https://github.com/jaked/ocamljs
Revert OUnit breakage, inappropriate debug fn; define modf
Port js int bitwise hack to other ocaml versions
Treat functions as objects rather than dicts for compiler support
unlimited arity fn wrapping
Escape characters that are not valid ascii