From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA02770 for caml-redistribution; Wed, 6 Oct 1999 16:19:04 +0200 (MET DST) 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 XAA15636 for ; Tue, 5 Oct 1999 23:42:55 +0200 (MET DST) Received: from alexandria.cs.uchicago.edu (alexandria.cs.uchicago.edu [128.135.11.87]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id XAA18433 for ; Tue, 5 Oct 1999 23:42:53 +0200 (MET DST) Received: from yeenoghu.cs.uchicago.edu (yeenoghu.cs.uchicago.edu [128.135.11.46]) by alexandria.cs.uchicago.edu (8.9.1/8.9.3) with ESMTP id QAA26964; Tue, 5 Oct 1999 16:42:51 -0500 (CDT) Received: from yeenoghu.cs.uchicago.edu (localhost [127.0.0.1]) by yeenoghu.cs.uchicago.edu (Postfix) with ESMTP id 7E194198; Tue, 5 Oct 1999 16:42:50 -0500 (CDT) To: skaller Cc: caml-list@inria.fr Subject: Re: Can someone explain? In-Reply-To: Your message of "Tue, 05 Oct 1999 08:57:20 +1000." <37F930D0.6547CE0F@maxtal.com.au> Date: Tue, 05 Oct 1999 16:42:50 -0500 From: Lyn A Headley Message-Id: <19991005214250.7E194198@yeenoghu.cs.uchicago.edu> Sender: weis >>>>> "skaller" == skaller writes: >> The only way to access a value of a class instance is via >> method invocation: you have to define a method that returns the >> value. skaller> Thanks, but you have not answered the real question skaller> here: WHY are the values present in the interface when skaller> they are not accessible via the interface? good question. >> > Similarly, what is the purpose of allowing 'virtual' > >> methods in class types and class declarations in > module >> signatures? >> >> Virtual methods are methods that are declared but not >> implemented: sub-classes must define them. skaller> Again, I knew that, the real question is WHY this skaller> information is in the _interface_?? [I know] skaller> I will change the representation to match Python, skaller> using an array (or perhaps a doubly linked list of skaller> arrays), and report back. 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. 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. skaller> You would need the WHOLE interpreter :-) I will make skaller> that available in the near future, asking for help to skaller> speed up the implementation. yum. skaller> I think it would be VERY useful to have an ocaml skaller> written Python interpreter/compiler as fast as, or faster skaller> than, CPython. There are a lot of Python users out there skaller> who could be introduced to ocaml this way, and gain skaller> immediate benefits from a faster implementation skaller> (particularly the compiler). Me too! This could be a big thing for ocaml. Darn it, now you've got me all psyched about ocaml again. Too bad I already committed to Eiffel for my latest project. [snip] skaller> A doubly linked list has a node containing two pointers, [snip] >> > and 't iterator = > Empty > | Node of 't d_node skaller> This is the type of a pointer to a node. In ocaml, An ocaml "port" of STL would kick ass. 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) 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? -Lyn