Re: [Caml-list] Automatic wrapper generator

[skaller <skaller@users.sourceforge.net>]

On Sun, 2004-05-23 at 20:58, Marcin 'Qrczak' Kowalczyk wrote:

> They rely on the fact that code is compiled into C, and thus the
> compiler can insert these snippets in appropriate places and compile
> the resulting C code as a whole. 

Just what Felix does :)

> Contents of the snippets rely on the
> implementation of the runtime, and use various functions and macros
> which would otherwise be internal to the runtime. For now there is a
> single implementation of my language anyway, but these constructs will
> not be portable. 

I put all the special constructs in the standard library,
in a module named 'C_hack' :-)

> Your binding language lies between my low-level binding, and my
> hand-written high-level bindings for particular libraries. We compared
> your language to my high-level interfaces, but perhaps it should be
> compared to my low-level sublanguage. 

Yes, that seems reasonable.

> Now mine is as universal as
> yours :-) but it requires some knowledge about internals of the
> compiler, comparable to what is required for OCaml extensions.

In Felix, some FFI stuff needs no knowledge of the compiler
or implementation. Most of it, in fact :)

However, you can do some nasty tricks, and do need to
sometimes, and those things are implementation dependent.
C_hack handles many of them.

> I think yours is easier to use because your runtime is much closer to
> C++ than mine. 

Yes. There are only two languages which can bind to C
better than Felix: C++ and C (in that order LOL!)

It was indeed specifically designed to be an upgrade
of C/C++. I learned a lot about compatibility on the C++
committee, particularly its *political* importance :)

> I don't know the details of yours, but major differences
> between my runtime and C are:
> - dynamic typing
> - variables refer to objects, not contain them
> - garbage collection (copying, generational; pointers may change,
>   pointer stores require write barrier)
> - tail calls
> - exceptions (as lightweight as in OCaml)
> - integers are unbounded (with a separate representation for fixnums,
>   but is should be transparent to the user)
> - strings are Unicode (UTF-32 or ISO-8859-1 internally).

Felix is a statically typed Algol-like language meaning
it has variables containing values. (Variants are
boxed due to an inexcusable flaw in C++)

It has an exact  *user supplied* garbage collector capable 
of supporting compaction (but I haven't actually written a compactor).

It optimises tail calls for procedures (but relies on g++
for functions at the moment -- this is hard to fix
because gcc is a toy compiler, and can't be relied
on to do any kind of heavy work)

There's no exception handling. 

Felix has no datatypes (not even bool).

Numbers of various kinds are provided in the library
using the binding technology .. although bool
doesn't need it:

typedef void = 0;
typedef unit = 1;
typedef bool = 2; // = 1 + 1 = unit + unit

defines it in terms of the basic type constructors.
[and by a "lucky" coincidence .. this maps to 
C/C++ int/boolean ..]

There is some hackery to make the lexer etc support
literals -- this is *supposed* to be handled
by a loadable user specified extension .. but
Ocamlyacc/lex lexers/parsers aren't so easy to
extend, and Ocaml native code is hard to extend
dynamically (Felix itself is designed from the ground
up to support dynamic loading, but bootstrapping
is a long way off yet ..)

> > In your case, you might consiser a DSSL which has
> > some static typing, just to deal with FFIs ..
> > but which is higher level than C, and interfaces
> > with the rest of your language.
> 
> I'm not sure how it should look like.

Use type inference, with a fallback to dynamic typing.
That's basically what I did for Python.

> Should a variable holding a foreign type be mutable? Should the foreign
> object be copied when passing it around? Implicing copying + mutability
> = weird semantics, and inconsistent with the rest of the language.

The simplest model for *foreign* objects is 'pointer'.
They're all the same size, and you manage them by value.

If you do some type inference, you may find your native
integers, strings, and also foreign pointers can sometimes
be detected and you can then possibly optimise things.
I guess you need to always be able to fallback on
dynamics.

> Where should a foreign object be allocated? 

You can't allocate one inside your language, its foreign ..
so it has to be done by a foreign function.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners