From: Lyn A Headley <laheadle@cs.uchicago.edu>
To: skaller <skaller@maxtal.com.au>
Cc: caml-list@inria.fr
Subject: Re: Can someone explain?
Date: Tue, 05 Oct 1999 16:42:50 -0500 [thread overview]
Message-ID: <19991005214250.7E194198@yeenoghu.cs.uchicago.edu> (raw)
In-Reply-To: Your message of "Tue, 05 Oct 1999 08:57:20 +1000." <37F930D0.6547CE0F@maxtal.com.au>
>>>>> "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
next prev parent reply other threads:[~1999-10-06 14:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-09 16:34 strange behavior of the object type-checker Pierre Boulet
1999-09-09 19:43 ` Jerome Vouillon
1999-09-28 18:56 ` Can someone explain? skaller
1999-10-04 8:23 ` Pierre Weis
1999-10-04 22:57 ` skaller
1999-10-05 9:43 ` Jerome Vouillon
1999-10-05 19:35 ` Gerd Stolpmann
1999-10-06 9:42 ` skaller
1999-10-08 0:17 ` Problem of coercion in recursive class definitions Peter Schrammel
1999-10-05 21:42 ` Lyn A Headley [this message]
1999-10-06 10:17 ` Can someone explain? skaller
1999-10-13 19:16 Juergen Pfitzenmaier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19991005214250.7E194198@yeenoghu.cs.uchicago.edu \
--to=laheadle@cs.uchicago.edu \
--cc=caml-list@inria.fr \
--cc=skaller@maxtal.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox