The CL complatibility module

[Robert Virding]

So work is continuing with this.

So there are some CL functions which work on a symbols plist. While LFE/erlang doesn't really have symbols with plists and values it would be quite easy to fake this. We would just define an ETS table called lfe-symbol-plist which contains the symbols which have been given an explicit plist and then the symbol plist functions get, putprop and remprop could access table. The same for symbol values with an ETS table lfe-symbol-value. This could be quite fun if we want it. It would only have default support in the cl module and force us to use the right plist functions: get, putprop and remprop for a symbol's plist; and getf, putf and get-properties on the actual plists.

Robert

A copy (sort of) of something I wrote earlier on the cl module to clarify its position:

The cl module is just a library containing many of the standard CL library functions which gives you the possibility of writing in a CL style. Not everything can be included, for example the nXXXX functions which mutate data, and some features don't mesh well with Erlang/LFE. For example equating nil/() and predicates which in Erlang/LFE return true/false while in CL are truthy and return nil/() and anything else. It is in no way a fundamental part of LFE and is just an add-on which is not used by the base LFE. If anyone feels inclined to do a similar module for clojure then I will definitely consider including it. Again it would just be an add-on. These could easily be included in the base release.

[H Durer]

Out of curiosity: you need a process to own that table, right?  How do you plan to manage the life cycle of that table/process?

Re property list themselves: do people still use these?  I always assumed they were merely some left-overs from old times long gone.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[arp...@cryptolab.net]

On 2015-11-05 13:28, H Durer wrote:
> Out of curiosity: you need a process to own that table, right? How do
> you
> plan to manage the life cycle of that table/process?
>
> Re property list themselves: do people still use these? I always
> assumed
> they were merely some left-overs from old times long gone.

Yea, I use proplists all the time. They could use a bit of syntax love
to
make it look like CL keywords though.

[Robert Virding]

Well, as I said it is a little bit hacky at the moment.

The process that does the first call to get/putprop/remprop creates the ets table and so owns it, BUT it makes the init process, <0.0.0>, heir to that table so when the table creator process dies it is then owned by the init process. This is safe because if the init process dies the whole system goes down. A bit sneaky/cunning/ugly.

This works but I don't know if we actually want this feature. If we turn LFE into an application with processes then one of these who own the tables.

Robert

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.

[Robert Virding]

You mean with :key format tags? You can create the atoms all-right but they are normal atoms there is no way to make them always be atoms/symbols and not variables so they need quoting.

I wonder if we really need to go this far?

Robert