From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: Common Lisp ontop of guile Date: Tue, 20 May 2014 10:06:53 +0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013d1cf86e4b9704f9cb5582 X-Trace: ger.gmane.org 1400573161 24228 80.91.229.3 (20 May 2014 08:06:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 May 2014 08:06:01 +0000 (UTC) Cc: guile-devel To: Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue May 20 09:50:39 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 1WmZSI-0003rx-G5 for guile-devel@m.gmane.org; Tue, 20 May 2014 04:07:02 +0200 Original-Received: from localhost ([::1]:50992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmZSH-00089f-Kg for guile-devel@m.gmane.org; Mon, 19 May 2014 22:07:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmZSD-00089a-8m for guile-devel@gnu.org; Mon, 19 May 2014 22:06:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmZSC-0003VZ-4j for guile-devel@gnu.org; Mon, 19 May 2014 22:06:57 -0400 Original-Received: from mail-la0-x22b.google.com ([2a00:1450:4010:c03::22b]:51298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmZSB-0003VP-KG for guile-devel@gnu.org; Mon, 19 May 2014 22:06:56 -0400 Original-Received: by mail-la0-f43.google.com with SMTP id mc6so4699315lab.2 for ; Mon, 19 May 2014 19:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bnRl3wixMysCWhF3vhWeXIWmzVUkqpYtR8L6ljW/DUA=; b=PF1G0YTCYXylGdTbg+yzdnY2/Ex7TTlOIczmVQQPerqfHk7pMbPrzW5g4hm91zNXam lQdoFtWOJDyvJlp+QrzZv0yVslU51mCd9rqCUk97hc6CXCBmWFQziLl/X+6hd/7BayOl wdwxCd4HaHAqu9ov14kS/U+YV9rYmiJKpUbBf/KXlxGw4f2g5Bm2mlHnKwoZaNlkgnqi 8hOBZnICMbVtYAp5AXxc25X+dN36OPFwzcLvd7xDMqiSMFdMnjNTs9lowc1+k8iDE/DB 4jtOQt9iqrxUzLYpMkMD0+juQHttc7xAmgZcnvRUZYA1A11+TTmIJlEULaOJuQ0woWWX qANw== X-Received: by 10.152.4.137 with SMTP id k9mr19420631lak.46.1400551613809; Mon, 19 May 2014 19:06:53 -0700 (PDT) Original-Received: by 10.152.23.103 with HTTP; Mon, 19 May 2014 19:06:53 -0700 (PDT) Original-Received: by 10.152.23.103 with HTTP; Mon, 19 May 2014 19:06:53 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22b 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:17151 --089e013d1cf86e4b9704f9cb5582 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi Stefan! Thanks for the reply! Please let me share some ideas: 2014=E5=B9=B45=E6=9C=8820=E6=97=A5 =E4=B8=8A=E5=8D=884:36=E4=BA=8E "Stefan = Israelsson Tampe" =E5=86=99=E9=81=93=EF=BC=9A > > 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. I see, but if someone want to do a serious hack for CL compiler on Guile, a simple(maybe naive) mind to translate AST of CL to tree-il and pray for the heaven is obvious insufficient. :=E2=80=93) So one has to customize the backend for CL properly. > 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. Yes I agreed. I have to point out that we can hardly expect Guile core provides generic solution for various languages, which means the frontend hacker has to consider to produce better optimizer with the tools Guile provided (CPS,DCE,CSE...). Maybe the original tools is not suit(?), and one has to write new one. ... > I'm sure I've mised many points but at least these thoughts might initiate a discussion. > I'm hacking on guile-lua these days, when it's done, I may have some experiences on frontend. Lua seems relatively easier than CL situation. But it's hard when you want it to be full compatible with the original one. Any comments? :) > Cheers! > --089e013d1cf86e4b9704f9cb5582 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

hi Stefan! Thanks for the reply!
Please let me share some ideas:

2014=E5=B9=B45=E6=9C=8820=E6=97=A5 =E4=B8=8A=E5=8D=884:36=E4= =BA=8E "Stefan Israelsson Tampe" <stefan.itampe@gmail.com>=E5=86=99=E9=81=93=EF=BC=9A

>
> Hi, I saw on irc that nalginrut was dreaming of implementing common li= sp ontop of guile
> I have spent some time thinking on that and came to the following conc= lusions.
>
> 1. Common lisp symbolic treatment and guile's syntax system does n= ot mix well.

I see, but if someone want to do a serious hack for CL compi= ler on Guile, a simple(maybe naive) mind to translate AST of CL to tree-il = and pray for the heaven is obvious insufficient. :=E2=80=93)
So one has to customize the backend for CL properly.

> 2. If we want to reuse CL code we will find out that th= e it produces tons of tagbodies.=C2=A0
> This can't be directly implemented by letrecs but delimeted contin= uations 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 h= and doing an implementation of CL might challange the guile hackers to prod= uce an even better optimizer. So tagbodies is doabale and I have code that = does them.

Yes I agreed. I have to point out that we can hardly expect = Guile core provides generic solution for various languages, which means the= frontend hacker has to consider to produce better optimizer with the tools= Guile provided (CPS,DCE,CSE...). Maybe the original tools is not suit(?), = and one has to write new one.

...

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

I'm hacking on guile-lua these days, when it's done,= I may have some experiences on frontend. Lua seems relatively easier than = CL situation. But it's hard when you want it to be full compatible with= the original one.

Any comments? :)

> Cheers!
>

--089e013d1cf86e4b9704f9cb5582--