[Caml-list] Interactive technical computing
Jon Harrop
Being a user of both OCaml and Mathematica, playing with the new F# language
from Microsoft and watching tutorial videos about VPython:
http://showmedo.com/videos/series?name=pythonThompsonVPythonSeries
has given me a lot of inspiration about interactive technical computing
environments. This class of applications is hugely useful for working
scientists and engineers because it lets you slice and dice your data in
interesting ways whilst also giving you visual throwback and even letting you
do some fancy visualisations.
For example, I'm in the process of updating my ray tracer language comparison:
http://www.ffconsultancy.com/languages/ray_tracer/index.html
and I'm using a mix of OCaml (to fire off compilation and execution commands)
and Mathematica (to dissect the results, compute verbosity using regexps and
plot graphs):
http://www.ffconsultancy.com/tmp/mathematica.png
Mathematica's equivalent of the OCaml top-level is called a notebook. It
provides expression input and result output, just like OCaml, but integrates
graphics, adds typesetting and lots of mathematical functions. However, it is
widely used for more general purpose programming despite being very slow.
Using F# from Visual Studio 2005 provides some of this functionality. The
following screenshots illustrate 2D and 3D graphics spawned from an F#
interactive session using a little of my own code and DirectX/ComponentsXtra:
http://www.ffconsultancy.com/tmp/fs_xygraph.png
http://www.ffconsultancy.com/tmp/fs_3dplot.png
For all non-trivials examples in F# it is necessary to spawn a separate thread
to handle the GUI of the visualization, or the GUI will hang when the
top-level is doing an intensive computation.
I think F# has a great future because of its ability to spawn visualizations
from a running interactive session. Expensive commercial offerings like
Matlab and Mathematica are ok when you're doing something they have built-in
(e.g. a Fourier transform) but when you're problem is not trivially
decomposed into their built-in operators (e.g. a wavelet transform), F# and
OCaml are typically 2-5x faster, and when you must resort to more general
purpose programming F# and OCaml are often 100x faster.
However, there is a lot of work to be done in getting competitive charting and
visualization tools into F# and I'm thinking that OCaml could benefit from a
joint venture here. Low-level routines would target DirectX in F# and OpenGL
in OCaml but high-level routines could be language and platform agnostic,
handling a scene graph that is essentially a typed version of Mathematica's
to provide much faster graphics and even interactive visualisation
(Mathematica is software rendered and not interactive!).
This raises several questions:
What OCaml programs currently allow OpenGL-based visualizations to be
spawned from the top-level?
Has anyone tried to write an IDE that mixes OCaml code with graphics?
Would anyone here be interested in a low-cost cross-platform technical
computing environment based upon the OCaml and F# languages?
Obviously I'm interested in this from a commercial perspective. That looks
easy for F# but not so easy for OCaml. Compiled OCaml+OpenGL code is not as
portable (between machines) as F#+DirectX. Also, I can sell F# DLLs and even
make the library available to other .NET languages (albeit with a
significantly less productive API).
Finally, I'd like to note that operator overloading is probably the single
biggest difference between my F# and OCaml code. The ability to apply + and -
to many types, particularly vectors and matrices, makes this kind of work so
much easier. Even if you have to add the odd type annotation. So I'd love to
see a compatible implementation of overloading introduced into OCaml.
I'd like to hear everyone's opinions on this as, it seems to me, we're sitting
on the foundations of a great technical computing system.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
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
Jim Miller
physicist I am frequently faced with the option of using an interactive tool
that supports graphics (PV-WAVE, IDL, R, and Matlab/Octave are very popular)
but is VERY slow or doing things in a fast but tedious language (C/C++ are
currently the rage with a few individuals that still do Fortran 9X).
Having an OCaml based language that combines a top level command line loop
that allows me to interactive explore data and develop scripts but that
allows me to compile those into something fast could be a very, very useful
tool. My particular domains are atmospheric photochemistry as well as
satellite mission planning and imagery exploitation. We tend to do a LOT
less with 3D visualizations and much more with traditional line, contour,
and scatter plots. We also do a lot of false color imagery.
The closest that I have come to this is a quick module that allows me to
spawn a gnuplot program and pass command strings, via a pipe. A few
functions to ensure that data is formatted properly and I have something
that's manageable.
I'd be interested in conspiring/planning on something in this space. It
would also be useful to see if there's a useful way to bridge this with R,
which is my current favorite language for doing statistical data analysis
and plot generation but it still suffers from the problems of speed.
> . What OCaml programs currently allow OpenGL-based visualizations to be
> spawned from the top-level?
>
> . Has anyone tried to write an IDE that mixes OCaml code with graphics?
>
> . Would anyone here be interested in a low-cost cross-platform technical
Erik de Castro Lopo
> Finally, I'd like to note that operator overloading is probably the single
> biggest difference between my F# and OCaml code. The ability to apply + and -
> to many types, particularly vectors and matrices, makes this kind of work so
> much easier. Even if you have to add the odd type annotation. So I'd love to
> see a compatible implementation of overloading introduced into OCaml.
I'm mainly a Linux guy so the chances of me getting up close and personal
with F# are exactly zero :-). However, I am interested in hearing about
the differences between F# and Ocaml wrt operator overloading. Care to
clue me (and everyone else) in?
Cheers,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Reality is just a crutch for people that can't handle CyberSpace!!"
- Hank Duderstadt
skaller
> I think that this would be a potentially fantastic application!
The question is whether you would get a sufficient grant to
actually pay for it.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Jim Miller
immediate question my sources would ask is "WHY?" when there are so many
other languages out there. The number of research scientists that I know of
that are asking for anything like this is exceedingly low.
On a side note, this is the most frustrating thing about the physics
community I work with. I'm involved at GMU in the COMPUTATIONAL physics
department. We are supposed to be applying cutting edge technology to
problems and yet the application of new languages gets VERY little traction
there. Every argument I've ever made to the faculty there about the ability
for an O'Caml type language to improve our productivity and confidence in
the answers it produces tends to fall on deaf ears.
Of course, I am just a student there, but I'm also an experienced (15 years)
professional programmer that might know a thing or two about programming ...
sigh.
Most research physicists that I work with (NRL in particular) are worse.
skaller
> I have no doubt that nobody would give you a grant do to this.
That isn't the question. If Harrop developed it and sold it
for $US 5000.00 would your grant cover it?
Harrop can estimate the market by surveying researchers
and finding what their financial situations could support.
One grant isn't expected to cover the whole development!
BTW: I did some computational atmospheric photochemistry
in the 1970s, looking at ozone and effects of SSTs,
but mainly studying the socio-political role of
funding of those studies .. (most of the money came
from people with vested interests :)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
skaller
> Ah, I misunderstood ...
>
> I would say that with the researchers I know of and work with, the
> answer would be no. $5K these days is a lot of money for most of the
> scientists I'm working with, to the point that they're actually using
> Octave and R (free) and moving away from buying their analysis
> packages.
So how about $500? I just picked a random number out of the air.
Don't forget .. the general framework Harrop describes isn't
restricted to the science market, certainly not just atmospherics.
Although with the current hype about global warming, atmospheric
modelling might get additional funds pumped in .. :)
Jim Miller
reasonable than the thousands, obviously :-)
What's I think is the interesting point about this discussion is "What are
the hurdles toward acceptance of any new language, scripting or not, into a
given community?" Obviously OCAML and the ML languages have deeply
penetrated some markets but haven't even dented others. There have been
lots of papers, studies, and discussion written on this (
lambda-the-ultimate.org has many of them archived) so that's probably
something for a different thread to be read wearing flame-retardant
underthings.
Professionally I'm in a community that could deeply benefit from the type of
language that would allow for scripting, data analysis, etc, that could then
be directly compiled into tight executable code. While the barriers to
entry to that market could be high, I'm in a position where I could see
selling it. I could actually get really excited about this.
Probably something to take off list if this is something to pursue
On 3/7/07, skaller <ska...@users.sourceforge.net> wrote:
>
Andrej Bauer
> I'd like to hear everyone's opinions on this as, it seems to me, we're sitting
> on the foundations of a great technical computing system.
I would be very much interested in participating in an effort to develop
an interactive environment for ocaml that surpases the currect toplevel.
I have in mind a toplevel that can be used *easily* as part of an
application, has support for line-editing, fancy typesetting and
graphics display. Intelligent pretty-printing would probably be a
natural consequence of such desires (so that we graphics is just a fancy
pretty printer).
As far as symbolic computation and manipulation of mathematical
expressions is concerned: I am not sure that overloading operators and
doing other kinds of violence to ocaml is the right way to go. It might
be better to have instead a specific language for symbolic computation
_on top_ of ocaml. The symbolic computation language would swallow the
horrible and nasty notation that is used in mathematics, digest it, and
pass it on to ocaml.
Best regards,
Andrej
Gerd Stolpmann
> On Wed, 2007-03-07 at 22:19 -0500, Jim Miller wrote:
> > Ah, I misunderstood ...
> >
> > I would say that with the researchers I know of and work with, the
> > answer would be no. $5K these days is a lot of money for most of the
> > scientists I'm working with, to the point that they're actually using
> > Octave and R (free) and moving away from buying their analysis
> > packages.
>
> So how about $500? I just picked a random number out of the air.
>
> Don't forget .. the general framework Harrop describes isn't
> restricted to the science market, certainly not just atmospherics.
>
> Although with the current hype about global warming, atmospheric
> modelling might get additional funds pumped in .. :)
Hehe, scientists and business...
Here is a way that could work (because it already worked for me):
- Make the product open-source (this is a door-opener!)
- Make a good web site, with add-ons etc.
- Announce yourself as the guy who increases the productivity of the
highly-paid scientists, and offer your consultancy services
I say that because it is not so easy to sell licenses for money (high
costs to even be recognised as a product vendor). It is not so easy to
get rich these days...
Gerd
--
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
ge...@gerd-stolpmann.de http://www.gerd-stolpmann.de
Phone: +49-6151-153855 Fax: +49-6151-997714
------------------------------------------------------------
Jon Harrop
> I'm mainly a Linux guy so the chances of me getting up close and personal
> with F# are exactly zero :-).
Actually the F# compiler and tools are freely available and run under Mono (on
Linux). I've had a little play with C# from Mono and was really impressed,
but I haven't tried F# from Mono yet.
> However, I am interested in hearing about
> the differences between F# and Ocaml wrt operator overloading. Care to
> clue me (and everyone else) in?
I can try. Basically, overloading is very popular in languages like C++ and
C#. Programmers even overload functions and constructors in those languages.
General overloading doesn't sit well with type inference because the code no
longer conveys a sufficient amount of type information to resolve the
overload and infer all of the types. So general overloading is bad for type
inferred languages like F# and .NET APIs that use overloading make for uglier
F# code that uses them.
However, operator overloading (i.e. overloading symbols) makes numerical code
so much easier to read that it is worth sacrificing some inference for it.
The arithmetic operators default to int:
> let add a b = a + b;;
val add : int -> int -> int
So you keep OCaml compatibility. But the operators can be applied to floats:
> 1.1 + 2.2;;
val it : float = 3.3
SML provides the same capability up to this point but F# allows the
overloading to be extended. It already works for vectors:
> let a = vector [1.; 2.; 3.] and b = vector [2.; 3.; 4.];;
val a : vector
val b : vector
> a + b;;
val it : vector = [3.; 5.; 7.]
and you can even extend it to work on your own types by augmenting the type
constructor with static member functions:
> type expr =
| Int of int
| Add of expr * expr
| Mul of expr * expr with
static member ( + ) (f, g) = Add(f, g)
static member ( * ) (f, g) = Mul(f, g)
end;;
Then you can even use + to add symbolic expressions:
> Int 3 + Int 4;;
val it : expr = Int 3 + Int 4
However, the operator must always be statically resolved, so the code is
always fast because it doesn't incur run-time dispatch.
That's the basic idea. There are some subtlties, like is the type of
+ 'a->'a->'a or 'a->'b->'c?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Jon Harrop
> You probably know it already, but it is very easy to spawn opengl
> graphics directly from the toplevel using sdl. Then if you use the
> toplevel inside emacs, you get something very similar to the screenshots
> you had.
>
> And since you are into screenshots, here is one :-)
>
> http://www-fourier.ujf-grenoble.fr/~svungoc/prog/oplot/toplevel_plot.png
This is just the kind of thing that I'd like to hear about!
How exactly do you do that? Can you post a complete working example?
Looks great... :-)
Francesco Bellomi
you might find Vital and Pivotal interesting:
http://www.cs.kent.ac.uk/projects/vital/
http://www.cs.kent.ac.uk/projects/pivotal/
they both are document-centric haskell environments, similar to
Mathematica's notebooks.
Francesco
Christophe TROESTLER
I certainly am interested in such a project (even to contribute though
my time is limited).
> On Thu, 8 Mar 2007, Jon Harrop <j...@ffconsultancy.com> wrote:
> >
> > I think F# has a great future because of its ability to spawn
> > visualizations from a running interactive session. [...]
I have written a Gnuplot module that allows that. Here is the
compulsory screenshot :)
ftp://ftp.umh.ac.be/pub/ftp_san/Ocaml-gnuplot.png
Code :
# load "gnuplot.cma";;
# module G = Gnuplot.Array;;
# let g = G.init G.X;;
# G.box g;;
# G.pen g 1;;
# G.fx g sin (-1.) 20.;;
It definitely needs some further work but I do not have much time for
that now. Also, I need to be able to plot data defined on triangular
meshes (and non square domains) and Gnuplot does not allow that so I
am looking for a solution viable for a longer term.
Maybe a wrapper for VTK (http://www.vtk.org/) could be a good start --
and trivially solves the portability issues.
> > Obviously I'm interested in this from a commercial
> > perspective. That looks easy for F# but not so easy for OCaml.
> > [...]
On Thu, 08 Mar 2007, Gerd Stolpmann <in...@gerd-stolpmann.de> wrote:
>
> - Make the product open-source (this is a door-opener!)
Unless it is open source, I would not use such a product. Having it
open source is the only waranty for long term security. I would not
develop codes that cannot run 5 years later because, say, you
unfortunately went to bankruptcy... or you became crazy and ask 10
times more money... or...
> > Finally, I'd like to note that operator overloading is probably
> > the single biggest difference between my F# and OCaml code. The
> > ability to apply + and - to many types, particularly vectors and
> > matrices, makes this kind of work so much easier.
That would not completely remove the problem of adding some operators
but I was thinking of a possibly generic solution using Camlp4:
writing [X.(a + b)] where [X] is a module would become [X.add a b].
Now for matrices, one still needs + (for matrix addition), * (for
matrix multiplication) and, say, .* (for scalar product). So to be
generic, one needs to be able to specify a set of operators (with
precedences) and a way to transform an AST of that mini language into
Caml code (that would possibly allow some optimisations, analysing the
expression at compile time to reduce de number of intermediate
matrices allocated). A slicing notation also needs to be developed,
say [a.{1, 2:3:7}], as well as a good ASCII pretty printer for
matrices (they must be bigarrays to be able to use interesting
libraries).
Cheers,
ChriS
Robert Fischer
> so much easier to read that it is worth sacrificing some inference for it.
>
Unless, of course, you like to know what it is you're actually doing.
It's bad enough trying to figure out what "+" means in an overloaded environment with nominal typing. With duck typing, it's a mess, and it's a mess that both you and the compiler have to work hard to figure out.
I highly suggest checking out the Programmer-to-Programmer book on C# and their conversation about operator overloading. They do a nice job documenting just why it's such a dangerous tool in the toolbox.
~~ Robert.
Jon Harrop
> > However, operator overloading (i.e. overloading symbols) makes numerical
> > code so much easier to read that it is worth sacrificing some inference
> > for it.
>
> Unless, of course, you like to know what it is you're actually doing.
As overloads are statically resolved in F#, you just hover the mouse to find
out which overload is being used. So you know immediately what the code is
actually doing.
> I highly suggest checking out the Programmer-to-Programmer book on C# and
> their conversation about operator overloading. They do a nice job
> documenting just why it's such a dangerous tool in the toolbox.
Well, I've spent the past few months writing F# code full time and I can
definitely say that this aspect of F# is better. Of course, you'll have to
read F# for Scientists to find out why. ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Francesco Bellomi
> Actually the F# compiler and tools are freely available and run under Mono (on
> Linux). I've had a little play with C# from Mono and was really impressed,
> but I haven't tried F# from Mono yet.
How do Mono and the .NET VM compare, performance-wise?
Francesco
Roland Zumkeller
operator overloading?
--
http://www.lix.polytechnique.fr/~zumkeller/
Brian Hurt
> Wasn't there a more or less good reason for OCaml *not* to support
> operator overloading?
>
Yes. Ocaml has modules and functors. IMHO, any time you thing "boy,
it'd be really nice to use operator overloading here", you should use a
module and a functor instead.
I have a long post on this topic comming soon, but for now:
1) Functors state up front what operators need to be provided to the
code. This is less of a problem with purely numeric code, but I've yet
to see a language that allowed operator overloading and then exercised
the restraint and kept them only on numeric types. At which point,
having it stated in the .mli file what operators are needed, and having
it checked that you're actually providing them, is nice.
2) Functors allow for more flexible semantics as to what operations need
to be provided, so operations that aren't obviously operators can be
required as well- for example, Newton's method likes having an "equals
within epsilon" function, or norm operation, neither of which are really
operators.
3) Functors allow for more types- for example, if you're doing Newton's
method on complex numbers, the type of an epsilon, or the type of a
norm, is not a complex number, but instead just a real. Or if you're
doing Newton's method on vectors, the type of the derivitive is a
matrix. These are easy to express this with functors, hard to do with
operator overloading.
4) Functors make it easier to swap in alternate implementations of
various operations. For example, doing Newton's method on vectors, you
end up needing to calculate b/A, where A is a matrix and b a vector.
This is easy enough to translate as solving Ax=b, you standard linear
system. It's nice to be able to switch out which linear system solver
you want to use with functors, rather harder with operator overloading.
Brian
Jon Harrop
> I have written a Gnuplot module that allows that. Here is the
> compulsory screenshot :)
>
> ftp://ftp.umh.ac.be/pub/ftp_san/Ocaml-gnuplot.png
Great stuff. Thanks. :-)
> Unless it is open source, I would not use such a product. Having it
> open source is the only waranty for long term security. I would not
> develop codes that cannot run 5 years later because, say, you
> unfortunately went to bankruptcy... or you became crazy and ask 10
> times more money... or...
I can't justify the time unless I get to sell something. :-)
> > > Finally, I'd like to note that operator overloading is probably
> > > the single biggest difference between my F# and OCaml code. The
> > > ability to apply + and - to many types, particularly vectors and
> > > matrices, makes this kind of work so much easier.
>
> That would not completely remove the problem of adding some operators
> but I was thinking of a possibly generic solution using Camlp4:
> writing [X.(a + b)] where [X] is a module would become [X.add a b].
> Now for matrices, one still needs + (for matrix addition), * (for
> matrix multiplication) and, say, .* (for scalar product). So to be
> generic, one needs to be able to specify a set of operators (with
> precedences) and a way to transform an AST of that mini language into
> Caml code (that would possibly allow some optimisations, analysing the
> expression at compile time to reduce de number of intermediate
> matrices allocated). A slicing notation also needs to be developed,
> say [a.{1, 2:3:7}], as well as a good ASCII pretty printer for
> matrices (they must be bigarrays to be able to use interesting
> libraries).
I don't think you can obtain F#'s brevity/clarity that way because you need to
affect type inference and macros can't do that.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Jon Harrop
> Roland Zumkeller wrote:
> > Wasn't there a more or less good reason for OCaml *not* to support
> > operator overloading?
>
> Yes. Ocaml has modules and functors. IMHO, any time you thing "boy,
> it'd be really nice to use operator overloading here", you should use a
> module and a functor instead.
For me, operator overloading is about clarity. In the absence of operator
overloading, you cannot regain the lost clarity using modules and functors.
This is one of the two things I missed when I moved from C++ to OCaml:
operator overloading and template metaprogramming for low-dimensional vector
and matrix operations. The latter can be addressed by autogenerating code.
The former cannot be addressed in the current OCaml.
For example, I often define +| for vectors, +|| for matrices, *| for
scalar-matrix multiplication, *|| for vector-matrix and *||| for
matrix-matrix. I also want to support complex numbers and symbolic
expressions and I don't particularly want to remember and document 50 numeric
operators, nor explain their existence to my customers and I certainly don't
appreciate reading expressions written in this syntax.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Robert Fischer
> scalar-matrix multiplication, *|| for vector-matrix and *||| for
> matrix-matrix. I also want to support complex numbers and symbolic
> expressions and I don't particularly want to remember and document 50 numeric
>
Which is exactly my point. You should have to document all that, because they are genuinely different operations. You have these operations, so why shouldn't you document them? Or, better yet, abstract them and organize them. By using operator overloading, you're sweeping under the rug genuine complexity -- something that my surprise later developers!
When I see "+", I want to know what that means. With operator overloading, I don't know. An IDE might help me out there, but that's just polishing a genuine ding on code readbility and maintainability. Why should I have to rely on an IDE to make sense of my code?
If I have a typing issue in my code, I want the compiler balk at where the problem is. The best I can hope for with operator overloading is that the result type is caught through a failure of duck typing shortly down the pipeline -- but that very safety would is undermined if "down the pipeline" also uses lots of operator overloading.
I'm very sure that you can code with operator overloading and be productive. The person writing the code probably even feels like it's a productivity and readability boon. But I see maintainability as a big problem here. As far as I'm concerned, if two things do different things, they should have different names. You can give them funny names like "+|", but it should still be different names.
~~ Robert.
Michael Hicks
relationship between ML modules and Haskell type classes. The former are
really good for organizing your namespace and making dependencies and
operations explicit. The latter are really good at (disciplined) operator
overloading (which is convenient as many here have argued). The paper looks
at how the two can be combined (essentially, operator overloading is
implicit functor instantiation), so you can have the best of both worlds.
Now someone just needs to implement it for OCaml ...
Modular Type Classes.
Derek Dreyer, Robert Harper, and Manuel M.T. Chakravarty.
In 2007 ACM SIGPLAN Symposium on Principles of Programming Languages
http://ttic.uchicago.edu/~dreyer/papers/mtc/main-short.pdf
http://ttic.uchicago.edu/~dreyer/talks/popl07.ppt
-Mike
Christophe TROESTLER
I understand that, that why I put Gerd's quote first.
> I don't think you can obtain F#'s brevity/clarity that way because
> you need to affect type inference and macros can't do that.
No but macros can locally change what '+' means. With some Camlp4
hackery and using the Vec.t type of Lacaml (which is a shorthand for
(float, Bigarray.float64_elt, Bigarray.fortran_layout)
Bigarray.Array1.t), your F# example could look :
# let a = {| 1.; 2.; 3. |} and b = {| 2.; 3.; 4. |};;
val a : Vec.t = {| 1.; 2.; 3. |}
val b : Vec.t = {| 2.; 3.; 4. |}
# Vec.(a + b);;
- : Vec.t = {| 3.; 5.; 7. |}
Of course, when mixing vectors and matrices, we will not be able to
stay with only + and * but I am not sure that having to put type
annotations will compare favorably to put the expression in Mat.(...)
and inventing a _few_ additional operators.
Moreover I think that, in some respects, it is even better than
overloading! For example if you write
# Vec.(a + b + c)
then Camlp4 could generate code that only needs to create 1 temporary
vector to hold the result instead of 2 (as is the case in F#).
Cheers,
ChriS
Brian Hurt
>On Thursday 08 March 2007 17:54, Brian Hurt wrote:
>
>
>>Roland Zumkeller wrote:
>>
>>
>>>Wasn't there a more or less good reason for OCaml *not* to support
>>>operator overloading?
>>>
>>>
>>Yes. Ocaml has modules and functors. IMHO, any time you thing "boy,
>>it'd be really nice to use operator overloading here", you should use a
>>module and a functor instead.
>>...
>>
>>
>
>For me, operator overloading is about clarity. In the absence of operator
>overloading, you cannot regain the lost clarity using modules and functors.
>
>
Hmm. My experience from C++ was that operator overloading results in a
net *loss* in clarity of the code. For every time I've seen operator
overloading done correctly, I've seen it abused at least twice, probably
more often. And this is even ignoring the use of << and >> in IO. By
abused, I mean "used in a way that violates the numerical implications
of the operator".
There are also the case of bugs introduced by operator overloading. For
example, in C++, this sucker has bitten me:
int i = 10;
cout << i << 2;
The problem here is the two different meanings of <<.
Brian
Brian Hurt
>This discussion reminds of a paper that appeared at POPL 2007 about the
>relationship between ML modules and Haskell type classes. The former are
>really good for organizing your namespace and making dependencies and
>operations explicit. The latter are really good at (disciplined) operator
>overloading (which is convenient as many here have argued). The paper looks
>at how the two can be combined (essentially, operator overloading is
>implicit functor instantiation), so you can have the best of both worlds.
>
>
The reason type classes were implemented in Haskell was as a sane way to
implement a generic equality operator. Myself, I question the need for
a generic equality operator.
Brian
Tom
>
>
> When I see "+", I want to know what that means.
>
I disagree and I couldn't disagree more. In mathematics, we're perfectly ?!?
using + for integer, float, complex, vector and matrix addition (and the
combinations of them) and * for integer, float, complex, vector, vector and
scalar, and matrix multiplication. One who doesn't understand what the
"code" - mathematical notation - means should blame oneself for not
understanding the algorithm, not the "designer" for making the "language" -
mathematical conventions - unappropriate.
Albeit Brian Hurt's comment about operator overloading making more harm than
good in C++, I believe that overloading simply has to be used appropriately
- it's like saying pointers are bad because they can introduce memory leaks
and null references, and division is bad because it can raise
Division_by_zero exceptions.
Like a saying for magic goes, "There is no black magic or white magic, there
is only magic. It's classification depends on the intentions of the caster!"
Any tool given to a programmer can be used either to his advantage or
disadvantage. Even in the "best" language, a stupid programmer will programm
poor algorithms, so there is no point protecting the programmer from himself
(or herself).
Hence, one can hardly say overloading (in general, not only operator
overloading) is bad in C++. If designed carefuly and mantained with a bit of
common sense, it can result in enormous productivity gain. And, how often
does it happen that you don't know what a particular operation means in a
three-lines-long numerical calculation involving vectors, floats and
matrices? Anyhow, if you DID get lost, then you would equally lose yourself
in a mess of *|, +\, %, -| and /. operators. You don't want OCaml be named
LISO - Lost In Superfluous Operators.
I believe that operator overloading an d overloading in general can result
in great productivity and readability gain. Also, they can improve
polymorphism. For example, does it matter if you can't figure out the type
of a in length a? Actually, it doesn't - it could be a list, an array, a
dynarray, a train or a snake - as long as it "fits" algorithmically, it can
be anything.
- Tom
Richard Jones
> What's I think is the interesting point about this discussion is "What are
> the hurdles toward acceptance of any new language, scripting or not, into a
> given community?" Obviously OCAML and the ML languages have deeply
> penetrated some markets but haven't even dented others. There have been
> lots of papers, studies, and discussion written on this (
> lambda-the-ultimate.org has many of them archived) so that's probably
> something for a different thread to be read wearing flame-retardant
> underthings.
I'm currently contributing to a 45KLOC C library which I'm sure would
be about 10 times smaller if written in a reasonable language.
Putting aside the obvious cultural resistance to using a sensible
language for this project, there is one technical hurdle: It needs to
compile into a DLL which can be linked to other programs (in C and
other languages). I can't generate such code using ocamlopt, at least
not without using unsupported out-of-tree extensions.
Rich.
--
Richard Jones
Red Hat
Robert Fischer
> language for this project, there is one technical hurdle: It needs to
> compile into a DLL which can be linked to other programs (in C and
> other languages). I can't generate such code using ocamlopt, at least
> not without using unsupported out-of-tree extensions.
>
After all, Java and C# aren't intended to be used like that, yet they
certainly have wide-spread adoption.
I suppose there is gcj for Java, but that's not in 99+% of Java
development, and I'm not sure that will give you a lib at the end of the
day. I don't know of an equivalent for that in C# -- in all the C#
development I've done, we've never even considered it.
~~ Robert.
Vu Ngoc San
> How exactly do you do that? Can you post a complete working example?
>
> Looks great... :-)
>
Thanks :-)
The idea is that sdl (contrary to glut or lablgtk2), does not have a
"main loop": so you can write your own. This allows you to open an
opengl window from the toplevel, and when you quit your mainloop, you
get back nicely to the toplevel. You can even let the window open when
you are back to toplevel, but then the graphics are not updated anymore.
Nice enough: you can later update the sdl window (no need to close it
and open another one !).
If you really need interaction in the window and in the toplevel at the
same time, you can launch the sdl mainloop in a separate thread. It
really works. But I wouldn't try to open two sdl windows at the same
time (??).
I don't have the courage -- and time -- to give you a "working example"
(see below) but the initialisation is like this:
Sdl.init [ `VIDEO ];
Sdlvideo.set_video_mode !window_width !window_height [ `DOUBLEBUF ;
`OPENGL ; `RESIZABLE]);
Sdlwm.set_caption "Oplot - SDL Window" "";
Then you can issue any openGL command you wish. Even from the toplevel !
You can also use Sdlttf to handle any ttf font.
....
Now, since you sort of asked for it, here it is:
I have written a small graphics library that does all of this. But this
is my first ocaml program, first use of openGL etc.. so I'm not
particularly proud of it. It is quite messy, and in a state of perpetual
development. You can find a (not so recent) version at
http://www-fourier.ujf-grenoble.fr/~svungoc/prog/oplot/index.html
This lib is actually useful (to me) because you can insert LaTeX
formulas and export directly to xfig (or postscript). It produces
postscript of better quality than maple :-)
There is a (very recent) GUI for this at
http://www-fourier.ujf-grenoble.fr/~svungoc/prog/goplot/index.html
which uses lablgtk2 and launches sdl in a separate thread... (yep. my
first use of GTK and of threads.. don't be too harsh if you read my
code... -:) ). However, and even though I'm not a programmer (I do this
for learning ocaml during my spare time), I'd be happy to have some
feedback. There is a package with precompiled binaries that works on at
least three linux machines :-)
San
Brian Hurt
>
> Albeit Brian Hurt's comment about operator overloading making more
> harm than good in C++, I believe that overloading simply has to be
> used appropriately - it's like saying pointers are bad because they
> can introduce memory leaks and null references, and division is bad
> because it can raise Division_by_zero exceptions.
>
So maybe we should introduce pointers into Ocaml?
Brian
Michael Vanier
with safe languages. I see no such concern with respect to operator
overloading, though there are certainly many ways in which it complicates the
language.
This is one of those never-ending arguments that will never get settled to
anyone's satisfaction; it's a matter of personal preference. Why don't we start
arguing about static versus dynamic typing while we're at it?
Mike
Ian Zimmerman
>
>
> On 08/03/07, Robert Fischer <RFis...@roomandboard.com> wrote:
> >
> > When I see "+", I want to know what that means.
> >
>
> I disagree and I couldn't disagree more. In mathematics, we're perfectly ?!?
> using + for integer, float, complex, vector and matrix addition (and the
> combinations of them) and * for integer, float, complex, vector, vector and
> scalar, and matrix multiplication. One who doesn't understand what the
> "code" - mathematical notation - means should blame oneself for not
> understanding the algorithm, not the "designer" for making the "language" -
> mathematical conventions - unappropriate.
>
I agree with Robert and the analogy with maths notation only reinforces that:
when I was a student of maths, I frequently cursed the authors of
papers I was reading for using notation without definition. Of
course, it was perfectly clear to someone seasoned in the area of the
paper, because the notation was conventional - but a puzzle for a
newbie.
Fernando Alegre
> For me, operator overloading is about clarity. In the absence of operator
> overloading, you cannot regain the lost clarity using modules and functors.
I often use the poor man's local operator overloading already built into
the core OCaml:
let result =
let (+) = Vector.add and ( * ) (x:int) (v:Vector.t) = Vector.scalarmul x v
in 3 * a + 2 * b
This makes overloading local and explicit, and at the same time makes
expressions clear. I do not miss implicit overloading.
Fernando
Till Varoquaux
Instead of proving once again Godwin's law we might want to use
constructive criticism (even though I also tend to flame more than my
share)...
There have been many articles relating type classes and ML module
system. Lambda the Ultimate has link to quite a share of them.
Swapping type classes for modules forces you to be more explicit and
verbose. Indeed you would have to wrap your code in a functor whenever
you want ad-hoc polymorphism (aka overloading) to occur. This can
prove quite cumbersome. Haskell relies heavily on type classes, monads
would be much more painful if you had to wrap them in a functor.
Overloading, however, does come with a cost: the compiler cannot get
rid of all type information: sometime (e.g. separate compilation) the
right monomorphic function can only be done dynamically.
G'Caml brings extensional polymorphism (types as first class values)
to OCaml. Extensional polymorphism allows run time type introspection
thus allowing overloading... whether you like it or not is a matter
of personal taste.
Till
P.S. FYI I happen to like type classes and exceptions. I do know there
are also good reasons not to and I respect other opinions.
skaller
> Roland Zumkeller wrote:
>
> > Wasn't there a more or less good reason for OCaml *not* to support
> > operator overloading?
> >
> Yes. Ocaml has modules and functors. IMHO, any time you thing "boy,
> it'd be really nice to use operator overloading here", you should use a
> module and a functor instead.
Unfortunately you often cant do that easily:
* functors don't scale to separate compilation
* separate compilation doesn't support inter-unit recursion
* functors have a huge book-keeping overhead
(I mean syntactic overhead, not performance overhead)
* functors are hard to combine
The first two issues are implementation problems rather than
intrinsic to the language in the abstract.
The book-keeping problem is a consequence of the fine grained
control functors provide, compared with say Haskell typeclasses.
The combination problem is best characterized by an expert.
A lot of the time you want a data functor, not a module
functor, and higher order data functors (functorial
polymorphism) aren't available in Ocaml.
For example if you have some container you just want
to fold over it, which means you want a polyadic fold.
Module functors help *define* a fold which is polymorphic
over signature arguments, but don't provide polyadic usage.
Although the mechanism used in C++ is unsound, C++
does provide polyadic programming, and in that sense
is way ahead of Ocaml and Haskell. Despite the unsoundness,
generics in C++ usually 'just work anyhow'.
However .. and Harrop "interactive" crowd note .. functors
do provide one advantage. Because of the mandatory
book-keeping they're amenable to use of a Form based GUI/IDE
to assist in definition:
Functor Hashtbl
key | <instantiating type here>
compare | < defn here>
hash | <defn here>
[That's supposed to be a form where the signature is listed in
a column format, and the programmer just fills in the
definitions]
I would probably hate that BUT it would sure help noobs learn
to use first order functors.
In fact you could use a little cheat .. and call them
static classes, and tell people it's an Ocaml kind of OO ..
(Haskell does this little cheat .. it makes typeclasses
very easy to explain to OO people).
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Robert Fischer
cake and Jon eat it, too. :D
~~ Robert.
-----Original Message-----
From: caml-lis...@yquem.inria.fr
[mailto:caml-lis...@yquem.inria.fr]On Behalf Of Fernando Alegre
Sent: Thursday, March 08, 2007 4:25 PM
To: Jon Harrop
Cc: caml...@yquem.inria.fr
Subject: Re: [Caml-list] Operator overloading
On Thu, Mar 08, 2007 at 07:40:42PM +0000, Jon Harrop wrote:
> For me, operator overloading is about clarity. In the absence of
operator
> overloading, you cannot regain the lost clarity using modules and
functors.
I often use the poor man's local operator overloading already built into
the core OCaml:
let result =
let (+) = Vector.add and ( * ) (x:int) (v:Vector.t) =
Vector.scalarmul x v
in 3 * a + 2 * b
This makes overloading local and explicit, and at the same time makes
expressions clear. I do not miss implicit overloading.
Fernando
_______________________________________________
skaller
> When I see "+", I want to know what that means. With operator overloading, I don't know.
This argument is fallacious: When you see + you know it means addition
of whatever argument types are used.
Addition is well understood. The structure of the types is not
distinct.
The problem is that Ocaml doesn't provide sufficiently powerful
system to easily encapsulate this structure.
Addition is a bad example because it's somewhat questionable.
It is clearer if we talk of map, fold, and other such operations
which are clearly polyadic operators.
Overloading eases the burden of a weakness in the language,
not providing polyadic map and fold.
In fact Ocaml functors just provide overloading, because they
only work for finite manual instantiations.
They don't provide genunine polyadic programming.
FISh 1 is a polyadic array programming language, you can
do algorithms which are independent of rank
(number of dimensions). In that language, map and fold
only need ONE definition and then work on all data types.
BOTH Ocaml functors and overloading are just hacks to
work around the lack of ability to properly express
higher order natural transformations.
C++ provides polyadic behaviour: the whole of STL
is based on it, it just doesn't do it the right way.
The thing to understand is that a lot of programming
is experimental and/or loose: a lot of code is actually
written in dynamically typed scripting languages.
For systems like Ocaml, you need a mix of sloppiness
and heavy typing, because unless you're implementing
a well understood mathematical formalism, too much
formality and abstraction just gets in the way.
For example if you were implementing a C++ compiler in Ocaml
I'm going to bet you'd want plenty of space to fiddle with
your representations and concepts, because you don't quite
know what it is you're actually implementing.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
skaller
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages). I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
> >
> I don't think this is a real hurdle to general adoption of a language.
It is in fact an utter and complete show stopper.
I've spent 6 years developing Felix precisely to solve this
problem: a high level language that can generate shared libraries
which can use and be used by other shared libraries.
Ocaml is great for stand-alone programs but a significant
fraction of software development is library building,
and Linux distros such as those based on Debian provide
a library component model which demands dynamic linkage
so the components can be upgraded without end user recompilation.
I expect this will eventually be solved too.
> After all, Java and C# aren't intended to be used like that, yet they
> certainly have wide-spread adoption.
They don't make binary shared libraries
because the architecture is a virtual machine driven by
bytecode .. they DO make dynamically linkable bytecode
libraries.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
skaller
> If you really need interaction in the window and in the toplevel at the
> same time, you can launch the sdl mainloop in a separate thread. It
> really works.
No it doesn't. It works on Linux, but not on Windows.
Messages on Windows go to the thread that creates the
window, and fetches are done by default on the current
thread's message queue. X maintains a queue per
process, so it works on Linux (but be careful because
even re-entrant X isn't really re-entrant).
SDL has a serious design bug: it can't be used as a library,
it insists on providing the mainline (you can hack around
this though). On Linux, you don't have to do this because
the SDL mainline does nothing.
OpenGL has an even more serious design bug: contexts
are implicit. This is extremely bad design: it was
designed to work with serial code and optimise use
of a single video card.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Tom
>
>
> BOTH Ocaml functors and overloading are just hacks to
> work around the lack of ability to properly express
> higher order natural transformations.
Hm... indeed, but for some operations, you cannot provide a single, general
definition - say for length operation, or for * (* is very different when it
comes to scalars, vectors and matrices - not even the same axioms hold). I
believe that the basic operations should be implemented using overloading
(actually, some smart overloading that would allow both static and
(seemingly) dynamic resolving) and then polyadic operations be built on top
of that.
For systems like Ocaml, you need a mix of sloppiness
> and heavy typing, because unless you're implementing
> a well understood mathematical formalism, too much
> formality and abstraction just gets in the way.
>
> For example if you were implementing a C++ compiler in Ocaml
> I'm going to bet you'd want plenty of space to fiddle with
> your representations and concepts, because you don't quite
> know what it is you're actually implementing.
>
I have a feeling what you say here is important, yet I don't quite
understand it... Can you clarify it ang give an example? And how (in your
opinion) can this problem be solved?
- Tom
ol...@pobox.com
This message illustrates the translation of Haskell98 non-constructor
classes to OCaml, which gives us bounded polymorphism and a sort of
polymorphic recursion in OCaml.
It has to be remarked first that overloading is quite a complex issue:
please see `A Theory of Overloading' by Stuckey and Sulzmann (TOPLAS
2005) for many gory details. The issue of the type of the plus
operation: 'a->'a->'a or 'a->'b->'c is not an abstract
subtlety. That's why functional dependencies where introduced in
Haskell (and quite often we need local functional dependencies to
resolve overloading). There are three main techniques of implementing
overloading: full inlining (aka C++), dictionary passing, and
the intensional type analysis. The latter is like `switch' and dictionary
passing is like a `vtable'. GHC and Hugs implement dictionary passing,
whereas JHC and Chameleon implement typeclasses via intensional type
analysis. I suspect F# might be doing something like that too, because
CLI might have run-time type tags.
Non-constructor Haskell 98 classes (that is, overloading over parameter
of the kind *) can be implemented in OCaml in a straightforward way.
We start with a typical Haskell code
class Numb a where
add :: a -> a -> a
shw :: a -> String
instance Numb Int where
add x y = x + y
shw = show
instance Numb Float where
add x y = x + y
shw = show
instance Numb a => Numb [a] where
add = zipWith add
shw a = "[" ++ concatMap (\x -> (shw x) ++ " ") a ++ "]"
summ (h:t) = foldl add h t
test1 = shw (add [(1::Int),2,3] [4,5,6])
test2 = shw (summ (add [(1::Int),2,3] [4,5,6]))
test3 = shw (summ [(1.0::Float),2.0,3.0])
test4 = shw (summ [[(1.0::Float),2.0,3.0], [4,5,6], [7,8,9]])
We introduce a class Numb with two methods, for addition and for
showing. The latter is quite handy. The instances for Int and Float
are trivial. The instance of [a] says that if the type of list
elements is in class Numb, the list is in class Numb as well. Note the
definition for the "add" method in that case. It looks recursive: the
body of 'add' invokes 'add' itself, but on a different type.
We then define a function summ. Its inferred type is
summ :: (Numb a) => [a] -> a
The function is bounded polymorphic: it works on lists of any type
provided that type is in Numb. The tests test3 and test4 demonstrate
that summ can sum lists and lists of lists, etc.
Here's the OCaml translation:
(* class Numb a *)
type 'a numb = {add: 'a -> 'a -> 'a; shw: 'a -> string};;
(* instance Numb Int *)
let numb_i = {add = (+); shw = string_of_int};;
(* instance Numb Float *)
let numb_f = {add = (+.); shw = string_of_float};;
(* instance Numb a => Numb [a] *)
let numb_l numb_e = {add = List.map2 numb_e.add;
shw = fun a ->
"[" ^ List.fold_right
(fun e z -> " " ^ numb_e.shw e ^ z) a "]"};;
(* we can define a bounded polymorphic function summ *)
let summ numb (h::t) = List.fold_left numb.add h t;;
let test1 =
let n = numb_l numb_i in
n.shw (n.add [1;2;3] [4;5;6]);;
let test2 =
let n = numb_l numb_i in
numb_i.shw (summ numb_i (n.add [1;2;3] [4;5;6]));;
let test3 =
numb_f.shw (summ numb_f [1.0;2.0;3.0]);;
let test4 =
let n = numb_l numb_f in
n.shw (summ n [[1.0;2.0;3.0]; [4.0;5.0;6.0]; [7.0;8.0;9.0]]);;
The inferred type of summ in OCaml is
val summ : 'a numb -> 'a list -> 'a = <fun>
It is instructive to compare it to the Haskell type. The only
difference is in the shape of the arrow: "Numb a =>" vs "'a numb ->".
Instead of the double arrow of Haskell we have the single arrow in
OCaml. The OCaml function summ is likewise bounded polymorphic: it
applies to arrays of any type provided that we have the _evidence_
(the dictionary) that the type is in the class numb. We must pass that
evidence as the first argument of summ. Granted, the burden of procuring
this evidence is on us; Haskell, in contrast, can, most of the time,
build that evidence by itself. As in Haskell, we can sum lists of
numbers and lists of lists of numbers, etc.
Haskell constructor classes (overloading over the parameters of
higher kinds) do require OCaml functors. The example is a monad. With a
bit of syntactic sugar, the monadic notation and the corresponding
overloading are tolerable in OCaml.
Conversely, OCaml and SML modules (including sealing, generative and
applicative functors and recursive structures) can be emulated in
Haskell typeclasses. Chung-chieh Shan and I wrote a couple of messages
on that topic back in August and September 2004 on the Haskell mailing
list.
John Skaller wrote: ``(Haskell does this little cheat .. it makes
typeclasses very easy to explain to OO people).'' Are you sure about
that? There has been many long and recurring threads on Haskell-Cafe
about typeclasses and OO classes. I think the common advice is _not_
to think of Haskell typeclasses as of OO classes. Ralf Laemmel and I
once wanted to elaborate on the issue of OO in Haskell; we ended up
with a 79-page paper. I guess that shows that OO is never easy.
Matthieu Dubuget
Richard Jones a écrit :
>> Putting aside the obvious cultural resistance to using a sensible
>> language for this project, there is one technical hurdle: It needs to
>> compile into a DLL which can be linked to other programs (in C and
>> other languages). I can't generate such code using ocamlopt, at least
>> not without using unsupported out-of-tree extensions.
>>
>>
I'm mainly producing DLLs with ocamlopt.
My only concern is the fact that I am to avoid some standard modules
(Thread at least),
to avoid crashes that occurs after the calling app has unloaded my DLLs.
Salutations
Matthieu
skaller
>
>
> On 09/03/07, skaller <ska...@users.sourceforge.net> wrote:
>
> BOTH Ocaml functors and overloading are just hacks to
> work around the lack of ability to properly express
> higher order natural transformations.
>
> Hm... indeed, but for some operations, you cannot provide a single,
> general definition - say for length operation, or for * (* is very
> different when it comes to scalars, vectors and matrices - not even
> the same axioms hold). I believe that the basic operations should be
> implemented using overloading (actually, some smart overloading that
> would allow both static and (seemingly) dynamic resolving) and then
> polyadic operations be built on top of that.
Actually, length can be defined in turns of fold:
let len x = fold (fun acc elt -> acc + 1) 0 container
Tom
>
>
> Actually, length can be defined in turns of fold:
>
> let len x = fold (fun acc elt -> acc + 1) 0 container
>
Yes, as long as x is a container. But how are you going to define a length
of a snake using fold?
Basically, I agree with you. I'm just saying that you can further increase
the "typeclass" of length-able objects to almost anything. Why limit
ourselves?
- Tom
skaller
>
> On 09/03/07, skaller <ska...@users.sourceforge.net> wrote:
>
> Actually, length can be defined in turns of fold:
>
> let len x = fold (fun acc elt -> acc + 1) 0 container
>
> Yes, as long as x is a container. But how are you going to define a
> length of a snake using fold?
That's a different kind of length. Now if you said 'worm'
there would be two kinds of length to define:
(a) the length in metres
(b) the number of segments
Jon Harrop
> On Thu, 2007-03-08 at 15:26 -0600, Robert Fischer wrote:
> > > Putting aside the obvious cultural resistance to using a sensible
> > > language for this project, there is one technical hurdle: It needs to
> > > compile into a DLL which can be linked to other programs (in C and
> > > other languages). I can't generate such code using ocamlopt, at least
> > > not without using unsupported out-of-tree extensions.
> >
> > I don't think this is a real hurdle to general adoption of a language.
>
> It is in fact an utter and complete show stopper.
Agreed. This is blocking the development of third party libraries written in
OCaml.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Elliott Oti
with the Ocaml Graphics module, thus bypassing the need for an
external windowing library like SDL or glut:
short descriptive article: http://www.elliottoti.com/index.php?p=24
download: http://www.elliottoti.com/code/glgraphics/glgraphics.tar.gz
Works on linux and windows, untested on os-x (I have no idea if the
xwindows trick will work on a Mac).
Cheers,
Elliott Oti
On Mar 8, 1:52 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> On Thursday 08 March 2007 11:59, Vu Ngoc San wrote:
>
> > You probably know it already, but it is very easy to spawn opengl
> > graphics directly from the toplevel using sdl. Then if you use the
> > toplevel inside emacs, you get something very similar to the screenshots
> > you had.
>
> > And since you are into screenshots, here is one :-)
>
> >http://www-fourier.ujf-grenoble.fr/~svungoc/prog/oplot/toplevel_plot.png
>
> This is just the kind of thing that I'd like to hear about!
>
> How exactly do you do that? Can you post a complete working example?
>
> Looks great... :-)
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> OCaml for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists
Jon Harrop
> Which is exactly my point. You should have to document all that, because
> they are genuinely different operations. You have these operations, so why
> shouldn't you document them? Or, better yet, abstract them and organize
> them. By using operator overloading, you're sweeping under the rug genuine
> complexity -- something that my surprise later developers!
Because the distinction is purely incidental as it depends upon the language's
choice of type system.
> When I see "+", I want to know what that means. With operator overloading,
> I don't know.
The same can be said of type inference. Then you're advocating explicit type
annotations everywhere.
> An IDE might help me out there, but that's just polishing a
> genuine ding on code readbility and maintainability. Why should I have to
> rely on an IDE to make sense of my code?
This is precisely why I rely so heavily on Tuareg's type throwback in Emacs.
If you sacrifice your development environment (even if it is just emacs) then
productivity goes down. Failing to embrace a future of graphical IDEs is a
bad idea, IMHO.
Jon Harrop
> Of course, when mixing vectors and matrices, we will not be able to
> stay with only + and * but I am not sure that having to put type
> annotations will compare favorably to put the expression in Mat.(...)
> and inventing a _few_ additional operators.
Many arithmetic expressions mix different types.
> Moreover I think that, in some respects, it is even better than
> overloading! For example if you write
>
> # Vec.(a + b + c)
>
> then Camlp4 could generate code that only needs to create 1 temporary
> vector to hold the result instead of 2 (as is the case in F#).
I would expect the compiler to automate that deforesting.
Jon Harrop
> > let result =
> > let (+) = Vector.add and ( * ) (x:int) (v:Vector.t) =
> > Vector.scalarmul x v
> > in 3 * a + 2 * b
>
> cake and Jon eat it, too. :D
I've been using that style for years and it just doesn't hack it.
Firstly, note the verbosity compared to:
let result = 3*a + 2*b
then note that many arithmetic expressions mix types, so you still end up
needing +, +., +/, +| and +||.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Jon Harrop
> On Thu, 2007-03-08 at 14:02 -0600, Robert Fischer wrote:
> > When I see "+", I want to know what that means. With operator
> > overloading, I don't know.
>
> This argument is fallacious: When you see + you know it means addition
> of whatever argument types are used.
Not necessarily. It also means set union and string concatenation in F#, for
example.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Jon Harrop
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages). I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
>
> I don't think this is a real hurdle to general adoption of a language.
> After all, Java and C# aren't intended to be used like that, yet they
> certainly have wide-spread adoption.
On the contrary, that is exactly how C# is intended to be used. Most libraries
used from F# are written in C# (and the same for most other .NET languages).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Jon Harrop
> I agree with Robert and the analogy with maths notation only reinforces
> that: when I was a student of maths, I frequently cursed the authors of
> papers I was reading for using notation without definition. Of
> course, it was perfectly clear to someone seasoned in the area of the
> paper, because the notation was conventional - but a puzzle for a
> newbie.
When I read some of Luca Cardelli's papers on type inference I found that they
were not explicit enough and required me to infer a lot. When that inference
went wrong the backtracking was costly and seemed unneccesary because I could
have read a paper 4x as long that required no inference.
But aren't we all here because we like inference and brevity?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Christophe TROESTLER
>
> > # Vec.(a + b + c)
> >
> > then Camlp4 could generate code that only needs to create 1 temporary
> > vector to hold the result instead of 2 (as is the case in F#).
>
> I would expect the compiler to automate that deforesting.
And how could it do that, not even knowing how to allocate a vector,
less how to pass a preallocated vector to an « add » operation
(because this, of course, depends on what « + » means...) ?
ChriS
skaller
> John Skaller wrote: ``(Haskell does this little cheat .. it makes
> typeclasses very easy to explain to OO people).'' Are you sure about
> that? There has been many long and recurring threads on Haskell-Cafe
> about typeclasses and OO classes. I think the common advice is _not_
> to think of Haskell typeclasses as of OO classes. Ralf Laemmel and I
> once wanted to elaborate on the issue of OO in Haskell; we ended up
> with a 79-page paper. I guess that shows that OO is never easy.
Certainty requires at least a proof sketch, which I don't have.
However I do have a 'gut feeling' :)
It's hard to say, because in OO terms Haskell typeclasses
are so weak it's surprising they're any use at all.
If you consider your record implementation, observe
it is just a weak special case of a C++ class.
C++ classes can also provide state and inheritance.
The state looks vaguely like dependent typing to me .. :)
OK, so now we have a much more powerful model .. yet
it has known limitations, in particular the so-called
'covariance' problem prevents OO from modelling any
serious kind of system: for example a system
with binary operators doesn't admit an OO representation.
So all you need to do is elevate this model up one kinding
level to see typeclasses, even with the additional power
of 'everything C++ classes can do' are limited.
Of course it is argument by analogy and intuition, not
any kind of formal proof, that's for the experts :)
Felix currently has multi-parameter typeclasses which
use inlining because it's a whole program analyser,
so it can, however explicit objects would be required
either for separate compilation, or simply to experiment
with the 'extra power' of dynamic binding.
The 'obvious' implementation is of course a C++ class.
The difference to ordinary use is that the object doesn't
represent a type, but a typeclass, possibly with dependent
type parameters: eg a 'get' method for an array with
the length as a state variable.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Andrej Bauer
themselves the following bit of Mathematica:
In[1]:= f[v_] = {{1,0}, {1,1}} . (v + {0,1});
In[2]:= f[{0,0}]
Out[2]= {{0, 0}, {1, 1}}
Firstly, if you do not think about the above, you won't even see what's
wrong. Secondly, once you do see what is wrong, you won't know why it's
wrong. The problem is caused by the meaning of + and Mathematica
evaluation strategy.
Explanation of what is wrong:
1) {0,1} is a two-dimensional vector
2) {{1,0},{1,1}} is the 2x2 matrix with rows (1,0) and (1,1)
3) The operator . means, according to the help system:
In[4]:= ?.
a.b.c or Dot[a, b, c] gives products of vectors, matrices and tensors.
For example, multiplying a 2x2 matrix and a 2D vector gives a 2D
vector:
In[5]:= {{1,0},{1,1}} . {0,1}
Out[5]= {0, 1}
4) Clearly, + is addition :-) but in case you do not trust me:
In[6]:= ?+
x + y + z represents a sum of terms.
5) The definition of f then says: take v, add to it the vector {0,1},
then multiply by the 2x2 matrix {{1,0},{1,1}}.
6) Thus we compute f[{0,0}] by hand according to 5):
f[{0,0}]
= {{1,0},{1,1}} . ({0,0} + {0,1})
= {{1,0},{1,1}} . {0,1}
= {0,1}
7) Hmm, strange, Mathematica thinks the answer is a 2x2 matrix, and we
think it's a 2D vector.
Have fun overloading!
I will repeat my suggestion again: when writing serious and complicated
code, overloading can cause a lot of harm. When manipulating expressions
such as vectors and matrices interactively, it is convenient to have
overloaded + etc. Perhaps the right way to solve the dilemma is to have
a "toplevel on streoids" which intelligently resolves ambiguities. The
intelligence can then go much further than simple overloading.
Andrej
Jon Harrop
> Basically, I agree with you. I'm just saying that you can further increase
> the "typeclass" of length-able objects to almost anything. Why limit
> ourselves?
Because there is a tradeoff between type inference and overloading. Operators
are conventionally heavily overloaded (e.g. in maths) and having overloaded
operators works well. Allowing all functions to be overloaded weakens
inference more and doesn't buy you so much, so you must choose to draw the
line somewhere.
I would like to have "sin" work on float and float32 in F# though... :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Jacques Carette
> I will repeat my suggestion again: when writing serious and
> complicated code, overloading can cause a lot of harm. When
> manipulating expressions such as vectors and matrices interactively,
> it is convenient to have overloaded + etc. Perhaps the right way to
> solve the dilemma is to have a "toplevel on streoids" which
> intelligently resolves ambiguities. The intelligence can then go much
> further than simple overloading.
The (heavily typed) computer algebra system Axiom tried just this. The
end result was that, frequently, 90% of the computation time was spent
in the "toplevel guesser", 10% on the actual computation. Much worse
was that while the underlying computations were very predictable (types
help), the toplevel was so huge and complex, that it was unpredictable
what *it* would do. And, worse, lots and lots of "types" now resolved
to the catch-all 'Expression' type.
Note however that Matlab also has its share of massive overloading, and
yet it doesn't suffer as much as Mathematica does from this. So there
must be something about the richness of the available data-structures
that makes the Matlab approach 'fail'.
Jacques
Andreas Rossberg
>
> 7) Hmm, strange, Mathematica thinks the answer is a 2x2 matrix, and we
> think it's a 2D vector.
Now you left me puzzled. Can you explain *why* Mathematica thinks
differently?
--
Andreas Rossberg, ross...@ps.uni-sb.de
Robert Fischer
>> certainly have wide-spread adoption.
>
> because the architecture is a virtual machine driven by
> bytecode .. they DO make dynamically linkable bytecode
> libraries.
>
~~ Robert.
-----Original Message-----
From: skaller [mailto:ska...@users.sourceforge.net]
Sent: Thursday, March 08, 2007 6:04 PM
To: Robert Fischer
Cc: caml...@inria.fr
Subject: RE: [Caml-list] Interactive technical computing
On Thu, 2007-03-08 at 15:26 -0600, Robert Fischer wrote:
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages). I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
> >
> I don't think this is a real hurdle to general adoption of a language.
It is in fact an utter and complete show stopper.
I've spent 6 years developing Felix precisely to solve this
problem: a high level language that can generate shared libraries
which can use and be used by other shared libraries.
Ocaml is great for stand-alone programs but a significant
fraction of software development is library building,
and Linux distros such as those based on Debian provide
a library component model which demands dynamic linkage
so the components can be upgraded without end user recompilation.
I expect this will eventually be solved too.
> After all, Java and C# aren't intended to be used like that, yet they
> certainly have wide-spread adoption.
They don't make binary shared libraries
because the architecture is a virtual machine driven by
bytecode .. they DO make dynamically linkable bytecode
libraries.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Andreas Rossberg
>
> It's hard to say, because in OO terms Haskell typeclasses
> are so weak it's surprising they're any use at all.
Not sure how you come to that conclusion. Both concepts are somewhat
incomparable, but there are a number of axes along which type classes
are much more expressive than OO classes.
Ignoring implementation inheritance, I claim that in combination with
existential types, even relatively basic type classes are strictly more
powerful than OO classes (modulo some lack of syntactic sugar).
Have a look at Oleg's paper.
> C++ classes can also provide state and inheritance.
> The state looks vaguely like dependent typing to me .. :)
I grant you (implementation) inheritance, but I don't understand the
rest of your comment. State is orthogonal to classes. Surely you can
define a type class that contains a, say, IORef (for per-class state).
Likewise, you can instantiate type classes to stateful types (as the
equivalent to per-object (mutable) state).
> OK, so now we have a much more powerful model ..
I don't think so.
> yet
> it has known limitations, in particular the so-called
> 'covariance' problem prevents OO from modelling any
> serious kind of system: for example a system
> with binary operators doesn't admit an OO representation.
Which is one of the problems type classes do not have, because qualified
types *are* more expressive than subtyping in that respect.
AFAICS, the rest of your argument hence does not follow.
--
Andreas Rossberg, ross...@ps.uni-sb.de
skaller
> >> After all, Java and C# aren't intended to be used like that, yet they
> >> certainly have wide-spread adoption.
> >
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
> >
> As long as you play within the bounds of their VM. This is no different than Ocaml.
Performance is different :) That's why I use Ocaml native code
exclusively, which doesn't support dynamic loading (yet :)
Jon Harrop
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
>
> As long as you play within the bounds of their VM. This is no different
> than Ocaml.
On the contrary, it is very different:
Can you dynamically load code and get native performance? Not with OCaml.
Can you compile to a cross-platform format and keep native performance? Not
with OCaml.
Can you write an interactive environment (top level) and keep native
performance? Not with OCaml.
Can you link to libraries (e.g. OpenGL) and be cross-platform? Not with OCaml
(I think, because you need a custom run-time).
I've got a killer high-performance 2D and 3D visualization library written in
OCaml and I'd like to sell it, but I don't want to sell the source code
because I value it too much. What can I do? Well, I can port it to F# and
sell it there. In the mean time, OCaml users are stuck with GNUPlot.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Robert Fischer
~~ Robert.
-----Original Message-----
From: skaller [mailto:ska...@users.sourceforge.net]
Sent: Friday, March 09, 2007 7:54 AM
To: Robert Fischer
Cc: caml...@inria.fr
Subject: RE: [Caml-list] Interactive technical computing
On Fri, 2007-03-09 at 07:33 -0600, Robert Fischer wrote:
> >> After all, Java and C# aren't intended to be used like that, yet they
> >> certainly have wide-spread adoption.
> >
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
> >
> As long as you play within the bounds of their VM. This is no different than Ocaml.
Performance is different :) That's why I use Ocaml native code
exclusively, which doesn't support dynamic loading (yet :)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Robert Fischer
>
> OCaml and I'd like to sell it, but I don't want to sell the source code
> because I value it too much. What can I do? Well, I can port it to F# and
> sell it there. In the mean time, OCaml users are stuck with GNUPlot.
>
>From what I understand, F# has a major performance issue resulting from the way the .Net VM handles allocation. Is that old info?
> Can you compile to a cross-platform format and keep native performance? Not
> with OCaml.
>
F# goes to byte code, OCaml goes to byte code. If you want to be "cross-platform", you're pretty much headed to a VM one way or another.
> Can you write an interactive environment (top level) and keep native
> performance? Not with OCaml.
>
The top-level is something I've been hacking on a bit, and I am a bit cranky with it right now, too. I'll post something on it later.
> Can you link to libraries (e.g. OpenGL) and be cross-platform? Not with OCaml
> (I think, because you need a custom run-time).
>
What are you doing with F# where you see it as more "cross-platform" than OCaml? I guess I don't understand the charge.
>From what I understand, your basic argument is "F# is cross-compatible with the .Net framework, and therefore better". This is definitely something I agree with. If I trusted the .Net framework to ever become and remain genuinely cross-platform (I expect Mono to be killed by vicious attack lawyers as soon as MS cares), I'd be a lot more inclined to use it.
~~ Robert.
-----Original Message-----
From: caml-lis...@yquem.inria.fr
[mailto:caml-lis...@yquem.inria.fr]On Behalf Of Jon Harrop
Sent: Friday, March 09, 2007 7:49 AM
To: caml...@yquem.inria.fr
Subject: Re: [Caml-list] Interactive technical computing
On Friday 09 March 2007 13:33, Robert Fischer wrote:
> > They don't make binary shared libraries
> > because the architecture is a virtual machine driven by
> > bytecode .. they DO make dynamically linkable bytecode
> > libraries.
>
> As long as you play within the bounds of their VM. This is no different
> than Ocaml.
On the contrary, it is very different:
Can you dynamically load code and get native performance? Not with OCaml.
Can you compile to a cross-platform format and keep native performance? Not
with OCaml.
Can you write an interactive environment (top level) and keep native
performance? Not with OCaml.
Can you link to libraries (e.g. OpenGL) and be cross-platform? Not with OCaml
(I think, because you need a custom run-time).
I've got a killer high-performance 2D and 3D visualization library written in
OCaml and I'd like to sell it, but I don't want to sell the source code
because I value it too much. What can I do? Well, I can port it to F# and
sell it there. In the mean time, OCaml users are stuck with GNUPlot.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
skaller
> skaller wrote:
> >
> > It's hard to say, because in OO terms Haskell typeclasses
> > are so weak it's surprising they're any use at all.
>
> Not sure how you come to that conclusion. Both concepts are somewhat
> incomparable, but there are a number of axes along which type classes
> are much more expressive than OO classes.
I'm sorry to write so poorly. This isn't the comparison I'm
drawing.
Consider *implementing* typeclasses with records,
as in Oleg's Ocaml examples.
Ok, now replace the records with classes. Classes
are more powerful because they provide
(a) state
(b) inheritance etc
They also don't make the weak assumption of an
abstraction (possibly with default methods as in Haskell)
and a single instantiation: in C++ at least you can
have sequence of more derived classes.
So the type model associated with this implementation
can do more than the one just using plain records:
records aren't typeclasses, so the class based implementation
can't be compared with them:
records classes
typeclasses ???????
Clearly ???? is more expressive than typeclasses, whatever it
is .. I am guessing the state of the classes provides dependent
typing but I don't really know.
Anyhow my ARGUMENT was actually that using classes
subsumes plain old records .. and classes are
limited by the covariance problem, so records
must be limited too.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
skaller
> Performance of Ocaml's bytecode is slower than F#? Really?
I wrote:
> > As long as you play within the bounds of their VM. This is no different than Ocaml.
>
> Performance is different :) That's why I use Ocaml native code
> exclusively, which doesn't support dynamic loading (yet :)
I have no idea about performance of F#: I'm talking about
using a Debian based Linux operating system which uses
dynamic loading of high performance machine binaries.
I once implement a Python interpreter in Ocaml, call Vyper.
One of the reasons I gave up was that to extend it with
the equivalent of Python's C modules, I had to write the
equivalent code in Ocaml and *statically* link it into
the program.
The main reason for doing this wasn't performance, but
to provide bindings to C libraries.
Robert Fischer
I'm still having trouble seeing what you're getting at -- sorry if I'm being dense.
~~ Robert.
-----Original Message-----
From: caml-lis...@yquem.inria.fr
[mailto:caml-lis...@yquem.inria.fr]On Behalf Of skaller
Sent: Friday, March 09, 2007 9:22 AM
To: Robert Fischer
Cc: caml...@inria.fr
Subject: RE: [Caml-list] Interactive technical computing
Brian Hurt
> Hum...
>
> Instead of proving once again Godwin's law we might want to use
> constructive criticism (even though I also tend to flame more than my
> share)...
No, actually, I was making a point. The fact that you don't like the
point I was making doesn't make it a flame. Disagreeing with you is not
an insult. Although I do find amusing the implication that bringing up
pointer arithmetic is the equivelent to calling someone a Nazi.
Spelling the point out explicitly for those who missed it: when
considering wether to add a feature to a language, you have to consider
*BOTH* the valid uses of that feature *AND* the probable ways the
feature will be misused and the problems it will cause. You don't get
to ignore the downsides. Because, if you do, then there's no real
reason why introducing pointer arithmetic into Ocaml is not a good idea.
Brian
Ian Zimmerman
Inference: On condition it is _controlled_. I.e. seeing operator
<foo> used on a complex type, I need to know I have seen its
definition and satisfied myself that it has the expected semantic
properties. That's just what functors formalize.
Brevity: There's the pesky tradeoff with some type annotations being
required when you introduce overloading.
Andreas Rossberg
>
> I'm sorry to write so poorly. This isn't the comparison I'm
> drawing.
>
> Consider *implementing* typeclasses with records,
> as in Oleg's Ocaml examples.
>
> Ok, now replace the records with classes. Classes
> are more powerful because they provide
>
> (a) state
> (b) inheritance etc
Records and classes are not in the same category. Records and *objects*
are. OTOH, objects *are* basically records, except that they usually
come with more expressive typing, particularly allowing recursive types
and subtyping. State is still orthogonal - records can have state, too.
Classes are a mechanism for *creating* objects (and in weaker languages
than OCaml, for defining subtyping relations). Take away inheritance and
you are basically left with fancy syntax for a function creating a
record of mutually recursive closures over some local variables.
> They also don't make the weak assumption of an
> abstraction (possibly with default methods as in Haskell)
> and a single instantiation: in C++ at least you can
> have sequence of more derived classes.
Please distinguish subtyping and inheritance. Type classes can express
something akin to nominal interface subtyping, e.g.
class C a where m1 :: t1
class C a => D a where m2 :: t2
But it's true that they do only provide a very weak form of inheritance
(via default methods).
> So the type model associated with this implementation
> can do more than the one just using plain records:
> records aren't typeclasses, so the class based implementation
> can't be compared with them:
>
> records classes
> typeclasses ???????
I cannot make much sense of this diagram, because of the category
mismatch I mentioned above.
> Anyhow my ARGUMENT was actually that using classes
> subsumes plain old records .. and classes are
> limited by the covariance problem, so records
> must be limited too.
Something like the covariance problem does not occur with type classes
(or modules, for that matter) because they decouple types from
interfaces. A type class is merely an interface, witnessed by a record,
the actual type is abstracted out. With OO, this is mingled together (an
object type *is* its interface), which produces that nasty recursion
where all the type problems originate.
So the difference is in the way these features factorise abstraction,
rather than in the intrinsic expressiveness of the underlying
primitives. Operationally, you can view dictionaries as detached
"vtables". This detachment allows them to be used in more flexible ways,
and avoid nuisances like the binary method issue.
Of course, it also makes inheritance a rather alien concept.
--
Andreas Rossberg, ross...@ps.uni-sb.de
Robert Fischer
~~ Robert.
-----Original Message-----
From: caml-lis...@yquem.inria.fr
[mailto:caml-lis...@yquem.inria.fr]On Behalf Of Ian Zimmerman
Sent: Friday, March 09, 2007 10:28 AM
To: Jon Harrop
Cc: caml...@yquem.inria.fr
Subject: Re: [Caml-list] Operator overloading
> But aren't we all here because we like inference and brevity?
Inference: On condition it is _controlled_. I.e. seeing operator
<foo> used on a complex type, I need to know I have seen its
definition and satisfied myself that it has the expected semantic
properties. That's just what functors formalize.
Brevity: There's the pesky tradeoff with some type annotations being
required when you introduce overloading.
_______________________________________________
Jon Harrop
> Exactly. If I was just going for inference and brevity, I'd still be
> coding in Perl.
But this is about statically resolving overloads to get both performance and
brevity. Perl doesn't have performance.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Jon Harrop
> Performance of Ocaml's bytecode is slower than F#? Really?
Performance of OCaml compiled to native code with ocamlopt is sometimes slower
than F#, so yes.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Robert Fischer
~~ Robert.
-----Original Message-----
From: caml-lis...@yquem.inria.fr
[mailto:caml-lis...@yquem.inria.fr]On Behalf Of Jon Harrop
Sent: Friday, March 09, 2007 11:26 AM
To: caml...@yquem.inria.fr
Subject: Re: [Caml-list] Interactive technical computing
Jon Harrop
Sum 1/x for x in [1 .. 10^6]. In OCaml:
time (Array.fold_left (+.) 0.)
(Array.init 1000000 (fun i -> 1. /. float(i+1)));;
In F#:
time (Array.fold_left (+) 0.)
(Array.map ((/) 1.) [|1. .. 1000000.|]);;
OCaml takes 0.256s, F# takes only 0.047s => F# more than 5x faster than OCaml
bytecode.
On numerical code, F# can be faster than native-code compiled OCaml. For
example, a naive 2^n FFT:
let fft a =
let n = Array.length a in
let j = ref 0 in
for i = 0 to n-2 do
if i < !j then
(let t = a.(!j) in
a.(!j) <- a.(i);
a.(i) <- t);
let m = ref (n/2) in
while !m <= !j do
j := !j - !m;
m := !m/2
done;
j := !j + !m
done;
let j = ref 1 in
let b = ref (neg c1) in
while !j<n do
let w = ref c1 in
for m = 0 to !j-1 do
let i = ref m in
while !i < n do
let t = !w *@ a.(!i + !j) in
a.(!i + !j) <- a.(!i) -@ t;
a.(!i) <- a.(!i) +@ t;
w := !w *@ !b;
i := !i + !j + !j
done
done;
j := !j + !j;
b := sqrt !b
done;
a;;
n=1<<15
ocamlopt: 0.164s
F#: 0.134s
F# is 22% faster, probably thanks to complex numbers in the language.
Discrete wavelet transform (4-tap Daubechies, n=2^20), OCaml is 25% faster:
ocamlopt: 2.03s
F#: 2.53s
Note that this is apples and oranges because my Windows environment is still
only 32 bit. If .NET shows the same performance improvement moving from
> From what I understand, F# has a major performance issue resulting from the
> way the .Net VM handles allocation. Is that old info?
Allocation is slower in F# for two main reasons:
1. The run-time is optimised for C# code that has quite different expected
value lifetimes (far fewer very short-lived objects compared to F#).
2. F# supports concurrency, which incurs a big performance cost in allocation
and GC.
but the consequence of this is that very allocation-heavy code (e.g. symbolic
rewriting) is up to 4x slower in F#. Lists are also more heavyweight in F#.
However, F# regains a lot of performance by having a much faster stdlib.
For example, creating a 2^16-element set is an allocation-intensive task. In
OCaml:
# module Int = struct
type t = int
let compare = compare
end;;
# module IntSet = Set.Make(Int);;
..
# time (Array.fold_right IntSet.add (Array.init 65536 (fun i -> i)))
IntSet.empty;;
0.744047s
Compiled with ocamlopt I get 0.065s.
For F# I get 0.240s. That's 3.7x slower than native-code OCaml.
However, it is worth noting that the F# equivalent is much more concise, just:
time (Array.fold_right Set.add [|0 .. 65535|])
Set.empty;;
primarily because no functors are involved when making a set. The comparison
function is taken from the element type.
> > I've got a killer high-performance 2D and 3D visualization library
> > written in OCaml and I'd like to sell it, but I don't want to sell the
> > source code because I value it too much. What can I do? Well, I can port
> > it to F# and sell it there. In the mean time, OCaml users are stuck with
> > GNUPlot.
>
> Do you have metrics showing that performance is better with F# than OCaml
> in these two cases?
In theory, performance should be very close because so much work is done by
the graphics card and not the CPU. In practice, I only just figured out how
to render static geometry optimally from DirectX, so my F# version still
sucks.
Once I've integrated that into my purely-functional scene graph I'll let you
know what the performance is like. I expect F# to win because I'm exploiting
concurrency and the application is more numerical than allocation intensive.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
skaller
> skaller wrote:
> >
> > I'm sorry to write so poorly. This isn't the comparison I'm
> > drawing.
> >
> > Consider *implementing* typeclasses with records,
> > as in Oleg's Ocaml examples.
> >
> > Ok, now replace the records with classes. Classes
> > are more powerful because they provide
> >
> > (a) state
> > (b) inheritance etc
>
> Records and classes are not in the same category. Records and *objects*
> are.
That depends on terminology. I was thinking in C++ terms:
record = struct
class = struct with methods
> OTOH, objects *are* basically records, except that they usually
> come with more expressive typing, particularly allowing recursive types
> and subtyping. State is still orthogonal - records can have state, too.
Yes, records can have state, but usually any functions stored
in record fields are not bound to the state of the record.
Methods of an object are bound to the state of the object.
> Classes are a mechanism for *creating* objects (and in weaker languages
> than OCaml, for defining subtyping relations). Take away inheritance and
> you are basically left with fancy syntax for a function creating a
> record of mutually recursive closures over some local variables.
Sure, but you're missing the point. In Haskell and in Oleg's Ocaml
implementation of typeclasses, a record object is like a C++ vtable.
A vtable contains static function pointers which can be
bound to the current object to create methods.
But I'm talking about replacing this with a class object,
so we're not talking about the methods binding against the
typeclass datatype .. we're talking about methods bound
against the typeclass itself.
> > They also don't make the weak assumption of an
> > abstraction (possibly with default methods as in Haskell)
> > and a single instantiation: in C++ at least you can
> > have sequence of more derived classes.
>
> Please distinguish subtyping and inheritance.
I did. I said 'derived classes'.
> Type classes can express
> something akin to nominal interface subtyping, e.g.
>
> class C a where m1 :: t1
> class C a => D a where m2 :: t2
>
> But it's true that they do only provide a very weak form of inheritance
> (via default methods).
Yes, its very weak. I don't know Haskell, but in Felix I have
typeclasses where I need to override the default method and I can't.
I don't know if Haskell suffers this restriction, but for someone
used to using C++ it shows the weakness of the
typeclass/instance dichotomy immediately.
I actually need to do this:
typeclass container[bag,value] {
virtual fold ..; // no default method
}
typeclass stl_container[bag,iterator,value] {
inherit container[bag,value]; // "implementation inheritance"
fold .. // default method
}
because all STL containers have a single fold function,
implemented by using iterators. I need to instantiate
fold in the derived typeclass stl_container, but I'm
not allowed to.
So what I require is a tree:
container --> stl_container --> vector --> vector<int>
and the distinction between typeclasses and instances is
a serious obstacle.
A C++ class has no such problems: you aren't limited to
defining an abstraction and one concrete instance class.
Roughly, my typeclasses allow adding new methods, but
you cannot override a method in a derived typeclass.
> Something like the covariance problem does not occur with type classes
> (or modules, for that matter) because they decouple types from
> interfaces.
That's right.. it only occurs when you go up to the kind level.
Which occurs immediately if you want to try some dependent typing.
[I'm assuming a typeclass system with multiple type parameters
is required of course]
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
skaller
> considering wether to add a feature to a language, you have to consider
> *BOTH* the valid uses of that feature *AND* the probable ways the
> feature will be misused and the problems it will cause. You don't get
> to ignore the downsides. Because, if you do, then there's no real
> reason why introducing pointer arithmetic into Ocaml is not a good idea.
Actually, using your criteria, it might a good idea IF it is possible
to limit abuse in a way compatible with Ocaml philosophy. For example
if you could ensure pointers always remained in bounds, or at least
threw an exception when an out of bound dereference occurred.
The latter seems acceptable because it is already what happens
with an out of bounds access to an array.
Array pointers seem easy to represent .. it's just a pair
'a Array.t * int
Offset addition is statically safe, so you can throw that in too.
That can be implemented with composition of closures which access
record fields.
However it isn't clear any of this is worth it: pointer arithmetic
is used in C because it is fast, in Ocaml it probably wouldn't be,
an other techniques would provide the same functionality.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Daniel Andor
>
> To all who like overloading, I dearly suggest that they explain to
> themselves the following bit of Mathematica:
>
> In[1]:= f[v_] = {{1,0}, {1,1}} . (v + {0,1});
>
> In[2]:= f[{0,0}]
>
> Out[2]= {{0, 0}, {1, 1}}
If you define the function f as most people would expect a function to work,
and the way you would be taught in Mathematica to define a function, and the
way you define 95% of your functions, you get the expected answer:
In[1]:= f[v_] := {{1,0}, {1,1}} . (v + {0,1});
In[2]:= f[{0,0}]
Out[2]= {0, 1}
So I think you are a little disingenuous in your example... ;)
Lots of interesting and sophisticated reasons have been given for the pros
and cons of overloading. As someone who programs numerical code on a daily
basis, I would just like to make a practical comment:
A reason to appreciate strong typing (and inference that makes it brief) is
that it catches a good number of bugs. When programming mathematical
algorithms, not having overloading increases the complexity of the code and
hence introduces bugs. Why? Most mathematicians I know syntax highlight
with their eyes. Complexity thwarts this process. (Until you have a
programming language that checks the algorithm as well as computes it, this
human syntax highlighter is the best (well, only) thing you've got.)
I do occasionally get caught by the kind of error that Andrej mentions. But
nonetheless I still reach for Mathematica, because algorithmic correctness
(which depends on my interaction with the computer) is at least as important
to me as type safety.
You know, if efficiency didn't matter, then we could all still prove our
programs with pencil and paper and then program it in assembler (or
punchcards).
Can't there be a systematic way of doing this overloading that will not
upset people while allow me (and Jon?) to `see' clearly? There's got to be
a way! :)
$0.0314,
Daniel.
David Thomas
to say Module.(expression), where operators within
that expression are drawn exclusively from Module (we
can then say that the entire program is wrapped in an
implicit Pervasives.() which seems somewhat elegant.
It would allow cleaning up of complex mathematic
expressions while not introducing ambiguities. It
seems the biggest downside is some possibly
unnecessary complexity.
All of that said, I was not, prior to this discussion,
aware that one could locally override operators
already defined. I expect this to clean up a bit of
my code when I get to applying it, and having done
that I'll let you all know whether I feel it's
sufficient or would still like to see the extension,
for whatever it's worth (in which case, I'll get
around to learning camlp4, I expect... :-p).
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
Richard Jones
> > Putting aside the obvious cultural resistance to using a sensible
> > language for this project, there is one technical hurdle: It needs to
> > compile into a DLL which can be linked to other programs (in C and
> > other languages). I can't generate such code using ocamlopt, at least
> > not without using unsupported out-of-tree extensions.
> >
> I don't think this is a real hurdle to general adoption of a language.
> certainly have wide-spread adoption.
It is a hurdle because not all programming is writing end-user
application code.
In fact what is somewhat sad is that OCaml (unlike Java and C#) can
compile to native code which really has very minimal "environmental
needs" - just a smallish library of functions and a GC which is
written on top of C's malloc. So really it could be an ideal
replacement for libraries written in C, where the heavy lifting is
done in OCaml and there are some thin bindings to provide a C API.
Rich.
--
Richard Jones
Red Hat
Michael Vanier
If it were fixed, ocaml would become an unstoppable juggernaut ;-)
Here's a paper describing an approach to this problem for an extended version of
Standard ML:
http://www.ps.uni-sb.de/Papers/abstracts/missing-link.html
This actually goes further than dynamic linking to provide a full component
model. What I wouldn't give to see this in ocaml.
Mike
Richard Jones wrote:
> On Thu, Mar 08, 2007 at 03:26:03PM -0600, Robert Fischer wrote:
>>> Putting aside the obvious cultural resistance to using a sensible
>>> language for this project, there is one technical hurdle: It needs to
>>> compile into a DLL which can be linked to other programs (in C and
>>> other languages). I can't generate such code using ocamlopt, at least
>>> not without using unsupported out-of-tree extensions.
>>>
>> I don't think this is a real hurdle to general adoption of a language.
>> After all, Java and C# aren't intended to be used like that, yet they
>> certainly have wide-spread adoption.
>
> It is a hurdle because not all programming is writing end-user
> application code.
>
> In fact what is somewhat sad is that OCaml (unlike Java and C#) can
> compile to native code which really has very minimal "environmental
> needs" - just a smallish library of functions and a GC which is
> written on top of C's malloc. So really it could be an ideal
> replacement for libraries written in C, where the heavy lifting is
> done in OCaml and there are some thin bindings to provide a C API.
>
> Rich.
>
_______________________________________________
Jon Harrop
> I agree 100%. This is the biggest limitation to using ocaml for large
> projects. If it were fixed, ocaml would become an unstoppable juggernaut
> ;-)
Concurrency has to be on that list as well though. F# inherits concurrency
from .NET and it is vastly easier to use than the last time I tried
concurrency (on a supercomputer, in Fortran).
However, a recent thread discussed the fledgling development of concurrency
for OCaml and it sounded fascinating (although I still haven't found time to
read it in detail!).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________
Joel Reymont
On Mar 29, 2007, at 1:33 AM, Jon Harrop wrote:
> However, a recent thread discussed the fledgling development of
> concurrency
> for OCaml and it sounded fascinating (although I still haven't
> found time to
> read it in detail!).
Where is this thread?
Thanks, Joel
Jon Harrop
> On Mar 29, 2007, at 1:33 AM, Jon Harrop wrote:
> > However, a recent thread discussed the fledgling development of
> > concurrency
> > for OCaml and it sounded fascinating (although I still haven't
> > found time to
> > read it in detail!).
>
> Where is this thread?
Finally found it:
http://tech.groups.yahoo.com/group/ocaml_beginners/message/7200
:-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
_______________________________________________