To: skaller <skaller@maxtal.com.au>
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 <laheadle@cs.uchicago.edu>
Message-Id: <19991005214250.7E194198@yeenoghu.cs.uchicago.edu>
>>>>> "skaller" == skaller <skaller@maxtal.com.au> 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. <smacks his chops noisily>
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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:26 MET