OK. This looks nice and I would be pleased if you could put a few pointers or explanations on your webpage about your typechecker implementation and how it differs with OCaml typechecker. I will get some free time this week and to implement yet another runtime and bytecode compiler from scratch. Not sure if it will be completed at the end of the week, but i'll be definitely interested to know more about the theoretical motivations of works like yours!
On Mon, Aug 30, 2010 at 2:37 AM, Jeremy Bem <jere...@gmail.com> wrote: > bluestorm: > > Thank you for the bug report. The toplevel issue has been fixed in the > version now posted. > > Do you see a nice way to add let-generalization without reintroducing "type > levels"? I was pleased to remove those. > > Ivan: > > It was originally forked from Caml Light but now includes more code from > OCaml. The typechecker is mostly original code at this point; the compiler > is OCaml's with minimal changes to accommodate the new typechecker; the > runtime is almost identical to OCaml's. > > -Jeremy > > On Sun, Aug 29, 2010 at 6:52 AM, bluestorm <bluestorm.d...@gmail.com>wrote: > >> When using the toplevel, declaration phrases fail (looks like a linking >> problem), but expressions work as intented : >> >>> $ llama >> >> Llama Light version 0.0828 >> >> # 1 + 1;; >> >> - : int = 2 >> >> # let x = 1 + 1;; >> >> Error: Reference to undefined global `Toploop' >> >> >> I made my tests using "llamac -i foo.ml". >> >> >> I found it startling that the most important difference to my eyes are >> buried, on the web page, under lines of relatively boring documentation : >> >> In Llama Light (and in contrast to other Caml implementations): >> >> >>> - let does not generalize. >> >> - Phrases are generalized immediately. In particular, "let foo = ref []" >>> does not typecheck. >> >> - The value restriction is not relaxed. (This is similar to Caml Light.) >> >> >>> These choices simplify the implementation while having relatively little >>> impact on the user. >> >> >> You cite the "Let Should Not Be Generalised" paper. There is however a >> difference in your application of the maxim : in the paper, local let that >> have polymorphic type annotations are generalised, while in your system it >> is not possible to force generalisation. >> >> I had a look at the typer, and it's indeed rather simple; it seems it >> would be quite simple to implement generalized let (when encountering >> annotations or with a different syntaxic construct : "letg .. = .. in ..."), >> but the added complexity is equivalent to adding let generalization by >> default. >> >> Is the presence of let-generalization a real issue in your work ? >> > > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > >
_______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
