Re: Can someone explain?

[skaller <skaller@maxtal.com.au>]

Lyn A Headley wrote:

> Here's an idea: just hijack the Python implementation and provide an
> ocaml interface.  This has the advantages that (1) it has been
> hand-tuned for efficiency for years and (2) that it will export a
> similar interface to the ocaml code as has existed for the C code for
> years, thus allowing a smoother transition to ocaml for python
> extension writers.

	I thought of that, and I was tempted!	
However, I decided against it for several reasons.

	First, while it leverages the Python code, it creates 
a headache for memory management, since Python does it's own,
which doesn't sit well with ocaml garbage collector.

	Second, it means any extensions I wish to write
will have to be written in C. This defeats the advantages
of using ocaml. For example, I have already added a Rational
type using the num module: I did it in only a few hours,
and added long integers at the same time: the num long integers
are already faster than the python ones.

	Third, it becomes sensitive to the C implementation
of Python which changes with versions, and depends on 
the whims of developers who may have different goals than I do.

> Come to think of it, why not do that for /all/ the builtin types?
> These will also be useful for use by code generated by viperc.

	So will the ocaml based run time, if the compiler back end
generates ocaml :-)

	There are two versions of Python: CPython (C) and JPython (Java).
Both suffer from portability problems, due to the base language,
compared with ocaml (IMHO). Both suffer from inferior technology,
compared with ocaml (IMHO).

	My plan is to suport _pure_ python, not C based extensions:
just the same as JPython cannot use C based extensions. 
I suspect that the C -> ocaml -> python wrapper chain for 
extensions representing external interfaces (operating system
services and access to C libraries) is probably easier
than the C -> CPython extension -> Python.

	However, a lot of C modules in python are only
for efficiency, and it is better to rewrite these in Python
and use the compiler, or, in ocaml if really necessary.

> Darn it, now you've got
> me all psyched about ocaml again.  Too bad I already committed to
> Eiffel for my latest project.

	Oh well :-)

> An ocaml "port" of STL would kick ass.  

	The code I showed is part of a set of modules I'm developing
that (attempt to) provide ocaml representations of the same ideas.
However, this has a lower priority than the python compiler.

>especially, think how well
> iterators would combine with closures!  The C++ notion of "function
> objects" and "adaptors" looks clumsy in comparison (e.g. you cannot
> create a localized class object)

	Yes. In fact, I have a contract to write a book on STL,
but I gave up precisely because of this. I tried to tell the
committee, but they just didn't understand. STL isn't that useful in
C++, because the core language fails to support
nested functions, when it could. Furthermore,
the committee broke the way unions work, so that they
cannot be used to implement variants easily.

	I prefer to work with a language whose developers
actually know some mathematics.

>     skaller> A class is used here to represent the whole list. It is
>     skaller> an object simply because that is the intended use: as a
>     skaller> mutable object with various mutators. In retrospect, this
>     skaller> is probably a mistake.
> 
> why?

	Because, the functional operations, such as concatenation,
require access to the private data, and cannot get it. There are
no friends in ocaml: the correct solution is to abandon the class
and use an algebraic data structure, and restrict the interface 
of the module so it becomes abstract.

	There is another reason: class methods cannot be polymorphic,
wheres plain functions of modules can be (independently of instantiation
of type parameters of the module).

-- 
John Skaller, mailto:skaller@maxtal.com.au
1/10 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
downloads: http://www.triode.net.au/~skaller