Structs (was RE: Record selectors)

Ulf Wiger etxuwig@REDACTED
Tue Jan 21 17:13:42 CET 2003


On Tue, 21 Jan 2003, Richard Carlsson wrote:

>Eh, in fact it's not a problem with packages. The problem
>is that the Thing.tag notation (where Thing is anything
>that's not an atom) is already stolen by the fairly obscure
>Mnemosyne syntax. (It denotes a record access to some
>implicitly-named record - I don't even want to know the
>details.)

If we introduce proper structs, then shouldn't mnemosyne be
updated to use those?


>Anyhow, this reminds me that I actually would like to ask
>this eminent list whether the Mnemosyne syntax could be
>lifted out of the Erlang language - instead one could have
>a separate preprocessor for those that use Mnemosyne,
>creating Normal Erlang (TM) files from ".erm" files or
>whatever. Would this be a too big penalty on some people
>out there?

One interesting aspect of the mnemosyne support is the
'query ... end' construct. To say that it's well documented
would be an exaggeration. My understanding is that it
returns a handle that can later be used when executing a
query. Cool, but couldn't one try to unify normal list
comprehensions, the struct semantics and the 'query ... end'
construct to provide real language support for query
processing?

I imagine that 'query NormalListComprehension end' could
return something that could be post-processed and optimized,
even though it is only used on normal lists, and a
mnemosyne-like utility could be made to work against other
databases than mnesia -- perhaps even across multiple
databases -- or perhaps not a database at all, but rather
using WSDL or other to query internet sites for data.

(I'm assuming that backward compatibility with the existing
mnemosyne is not a topmost priority. Please correct me,
those of you out there who consider yourselves heavy
mnemosyne users.)

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks




More information about the erlang-questions mailing list