On Wednesday 02 April 2008 10:59:24 Sylvain Le Gall wrote: > On 02-04-2008, salog <[EMAIL PROTECTED]> wrote: > >> module Add3Nativeint = Add3(Nativeint) > >> module Add3Int64 = Add3(Int64) > >> module Add3Int32 = Add3(Int32) > > > > I used C# for a while and this example reminds me generics in this > > language.
Yes. There is an important omission from .NET though: an interface for numeric types. Consequently, you cannot actually factor out the above commonality in C# using generics because these types do not share an interface. However, you can in F# because it provides an INumeric interface. This is the basis of F#'s vector and matrix types, the elements of which must implement the INumeric interface. > > But generics are more laconic: you have to only declare a name of > > generic type and then to indicate a type of treating object like this: > > List<string>; > > or > > List<int32>; OCaml gives you exactly the same functionality as generics but type inference means you never have to write <string> or <int32>. > Don't be mislead... Parametrized class (like the List<XXX>) in C++ (and > maybe in C#) are "text replacement". These are piece of crap and one of > the reason i stop coding using C++. In particular, it requires to > compile every time the same code (with some string replaced). You are talking about C++ templates, which are completely different. Salog was referring to .NET generics which are equivalent to parametric polymorphism in OCaml. Indeed, .NET generics were done by the creator of F#, Don Syme. > Module and functor in OCaml are not perfect but are far better than > this (BTW, this kind of thing is a direct legacy of the famous COBOL > "COPY ... REPLACING ..." -- C++ is somehow lagging 30 years behind OCaml). I think this is a bit unfair. Functors in OCaml incur a crippling performance penalty here because OCaml does not inline functions across functor boundaries. You're looking at an order of magnitude slowdown on integer addition! This makes the ability to factor primitive numeric types using functors practically useless in OCaml. The effect is compounded by OCaml's inability to handle many numeric types either not at all (e.g. int16, float32) or just very inefficiently (e.g. int8, int32, int64). Finally, you could use functional abstraction to achieve the same effect but this is also practically useless in OCaml because it does not support arbitrary inlining which is, ironically, exactly what you were saying. :-) C++ is no better, of course. But F# really does provide the best of both worlds with a variety of features: . A wealth of built-in types including int8, int16, int32, int64 and float32 that are efficient. . Typeful inlining of functions including higher-order functions to remove all costs associated with passing function arguments (which is slow in OCaml) without the hideous obfuscation of error messages impose by C++ templates. . Type specialization during JIT compilation, removing the run-time cost associated with polymorphism (which is slow in OCaml). > > Ideally I would imagine the solution in OCAML somehow wihout this > > declaring several similar functions where types of the argument are > > "encoded" in their names. > > Is it possible to declare functions with same names but with a > > different type of the argument, just as it's realized in C++? That is called function overloading and it is not possible in OCaml but it is available in a limited form in F#. > Polymorphic functions just like in C++... > > The answer is no. There is no way to do int without creating a variant > type that unify your type (MyInt32 of Int32.t | MyInt64 of Int64.t | > MyInt of int). > > Polymorphic function is just a syntactic sugar. Even if it seems cool, it > brings a lot of unnecessary complexity in your code (i.e. never being > sure of what function you are calling because of implicit type cast). Again, that is C++ specific. F# shows how you can augment an OCaml-like language with overloading to great effect. The benefits are quite specific though: numerical code benefits enormously from operator overloading but almost all other code sees no benefit. > I learn to live without it... And now i really don't want to go back to > this (having worked with legacy code and this kind of things told me > that application written with this syntactic sugar are very hard to > maintain). We have some of the world's largest OCaml and F# codebases having migrated from C++. I agree completely that OCaml is far better than C++ in practice for any non-trivial work. However, OCaml does leave room for improvement and, to date, the only competitive language is F# not least because it provides many of the features touched upon in this thread but without sacrificing the core features of OCaml. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ocaml-developer" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/ocaml-developer?hl=en For other OCaml forums, see http://caml.inria.fr/resources/forums.en.html -~----------~----~----~----~------~----~------~--~---
