[erlang-questions] The compiler "eats" structures which are not separated by commas

[Jan Burse]

Jan Burse schrieb:
>
> Are especially dangerous. They insuinate that late
> binding (*) can be solved performance wise. I am primarily
> concerned with the idea that some borders can be pushed
> that have not already been push for example by my contrast
> OO language Java. So I am awaiting clarification:
>
> JB wrote:
>  > In which proposal is this substantiated?

For example one solution is to use global oriented
vtables. That is the keys name space leads to indexes,
and all frames will have the same eventually very large
vtable. I am currently using this approach for
Jekejeke Prolog, for thread local predicates. But
would be interested in alternative solutions.

Here processes not only have state inside their
local variables of their tail recursive predicates
as in Erlang, but predicate modifications can be also
local to the processes, not sure whether this has
made its way into Erlang. It is very useful for
hypothetical reasoning inside a process.

Many Prolog systems do have this in one or the
other form. XSB calls it private and not thread
local. Some Prolog system probably implement it by
the thread local support found in some C compilers.
I don't implement it via ThreadLocal found in Java.

You might want give it a try, its still experimental:
http://www.jekejeke.ch/idatab/doclet/prod/en/docs/05_run/02_reference/07_theories/06_system/04_thread.html

The performance penalty is practically zero in Jekejeke
Prolog. My thread local predicates have the same speed
as the normal predicates. There is one advantage for
thread local predicates, they don't need synchronization
compared to normal predicates. This probably compensates
the additional indirection via the global oriented vtables.

But the global oriented vtables solution doesn't need
type information. It only needs generation of sernos
for key names, i.e. atoms and caching of these sernos
inside the code that is executed. So without type
information one will have at least amortized cost
of O(1) for:

     frame_has/2
     frame_value/2
     frame_find/2

The other operations that generate new frames, are also
not that expensive, but there is no yet support for them.
So for example copying one clauses from one predicate in
one process to another predicate in another process would
not be slowed down by finding the predicate. This could
be use for message passing.

Bye