non-Erlang Erlang grammars

[Robert Virding]

"Vlad Dumitrescu" <vladdu@REDACTED> writes:
>----- Original Message -----
>I was thinking about this problem, and I suppose the solution using funs
>would be to provide an ets:lookup/3, where the third argument is a fun that
>filters the results of ets:lookup/2 and also filters the elements that will
>be outputted to the result. Also, list comprehensions that accept an ets
>generator would also do fine, even more elegantly than simple funs.
>
>As I understand it, the big problem is how to make the funs evaluate in ets
>space, not local space. But otherwise I can't understand why these funs
>should abide by the following rules
>>- no message passing
>>- no external function calls
>>- no loops
>>- no operations that are not known to be O(1)
>
>Is it an efficiency aspect? Or an implementation issue? Or a more deep-going
>architecture one?
>Is it because the funs woill be evaluated in a different space?
>Could someone please explain this? Thanks.

It is basically an issue about efficiency in the current 
implementation.  Today ets tables are stored in a separate heap area 
outside all processes so data transfer with insert and lookup are done 
by copying between the ets table area and the process heap.

When searching for data you would like to be able to do as much of the
selection work as possible without copying any data from the ets area.
that is why you have functions like match/match_object which take a
pattern, the pattern matching can be done without copying. This also the
reason why you have match specs, they can be interpreted by the 
emulator without copying any data.

This also means that functions which fold over tables with general 
functions will be inherently more inefficient as all the objects must 
be copied before the fold function can be applied.

Therefore if you wish to replace match specs with funs, which would 
look MUCH better, then you have to be very restrictive, basically what 
I listed, to get the same efficiency as match specs.  Basically coding 
match specs in the pattern and guard part of fun clauses.

    fun (#foo_type{a=A,b=B}) when A > B+3 -> true;
        (#foo_type{c=sune}) -> true;
        (Other) -> false.

The funs would not be evaluating in any space as the ets table areas 
are very specialised for storing ets tables and not suitable for 
general term usage.  I suppose you could run in normal process space 
but this would cause some really hairy problems with the collector as 
you would be adding inter heap references to system which does support 
it.

By checking the legality of the funs at run time you get around the 
problem of how you would check these funs at compile time.  Basically 
impossible unless you impose severe restriction on how the funs are 
defined.

I would LOVE to be to send over general funs with match/match_object to 
extract objects from tables but this would mean an almost complete 
rewrite of the ets table code, which is unrealistic today.

	Robert

-- 
Robert Virding                          Tel: +46 (0)8 545 55 017
Alteon Web Systems                      Email: rv@REDACTED
S:t Eriksgatan 44                       WWW: http://www.bluetail.com/~rv
SE-112 34 Stockholm, SWEDEN
"Folk säger att jag inte bryr mig om någonting, men det skiter jag i".