help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to improve the readability of (any) LISP or any highlevel functi


From: Jan Burse
Subject: Re: How to improve the readability of (any) LISP or any highlevel functional language to the level of FORTH ?
Date: Sat, 01 Jan 2011 19:05:24 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11

Hi

I am responding from comp.lang.prolog.

Nathan schrieb:
Ruby is just a blast to code in. If it had stronger GUI support, no
global interpretor lock,

I think a global interpreter lock can be avoided by combining
the following approaches in logic programming languages:

0) Actual parameter data structures (of a thread running in the
   interpreter) should be immune to concurrency problems.
1) Conversions between actual parameter data structures, and
   global data structures (of the interpreter).
2) No exposure of global data structures,
   only access via the interpreter.
3) When exposure of global data structures, then access via
   thread safe methods.

Interestingly 0) and 1) is automatically assured by Prolog implementations. Actual parameters are not visible between
threads, and clause instantiation can be viewed as producing
actual parameter data structures from global data structures,
whereas asserting a clause can be viewed as producting global
data structures form actual parameter data structures.

Point 2) and 3) depend on the API design for a Prolog implementation.
For point 2) it is assumend that a multi-threaded interpreter will
not have any problems accessing its global data structures, for
example in the case of Prolog clauses, concurrently. For 3) it
is assumed that corresponding access can be encapsulated in
thread safe methods.

There are a couple of Prolog system implementations around
that support multi threading. For example SWI Prolog. Or
Jekejeke Prolog. In Jekejeke Prolog mostly the approach 2)
has been followed by the API on purpose.

and either lazy evaluation or preemptive multi-threading (with a
> strong preference toward the latter),

The threads deployed by multi-threading Prologs are preemptive.
They typically don't follow the cooperative model, because
coopertaive threads have only limited applications. SWI
Prolog has preemptive threads (*), Jekejeke Prolog inherits
the property from the threads of the Java VM.

Best Regards

(*)
http://hcs.science.uva.nl/projects/SWI-Prolog/articles/iclp-03.pdf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]