[erlang-questions] Add a new data structure to erlang VM.
Richard A. O'Keefe
ok@REDACTED
Tue Jul 12 00:44:48 CEST 2016
On 11/07/16 9:07 PM, Constantin Kulikov wrote:
>> ETS tables are not data structures in an Erlang process.
>Anyway, they are mutable(right?)
Yes, ETS tables are mutable. Which is why they are not *Erlang* data
structures.
> and I didn't ask that a new data structure must necessarily reside in
> an Erlang process.
If we are talking about something that Erlang code has a *name* for
(represented as say a reference) but cannot work with directly, then
adding a data structure to Erlang is pretty much what NIFs are for.
Objects that are large, long-lived, few, and have explicitly managed
lifetimes are a good fit for that. Data base connections, special
access to devices, that sort of thing.
Objects that are small, multitudinous, and evanescent are not.
The thing is that we are all floundering in the dark because you have
yet to tell us what it is you actually want to add and what problem
you expect to solve by adding it, and for that matter why it needs to
be in the Erlang VM at all instead of being a C node.
Background: I worked on Xerox Quintus Prolog, which put Quintus Prolog
and Interlisp-D in the same box. The design we ended up with was the
least painful and most efficient we could devise, and basically Prolog was
given a chunk of the address space and Interlisp-D was given the rest
and cross-language procedure calls involved copying. We worked hard
to make sure each language's GC had to know as little as possible about
the other. Around the same time, the Poplog system -- which is open
source these days -- was in flower. That put Pop-11, Prolog, Common
Lisp, SML, and I think Scheme in the one address space. It was and is
an impressive piece of work but meant that Prolog and SML performance
suffered. In contrast, the Prolog component of XQP did not suffer, as
we didn't have to make compromises.
More information about the erlang-questions
mailing list