Re: [Caml-list] Value shadowing
On Wed, 13 Aug 2008 02:15:53 -0700 Brighten Godfrey <[EMAIL PROTECTED]> wrote: > I also find that style useful. Sometimes the type changes, but I > can recall useful cases where the type doesn't change, e.g., a > sequence of various operations on a list. Mock-up: > > let lst = generate_list_somehow () in > let lst = List.filter (fun x -> x > 0) in > let lst = List.sort compare lst in Agreed. I have a slightly different proposal than using return types: short pragmas for switching off specific instances of a warning. I always want as many warnings as possible switched on because I find them really useful. The problem is they are warnings for a reason: They don't ALWAYS represent errors. Once my code has a warning in it, the usefulness of warnings is greatly reduced as I'm less likely to spot the addition of another warning in the compiler output. If I could disable specific instances of a warning, which I've looked at and decided to ignore, I'd get the best of both worlds. > (* @disableshadowwarning *) > let lst = generate_list_somehow () in > let lst = List.filter (fun x -> x > 0) in > let lst = List.sort compare lst in > (* @enableshadowwarning *) No doubt, someone can think of a better syntax Regards, Jim ___ 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] Typeclasses in OCaml (Was: Haskell vs OCaml)
2008/8/14 Peng Zang <[EMAIL PROTECTED]>: > In Haskell you can write a function that takes anything that is "showable" (a > type class) and print it out. The sig would be something like (I'm mixing > OCaml and Haskell syntax here, but hopefully the point is still clear): Out of curiosity, are there any theoretical reasons why OCaml could not be extended with type classes? They are one of my favourite features of Haskell, and I think they would really improve OCaml. Things like the (=) operator in OCaml vex me. One of the big advantages of static typing and type inference is that stupid programmer errors are prevented at compile time. However, the (=) operator in OCaml is effectively meaningless for a lot of types, yet there is no way to prevent a programmer from accidentally calling it. One way to get around this would be to take away (=) and (==) and replace them with specific versions for each type (just like we already have (+) and (+.) etc) but this leads to really verbose code. Type classes solve this kind of problem very effectively. Regards, Jim ___ 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] Typeclasses in OCaml (Was: Haskell vs OCaml)
2008/8/14 Peng Zang <[EMAIL PROTECTED]>: > (=) : 'a -> 'a -> bool > > But instead: > > (=) : (#equatable as 'a) -> 'a -> bool > > where > > class type equatable = object >method equals : 'self -> bool > end > > > This gives all the advantages of static typing and type inference and prevents > stupid errors and it is meaningful for all types that it is implemented for. This doesn't answer my question at all. :) Is there any theoretical reason they couldn't added? The kind of answer I'm looking for is "There is no theoretical reason why not", or "This is impossible as it would cause typing in OCaml to become undecidable, due to interactions with other features of the OCaml type system which aren't present in Haskell." Though, to address your solution, I am of course aware of it, but it has what seem like big disadvantages: 1. Every value in OCaml would then have to be an object 2. Every comparison now requires a relatively expensive dynamic dispatch, when the correct function could be determined at runtime. 3. If I add a new operator that wasn't thought of by the language implementors, it can't be easily added to primitive values, without either subclassing all of them, or changing the definition in the standard library to add the new method. Regards, Jim ___ 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] Constructors are not functions
David Allsopp wrote: I think it would be possible to simulate the SML behaviour in OCaml using camlp4 (if you assume that for [type foo = Bar of int] that future unbound references to [bar] are interpreted as [fun x -> bar x] instead of an error) I believe this is already the behaviour under the revised syntax, so this is definitely possible. Regards, Jim -- Jim Farrand E-Mail/Jabber/Google-Talk/MSN: jim.farr...@gmail.com Phone number changed Jun 2009: Now ends 996 (Ask for the rest, delete the old one!) ___ 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
