From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Burse Newsgroups: gmane.emacs.help 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 Organization: albasani.net Message-ID: References: <80ceeca0-1d32-47d1-ba96-feb4d9729c3a@v17g2000yqv.googlegroups.com> <87pqsgk8v9.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1293909708 10422 80.91.229.12 (1 Jan 2011 19:21:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 1 Jan 2011 19:21:48 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jan 01 20:21:44 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PZ71K-0003bZ-OC for geh-help-gnu-emacs@m.gmane.org; Sat, 01 Jan 2011 20:21:42 +0100 Original-Received: from localhost ([127.0.0.1]:48250 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZ71K-0005CT-6N for geh-help-gnu-emacs@m.gmane.org; Sat, 01 Jan 2011 14:21:42 -0500 Original-Path: usenet.stanford.edu!goblin1!goblin2!goblin.stu.neva.ru!weretis.net!feeder4.news.weretis.net!news.albasani.net!not-for-mail Original-Newsgroups: comp.lang.functional, comp.lang.lisp, gnu.emacs.help, comp.lang.forth, comp.lang.prolog Original-Lines: 53 Original-X-Trace: news.albasani.net LtMFVhClRjYacFFllP6+g1jDSeAqq5Cwd+ahDcy/xrWbZcae7R9xGTYEIvxIX0JpwEsij2mJJmP13t1OF+hScQ== Original-NNTP-Posting-Date: Sat, 1 Jan 2011 18:05:26 +0000 (UTC) In-Reply-To: Cancel-Lock: sha1:z8ciN/IYfasJ9R6SiJV9Ve96VJA= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 Injection-Info: news.albasani.net; logging-data="dcVovUv/2qO5l2awyBRFkv25mh48QIiCQ9NATUduKAFcG0j67eoObkwPX/+r2tbVk1wMn4KRwYRUcX/wgMolFAKgDxViSJMlo0whRzEZNENanbb9gn4Fg5Rzf/Iyzpm5"; mail-complaints-to="abuse@albasani.net" Original-Xref: usenet.stanford.edu comp.lang.functional:69059 comp.lang.lisp:297062 gnu.emacs.help:183811 comp.lang.forth:160227 comp.lang.prolog:43988 X-Mailman-Approved-At: Sat, 01 Jan 2011 14:19:51 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:78025 Archived-At: 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