Re: [Caml-list] interest in a much simpler, but modern, Caml?
* Jeremy Bem: To support my research, I've developed an implementation (Llama Light) of the core Caml language. Modules, objects, labels etc are not supported (except for file-level modules). The system strongly resembles OCaml, however the completely rewritten typechecker is not only much smaller in terms of lines-of-code; it has a genuinely simpler design owing especially to the lack of first-class modules. How do you deal with strings (are they mutable?) and polymorphic equality (is it type-safe?)? ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
On Sun, Aug 8, 2010 at 1:59 PM, Florian Weimer f...@deneb.enyo.de wrote: * Jeremy Bem: To support my research, I've developed an implementation (Llama Light) of the core Caml language. Modules, objects, labels etc are not supported (except for file-level modules). The system strongly resembles OCaml, however the completely rewritten typechecker is not only much smaller in terms of lines-of-code; it has a genuinely simpler design owing especially to the lack of first-class modules. How do you deal with strings (are they mutable?) and polymorphic equality (is it type-safe?)? Yes and no, respectively. In other words, nothing new here. Strings can be made immutable (in both Llama and OCaml) by disabling String.set in the standard library (the s.[i] - c construct is just sugar for a call to that function). Is there a better approach to polymorphic equality floating around? -Jeremy ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
* Jeremy Bem: Yes and no, respectively. In other words, nothing new here. Oh. I just happen to think that those two are very high on the list of things you want to fix once you can start with a clean slate. Is there a better approach to polymorphic equality floating around? Besides type classes? I'm not sure. It's probably possible to remove this feature from the language, with a little bit of syntactic overhead to pass around a matching comparison function. ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
On Sun, Aug 8, 2010 at 2:52 PM, Florian Weimer f...@deneb.enyo.de wrote: * Jeremy Bem: Yes and no, respectively. In other words, nothing new here. Oh. I just happen to think that those two are very high on the list of things you want to fix once you can start with a clean slate. Is there a better approach to polymorphic equality floating around? Besides type classes? I'm not sure. It's probably possible to remove this feature from the language, with a little bit of syntactic overhead to pass around a matching comparison function. Maybe I should clarify that my main goal has been to bring Caml Light up-to-date with OCaml's improvements, while keeping the type-checking code very simple, not to try to make further improvements. In fact, I wouldn't necessarily claim that omitting the module and object systems is an improvement, just that it is a simplification. But actually, now that you mention it, I did briefly explore the idea of removing Caml's polymorphic comparison functions. One issue I ran into was syntactic. How would you write: if 'A' = c c = 'Z' then ... where c is a char, without polymorphic comparison, and without more radical changes such as type classes? Ideally the solution would generalize to int64s, etc. I briefly had lexer support for a syntax along the lines of if 'A' =`c` c c =`c` 'Z' then ... In general, the backquote is available since I don't support variants. However, this syntax didn't feel elegant enough to warrant expanding the Llama project's more conservative scope. Currently OCaml can compile Llama code, a feature which doesn't seem like it should be discarded too lightly. I also found multiple instances of a pattern like type foo = Foo of int | Goo of string if myfoo = Foo 3 then ... It felt tedious and perhaps destructive to re-code all of these. Finally, on what theoretical basis do we disallow polymorphic comparison but retain polymorphic hashing and marshalling? Perhaps we just want all these functions to be less convenient, e.g. isolated in their own Polymorphic module. After all, Llama retains even the Obj module. Once the current system is posted, I could consider making these changes after all. Suggestions to smooth the syntax are more than welcome. Perhaps a bit more time to re-code things carefully is all that is really needed. If there is a broad consensus for immutable strings, I could make that change as well, again with a bit of delay as I'll need to port things like the relocation mechanism in the Llama linker, in order to remain self-hosting. Thanks, Jeremy ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
On Sun, 8 Aug 2010 14:44:11 -0400, Jeremy Bem jere...@gmail.com wrote: On Sun, Aug 8, 2010 at 1:59 PM, Florian Weimer f...@deneb.enyo.de wrote: * Jeremy Bem: To support my research, I've developed an implementation (Llama Light) of the core Caml language. Modules, objects, labels etc are not supported (except for file-level modules). The system strongly resembles OCaml, however the completely rewritten typechecker is not only much smaller in terms of lines-of-code; it has a genuinely simpler design owing especially to the lack of first-class modules. How do you deal with strings (are they mutable?) and polymorphic equality (is it type-safe?)? Yes and no, respectively. In other words, nothing new here. Strings can be made immutable (in both Llama and OCaml) by disabling String.set in the standard library (the s.[i] - c construct is just sugar for a call to that function). And removing the other functions of String module which mutates strings (actually I've made an experiment in which I removed string mutability). Is there a better approach to polymorphic equality floating around? Type classes! -- Nicolas Pouillard http://nicolaspouillard.fr ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
On Sun, 08 Aug 2010 20:52:53 +0200, Florian Weimer f...@deneb.enyo.de wrote: * Jeremy Bem: Yes and no, respectively. In other words, nothing new here. Oh. I just happen to think that those two are very high on the list of things you want to fix once you can start with a clean slate. Is there a better approach to polymorphic equality floating around? Besides type classes? I'm not sure. It's probably possible to remove this feature from the language, with a little bit of syntactic overhead to pass around a matching comparison function. Yes for instance the very concise local opening notation comes in handy here: if Int.(x = 42) then ... else ... -- Nicolas Pouillard http://nicolaspouillard.fr ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
On Sun, Aug 8, 2010 at 4:53 PM, Nicolas Pouillard nicolas.pouill...@gmail.com wrote: On Sun, 08 Aug 2010 20:52:53 +0200, Florian Weimer f...@deneb.enyo.de wrote: * Jeremy Bem: Yes and no, respectively. In other words, nothing new here. Oh. I just happen to think that those two are very high on the list of things you want to fix once you can start with a clean slate. Is there a better approach to polymorphic equality floating around? Besides type classes? I'm not sure. It's probably possible to remove this feature from the language, with a little bit of syntactic overhead to pass around a matching comparison function. Yes for instance the very concise local opening notation comes in handy here: if Int.(x = 42) then ... else ... That's very nice. I don't think type classes are conservative enough for this project, but this comes very close indeed. I haven't really had a chance to explore OCaml 3.12 yet, as it came out while I was working on this, but I will give this serious consideration. -Jeremy ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
Is there a better approach to polymorphic equality floating around? Besides type classes? I'm not sure. It's probably possible to remove this feature from the language, with a little bit of syntactic overhead to pass around a matching comparison function. Yes for instance the very concise local opening notation comes in handy here: if Int.(x = 42) then ... else ... That's very nice. I don't think type classes are conservative enough for this project, but this comes very close indeed. I haven't really had a chance to explore OCaml 3.12 yet, as it came out while I was working on this, but I will give this serious consideration. This approach is very nice indeed, but to make it practical you have to have one of the two following features : - a more restricted form of open statement that does not blindly import *all* the module values - nested modules If you don't have any of these, you have to declare infix operators directly inside the module. You'd have a val (=) : int - int - bool in the int.ml file for example. That's notoriously painful to handle if you use the open statement : a bunch of open statements in a non-careful order and your infix operators become unusable because you don't know anymore where they come from. What you really need is some form of explicit open, à la Python or Haskell, such as from Int import (mod, of_char, to_char) instead of the full open : only a few identifiers are unqualified, and you still use Int.(=), Int.(+) instead of polluting the global namespace. The other way to solve the problem is to put the dangerous infix operators into a submodule, eg. Infix or Ops. You have a Int module with int-specific functions that are not likely to silently conflict with values of other modules, and an Int.Infix module meant to be used in that local open form : Int.Infix(x + 1 = 2). ___ 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] Cooperation Suggestion
Hi, Let me take the opportunity to introduce myself. My name is Kenneth Page and I am the admin of http://www.online-bg.net/ , nice to meet you. I just visited http://caml.inria.fr/ and I found it very compatible with my current ongoing projects. I have a selection of quality websites that I can offer you a link exchange with. I have number of ways to help your website get better search results. I hope my E-mail is in your interest and I will be glad to send you more details about my offer as I am sure our collaboration will gain positive results. Kenneth Page, http://www.online-bg.net kenn...@online-bg.net ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
On Sun, 8 Aug 2010 23:47:20 +0200, bluestorm wrote: Is there a better approach to polymorphic equality floating around? Besides type classes? I'm not sure. It's probably possible to remove this feature from the language, with a little bit of syntactic overhead to pass around a matching comparison function. Yes for instance the very concise local opening notation comes in handy here: if Int.(x = 42) then ... else ... That's very nice. I don't think type classes are conservative enough for this project, but this comes very close indeed. I haven't really had a chance to explore OCaml 3.12 yet, as it came out while I was working on this, but I will give this serious consideration. This approach is very nice indeed, but to make it practical you have to have one of the two following features : - a more restricted form of open statement that does not blindly import *all* the module values This is possible to do with Delimited Overloading (pa_do): http://pa-do.forge.ocamlcore.org/ - nested modules The other way to solve the problem is to put the dangerous infix operators into a submodule, eg. Infix or Ops. You have a Int module with int-specific functions that are not likely to silently conflict with values of other modules, and an Int.Infix module meant to be used in that local open form : Int.Infix(x + 1 = 2). This is possible to import the overloaded functions form a submodule but has to be done by hand for the moment because there is no consensus on what the name of the submodule should be. My 0.02€, C. ___ 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
Re: [Caml-list] interest in a much simpler, but modern, Caml?
On Sun, Aug 8, 2010 at 5:47 PM, bluestorm bluestorm.d...@gmail.com wrote: Is there a better approach to polymorphic equality floating around? Besides type classes? I'm not sure. It's probably possible to remove this feature from the language, with a little bit of syntactic overhead to pass around a matching comparison function. Yes for instance the very concise local opening notation comes in handy here: if Int.(x = 42) then ... else ... That's very nice. I don't think type classes are conservative enough for this project, but this comes very close indeed. I haven't really had a chance to explore OCaml 3.12 yet, as it came out while I was working on this, but I will give this serious consideration. This approach is very nice indeed, but to make it practical you have to have one of the two following features : - a more restricted form of open statement that does not blindly import *all* the module values - nested modules If you don't have any of these, you have to declare infix operators directly inside the module. You'd have a val (=) : int - int - bool in the int.ml file for example. That's notoriously painful to handle if you use the open statement : a bunch of open statements in a non-careful order and your infix operators become unusable because you don't know anymore where they come from. What you really need is some form of explicit open, à la Python or Haskell, such as from Int import (mod, of_char, to_char) instead of the full open : only a few identifiers are unqualified, and you still use Int.(=), Int.(+) instead of polluting the global namespace. I don't believe there is really any issue here. Certain modules are simply not intended to opened to be opened globally. This is already the case: witness the many standard library modules that define length, map, iter, etc. -Jeremy ___ 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] About compiling native code on windows platform
I have some program to compiling native code on windows platform. when I use the command: ocamlopt -ccopt -LC:/out/gtk/lib -I +lablgtk2 lablgtk2 lablgtk.cmxa gtkInit.cmx testgtk.ml -o testgtk.exe it display a fatal error like this: cannot find file libgtk-win32-2.0 error:error during linking how to solve this problem? thank you! -- I Love You Siren___ 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
