Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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




  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