From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Common Lisp ontop of guile Date: Mon, 19 May 2014 22:36:34 +0200 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01419c6a1ca9a404f9c6b88b X-Trace: ger.gmane.org 1400533300 28327 80.91.229.3 (19 May 2014 21:01:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 May 2014 21:01:40 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 19 23:01:34 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WmUgT-0002s5-Sc for guile-devel@m.gmane.org; Mon, 19 May 2014 23:01:21 +0200 Original-Received: from localhost ([::1]:50143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmUId-0008Ip-7B for guile-devel@m.gmane.org; Mon, 19 May 2014 16:36:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmUIX-0008IU-RQ for guile-devel@gnu.org; Mon, 19 May 2014 16:36:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmUIW-0001tn-Gu for guile-devel@gnu.org; Mon, 19 May 2014 16:36:37 -0400 Original-Received: from mail-we0-x22d.google.com ([2a00:1450:400c:c03::22d]:47780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmUIW-0001pS-7A for guile-devel@gnu.org; Mon, 19 May 2014 16:36:36 -0400 Original-Received: by mail-we0-f173.google.com with SMTP id u57so6017257wes.4 for ; Mon, 19 May 2014 13:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZqIZ8zFJit8fchwSvcVRp5as3oPM9NXf6enJVe16G3M=; b=Veh9d8vckJ9t/CPcbx90QBi7OSTv7SZHOPyCIo6sXLao9k2VnDLPj7vEAG05oV4ICY yxG9qegn2iQoMPjSw2g/LUXX+t59zyCCGAA4Z1UAj6CMvxUMTV8tF90H0+cEHuidzJGk PdDeJQY8aVVcqs7NPaUcMRl7FJsA/Ko5GTtYVo5CQnwL1CcH3aZxPOXYvoDVJwszW/+G sbJXmhehSeOu/pMMgQ3YVM1TPFXUQrUDfs2lqrdTXKfi0Dk6vzvAhpB9PWbhSC7yYhow jc8WdbCGDbLM/cCik0gcSx/+9wexQICtrCnF8miuguNL+VNbbqOOk3zXy7BLaL+ROen7 38Mw== X-Received: by 10.194.161.168 with SMTP id xt8mr32233878wjb.35.1400531794556; Mon, 19 May 2014 13:36:34 -0700 (PDT) Original-Received: by 10.216.33.70 with HTTP; Mon, 19 May 2014 13:36:34 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::22d X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17149 Archived-At: --089e01419c6a1ca9a404f9c6b88b Content-Type: text/plain; charset=UTF-8 Hi, I saw on irc that nalginrut was dreaming of implementing common lisp ontop of guile I have spent some time thinking on that and came to the following conclusions. 1. Common lisp symbolic treatment and guile's syntax system does not mix well. 2. If we want to reuse CL code we will find out that the it produces tons of tagbodies. This can't be directly implemented by letrecs but delimeted continuations is needed. And with those it is somemwhat fuzzy how well optimized the code will become e.g. there is a risk of slow tagbodies. On the other hand doing an implementation of CL might challange the guile hackers to produce an even better optimizer. So tagbodies is doabale and I have code that does them. 3. CL is littered with use of put and get together with symbols, these probably have to be fast in order to be usable for the common lisp code out there. But for a first try, a simple hashmap will probaly do. 4. CL symbols has a variable context and a function context, again a hashmap can be used on the symbols namespace combo. 5. The CL spec is pretty hefty but most of it should be able to be derived from a smaller subset of ideoms. I would try to find an implementation (or an early correct version of an implementation of CL) where this is a fact (matured versions tend to optimize ideoms to death and therefore many idems will be special) Ask around in CL forums for the best fit. 6. Not sure how to make the CL module system to interop with the guile system Again if one can find a CL implementation witch is mostly written in CL, then the effort might not be too hefty. A question is how one would treat common lisp symbols, if we would like to interoperate between scheme and CL one need to do it with symbol name mangling e.g. f @ ns => f::ns With this we may be able to write a reasonable compiler to scheme Another possibility might be to treat symbols as vectors e.g. #(cl-symbol symbol ns (fslot) (vslot) (put/get-alist)) It's but ugly, but for sure the guile compiler would make sure that all symbol vectors point to the same vector hence the fslot vslot and put/get-alist is unique and can be mutated as is, then of cause there need to be some code written to be able to lookup these structures in other modules. Perhaps all symbols in a module can be put as a namespace mangled symbol guile exported as symbol e.g. g::nm for use in scheme code also a good thing with this is that ns can be a list of symbols just as in guile. I'm sure I've mised many points but at least these thoughts might initiate a discussion. Cheers! --089e01419c6a1ca9a404f9c6b88b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, I saw on irc that nalginrut was dreaming of implementi= ng common lisp ontop of guile
I have spent some time thinking on that a= nd came to the following conclusions.

1. Common li= sp symbolic treatment and guile's syntax system does not mix well.
2. If we want to reuse CL code we will find out that the it produces t= ons of tagbodies.=C2=A0
This can't be directly implemented by= letrecs but delimeted continuations is needed. And with those it is somemw= hat fuzzy how well optimized the code will become e.g. there is a risk of s= low tagbodies. On the other hand doing an implementation of CL might challa= nge the guile hackers to produce an even better optimizer. So tagbodies is = doabale and I have code that does them.
3. CL is littered with use of put and get together with symbols, these= probably have to be fast in order to be usable for the common lisp code ou= t there. But for a first try, a simple hashmap will probaly do.
4. CL symbols has a variable context and a function context, again a hashma= p can be used on the symbols namespace combo.
5. The CL spec is p= retty hefty but most of it should be able to be derived from a smaller subs= et of ideoms. I would try to find an implementation (or an early correct ve= rsion of an implementation of CL) where this is a fact (matured versions te= nd to optimize ideoms to death and therefore many idems will be special) As= k around in CL forums for the best fit.
6. Not sure how to make the CL module system to interop with the guile= system

Again if one can find a CL implementation = witch is mostly written in CL, then the effort might not be too hefty.

A question is how one would treat common lisp symbols, = if we would like to interoperate between scheme and CL one need to do it wi= th symbol name mangling=C2=A0
=C2=A0 =C2=A0e.g. f @ ns =3D> f:= :ns

With this we may be able to write a reasonable compiler to s= cheme

Another possibility might be to treat symbol= s as vectors e.g.=C2=A0
#(cl-symbol symbol ns (fslot) (vslot) (pu= t/get-alist))

It's but ugly, but for sure the guile compiler woul= d make sure that all symbol vectors point to the same vector hence the fslo= t vslot and put/get-alist is unique and can be mutated as is, then of cause= there need to be some code written to be able to lookup these structures i= n other modules. Perhaps all symbols in a module can be put as a namespace = mangled symbol guile exported as symbol e.g. g::nm for use in scheme code a= lso a good thing with this is that ns can be a list of symbols just as in g= uile.

I'm sure I've mised many points but at least th= ese thoughts might initiate a discussion.

Cheers!<= /div>

--089e01419c6a1ca9a404f9c6b88b--