Re: Can someone explain?

From: Lyn A Headley (laheadle@cs.uchicago.edu)
Date: Tue Oct 05 1999 - 23:42:50 MET DST


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