From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA30130; Sun, 23 May 2004 21:59:16 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA30126 for ; Sun, 23 May 2004 21:59:14 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4NJxBEV004882 for ; Sun, 23 May 2004 21:59:13 +0200 Received: from [192.168.1.200] (ppp114-11.lns1.syd3.internode.on.net [150.101.114.11]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i4NJx6k2028338; Mon, 24 May 2004 05:29:09 +0930 (CST) Subject: Re: [Caml-list] Automatic wrapper generator From: skaller Reply-To: skaller@users.sourceforge.net To: "Marcin 'Qrczak' Kowalczyk" Cc: caml-list In-Reply-To: <1085309896.32267.170.camel@qrnik> References: <1084869517.19838.409.camel@pelican.wigram> <1085220553.32267.49.camel@qrnik> <1085231636.774.250.camel@pelican.wigram> <1085235588.32267.78.camel@qrnik> <1085242444.6065.51.camel@pelican.wigram> <1085309896.32267.170.camel@qrnik> Content-Type: text/plain Message-Id: <1085342345.6065.157.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 24 May 2004 05:59:06 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 40B1028F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 marcin:01 'qrczak':01 kowalczyk:01 snippets:01 snippets:01 runtime:01 runtime:01 low-level:01 hand-written:01 high-level:01 high-level:01 low-level:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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