[23817] in Perl-Users-Digest
Perl-Users Digest, Issue: 6020 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 20:41:30 2004
Date: Thu, 29 Jan 2004 17:35:52 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 29 Jan 2004 Volume: 10 Number: 6020
Today's topics:
Re: Lisp2Perl - Lisp to perl compiler <hhdave@SPAMAROONEY.blueyonder.co.uk>
Re: Lisp2Perl - Lisp to perl compiler <usenet@jasoegaard.dk>
Re: Lisp2Perl - Lisp to perl compiler <qrczak@knm.org.pl>
Re: Lisp2Perl - Lisp to perl compiler <costanza@web.de>
Re: Lisp2Perl - Lisp to perl compiler <qrczak@knm.org.pl>
Re: Lisp2Perl - Lisp to perl compiler <jrm@ccs.neu.edu>
Re: Lisp2Perl - Lisp to perl compiler <costanza@web.de>
Re: Lisp2Perl - Lisp to perl compiler <find@my.address.elsewhere>
Re: Lisp2Perl - Lisp to perl compiler <prunesquallor@comcast.net>
Re: Lisp2Perl - Lisp to perl compiler <find@my.address.elsewhere>
Re: Lisp2Perl - Lisp to perl compiler <hhdave@SPAMAROONEY.blueyonder.co.uk>
Re: Lisp2Perl - Lisp to perl compiler <costanza@web.de>
Re: Lisp2Perl - Lisp to perl compiler (Thomas F. Burdick)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 20 Jan 2004 00:18:17 +0000
From: David <hhdave@SPAMAROONEY.blueyonder.co.uk>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <9s_Ob.178$ff5.141@news-binary.blueyonder.co.uk>
Thomas F. Burdick wrote:
> David <hhdave@SPAMAROONEY.blueyonder.co.uk> writes:
>
>
>>Producing readable, hackable perl code was not one of the goals of my
>>program (as you might have guessed if you've seen any of the output!). I
>>had sort of figured that when you started using macros of any degree of
>>complexity then, whether you are translating to perl or not, you
>>wouldn't want to see the entirety of the macro expanded code anyway.
>>This is certainly the case with one largeish program I've written - the
>>amount of expanded code is enormous compared to the un-macro-expanded
>>code.
>
>
> It does take some care when writing macros, but it's pretty much the
> same as always being in "I might have to debug this macro" mode. If
> you use meaningful variable names, and prune unused branches, it helps
> a lot. Plus, if you allow the macros to insert comments into the
> resulting code, the volume of Perl code isn't so daunting (kinda like
> if you wrote it by hand).
>
>
>>Also, using (cond) statements, especially nested ones, produces
>>horrible looking perl code. They compile down to lots of trinary ifs
>>(a?b:c) in perl. The fact is, if I were programming in perl my program
>>just wouldn't be structured like that, whereas in lisp it seems a
>>natural thing to do.
>
>
> Right, whereas in Lisp you might write (setf x (cond ...)), in Perl,
> you'd write:
>
> if (...) {... $x = 1;}
> elsif (...) {... $x = 2;}
> else {... $x = 3;}
>
> In my compiler, the translators for compound expressions have three
> modes: producing code for side-effect only, producing code used for
> its value, and producing code to put the value in a specific location.
> So, depending on context, cond might expand into if/elsif/else, or
> trinary-if, or if it's complicated and/or nested, a call to an
> anonymous lambda:
>
> (sub { if (...) {... return 1;}
> elsif (...) {... return 2;}
> else {... return 3;} })->();
>
>
Sounds much like what I did except that I had 2 modes, not 3. I did have
to create an anonymous sub (lambda) in the perl in certain cases and
immediately eval it. That was cunning I thought. My compiler doesn't do
that in the case above though. I actually noticed (I think) that ifs
which were forced to compile to the trinary operator (since the value
was used) were somewhat faster than the expression (side effect only)
ones too. I suppose that's due to not creating a new scope in perl.
>>I guess readable code is nice to have if you are 'supposed to be'
>>programming in perl, but really want to use Lisp :)
>
>
> Well, it wasn't so much "supposed to be", as much as the final product
> had to be in Perl, so it would be easy to find someone later to
> maintain it. No one had any problem with me using whatever expert
> development tools I wanted, as long as the output was maintainable
> as-is. But, pretty much, yeah :)
>
>
Fair enough. It was good that you managed to find a way of still using
lisp despite the requirement for maintainability by a perl programmer.
>>I'd be very interested in seeing the source code to your program if I may.
>
>
> I'm sitting on it, pending my thinking about how much time/effort it
> would take to make it useful to the general public, and if there's a
> market for it or not. And it's a mess of unfactored hacks, because I
> was concentrating on the systems I was supposed to be writing, not the
> compiler itself.
>
>
I know the feeling. There are lots of improvements I want to make to
mine as well. For one thing I want to change the way the whole thing
works as I've used a bit of a hack to get things like this to work:-
(define (f x)
...some function of x...)
(defmacro my-macro (a b)
(list 'foo a (f b)))
Basically, in order that the macro can use the function defined before
it the function must be evaluated at compile time as well as runtime. I
think the root of this problem is that I want to be able to translate
the lisp code into a perl script which can be executed in the normal
way. I don't want to have to read in the lisp code and translate and
execute each form one by one. This means that the macro definitions must
executed at compile time (obviously) hence function definitions must be
executed at compile time. I don't think there should really be such a
distinction between compile time and runtime. I have found a solution
though, which lies in having an intermediate lisp representation which
is just fully macro expanded lisp code which is generated as a side
effect of 'running' a lisp file. This means that you can't just compile
the lisp to perl as such, you have to run it, and it gets compiled
(partially) as a side effect. Separate modules could then be linked, and
fully translated to perl, later. Of course, running a file is not a
problem if all it does is define things (functions and macros).
Does this seem sane?
Even though lisp2perl isn't nearly where I'd like it to be I decided to
just release it anyway. Where I work, even though I use this and people
see its benefits, I think it would have been frowned upon if I'd spent
loads of time on it instead of what I was using it for (what a
surprise). I wrote much of it at home.
>>Thomas F. Burdick wrote:
>>
>>
>>>I have to say, I'm horrified that you're thinking of a scheme-like
>>>Lisp. Perl itself has 4 namespaces, and I preserved that at my Lisp
>>>level (special-forms called FUNCTION, SCALAR, HASH, and ARRAY, but an
>>>inferencing engine generally takes care of picking the correct
>>>namespace for you). Of course, my Lisp->Perl is hosted on Common
>>>Lisp, so it was a pretty natural choice.
>>
>>I didn't intend it to be horrific! (well, not _too_ horrific :)
>
>
> Horrific because it's a Lisp->Perl compiler, but not because of the
> namespace issue? :)
>
>
Well, quite. There is something 'unsettling' about the concept. Really
I'm looking forward to the release of Perl 6, because then I could just
compile lisp to parrot vm code and still get the benefits of using perl
code from lisp. That doesn't help your perl generation of course. I'm
surprised to find that someone else has done something similar.
>>I know it seems an odd thing to use a 1 namespace language to translate
>>to a 4 namespace language. The reason I'm doing the scheme thing as
>>opposed to the common lisp thing is that I just kind of like the 1
>>namespace approach. It seems to be a lot simpler and remove the
>>necessity for ways of dealing with different kinds of bindings. I guess
>>that's just personal preference. It does produce rather odd looking perl
>>code (lots of '$fn->(...)'), but as I say, I don't really care about
>>that. As long as it executes fast enough. I don't know if $fn->()
>>executes any slower than &fn() - haven't checked.
>
>
> I'd imagine it is, but I wouldn't sweat an added indirection when
> you're talking about a bytecode interpreter.
>
>
>>The other thing I find, with hashes and arrays and such, is that half
>>the time in perl I end up using references to those things stored in
>>scalars anyway. Particularly when I need nested structures.
>
>
> Certainly, references to hashes especially are important, in
> particular for supporting defstruct. But if you want to interact with
> Perl builtins, being able to spread arrays is important. I guess you
> don't need all 4 namespaces for that, it just makes the resulting Perl
> less crazy-looking.
>
>
I know what you mean. Interacting with built ins is something I haven't
really solved nicely yet.
>>>>This lisp2perl translator/compiler works rather well. I've used it for a
>>>>major project at work. It's also self hosting (used to compile itself).
>
>
> Oooh, just noticed this. I'm glad I didn't try to go that route, I
> was happy to have all of Common Lisp at my disposal when writing my
> compiler. You might want to reconsider this decision, if you find
> yourself having implementation difficulties -- compilers are a lot
> easier to write in big languages (like CL, or one of the big scheme
> implementations' dialects with all the add-ons).
>
>
>>> - If you're at all interested in readability of the resulting Perl,
>>> don't offer gensym, just make-symbol (I accompanied mine with a
>>> with-gensyms macro that takes the symbol names from the vars that
>>> are bound to the new symbols). The compiler has to pay attention
>>> to scoping anyway, so you can have it resolve the names. Hmm, that
>>> wasn't a very comprehensible sentance, was it? How about an
>>> example:
>>>
>>> (let ((a (make-symbol "a"))
>>> (b (make-symbol "a"))
>>> (c (make-symbol "a")))
>>> `(let ((,a 0))
>>> (let ((,b 100))
>>> (setf ,a (+ ,b 1)))
>>> (let ((,c "hi"))
>>> (print ,c))
>>> (print ,a)))
>>> => (let ((#1=#:a 0))
>>> (let ((#2=#:a 100))
>>> (setf #1# (+ #2# 1)))
>>> (let ((#3=#:a "hi"))
>>> (print #3#))
>>> (print #1#))
>>> => { my $a = 0;
>>> my $a2 = 100;
>>> $a = $a2 + 100;
>>> {
>>> my $a = "hi";
>>> print $a
>>> }
>>> print $a; }
>>
>>I'm not quite sure I understand this at the moment. I'll have to think
>>about it some more. If the generated perl looked like that wouldn't it
>>clash with a variable called 'a'? I know I'm probably being thick here.
>
>
> The point is that a naive translation would be:
>
> { my $a1 = 0;
> { my $a2 = 100;
> $a1 = $a2 + 100; # clash
> { my $a3 = "hi";
> print $a3;
> }
> }
> print $a1;
> }
>
> If you named $a1, $a2, and $a3 all just $a, it would work, except for
> the line labeld "clash", which refers to an $a from two different
> scoping levels. So you can name $a1 and $a3 plain old $a, and only
> need to give $a2 a distinct name. In $a3's scope, it is the only $a
> variable used.
>
>
>>> - I'm not sure how you can get better undefined-function error
>>> reporting if you use the scheme approach. If you use multiple
>>> namespaces in your Lisp, the function namespace maps directly from
>>> Lisp to Perl, so you get normal Perl error reporting.
>>
>>I know, and it would seem the obvious thing to do wouldn't it? I still
>>like the single namespace though, but fear not - I thought of a solution
>>[me: looks up solution in files of notes about the program...]
>>Ah, here we go: I'm planning to modify the compiler to keep track of
>>lexical scope. That way, when it compiles a reference to an undefined
>>variable it should know and generate a warning about it. This may be
>>related to the gensym issue above. I guess generating symbols can be
>>done if I keep track of scope. I'll have to think about that some more.
>
>
> Yeah, they're def related.
>
>
>>Incidentally, can you think of a good argument AGAINST the scheme single
>>namespace approach?
>
>
> You get to it yourself in a second :)
>
>
>>> One thing you might consider here is losing the Lisp1-ness, but
>>> keeping the Scheme-like handling (normal evaluation) of the first
>>> position in a form.
>
> [snip]
>
>>That is a thought. I suppose it would make it play nicer with 'normal'
>>perl code. It would be particularly useful for using built in functions.
>>At the moment I have to 'declare' those:-
>>
>>(<perl-sub> print)
>>which expands to a (defmacro ...)
>
>
> Yeah, that's a benefit of recognizing at least the function and
> variable namespaces. That way, you can easily use normal Perl
> functions, and your functions aren't second-class citizens (eg, you
> can write a module that Perl coders can use directly, normally).
>
>
Well yes, I know _that_ benefit of the 2 namespace approach. But I mean,
forgetting about perl (ie if we were compiling to something else) can
you think of any benefit of 2 namespaces?
More sane integration with normal perl code would definitely be good.
I'll do something about it if/when I get chance. I just wish I had more
time to work on it. Ho hum.
>>I guess the first thing to do in any case is to extend the compilartion
>>functions so that they keep track of lexical scope.
>
>
> That is the traditional thing to do when writing scheme compilers :-)
>
Yeah, sounds like a good idea. I'm new at this :) Its a slightly unusual
compilation target too.
------------------------------
Date: Tue, 20 Jan 2004 01:55:36 +0100
From: =?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <usenet@jasoegaard.dk>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <400c7cef$0$177$edfadb0f@dread12.news.tele.dk>
David wrote:
> Well, quite. There is something 'unsettling' about the concept. Really
> I'm looking forward to the release of Perl 6, because then I could just
> compile lisp to parrot vm code and still get the benefits of using perl
> code from lisp. That doesn't help your perl generation of course. I'm
> surprised to find that someone else has done something similar.
Never say never:
<http://okmij.org/ftp/Scheme/Scheme-in-Perl.txt>
<http://www.venge.net/graydon/scm2p.html>
--
Jens Axel Søgaard
------------------------------
Date: Sun, 25 Jan 2004 13:39:32 +0100
From: Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <pan.2004.01.25.12.39.26.774237@knm.org.pl>
On Tue, 20 Jan 2004 00:18:17 +0000, David wrote:
> This means that the macro definitions must executed at compile time
> (obviously) hence function definitions must be executed at compile time.
> I don't think there should really be such a distinction between compile
> time and runtime.
I think there should. Please read
<http://www.cs.utah.edu/plt/publications/macromod.pdf>
--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
------------------------------
Date: Mon, 26 Jan 2004 22:18:20 +0100
From: Pascal Costanza <costanza@web.de>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <bv406o$pij$1@newsreader2.netcologne.de>
Marcin 'Qrczak' Kowalczyk wrote:
> On Tue, 20 Jan 2004 00:18:17 +0000, David wrote:
>
>>This means that the macro definitions must executed at compile time
>>(obviously) hence function definitions must be executed at compile time.
>>I don't think there should really be such a distinction between compile
>>time and runtime.
>
> I think there should. Please read
> <http://www.cs.utah.edu/plt/publications/macromod.pdf>
Oh dear. This is just another one of those bad examples of unbreakable
abstractions. Unbreakability sucks.
Generally speaking, layering or staging of approaches is probably a good
idea. But there might be situations in which I need to mix up the
layers/stages. If a proposed solution doesn't provide a back door for
these things, it sucks IMHO.
In general, computer scientists tend to confuse description and
prescription. I can describe a good solution and explain why it works
and what's good about it. But prescribing that everybody else should do
it exactly the same is the wrong conclusion. Especially when you don't
give them a way out.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
------------------------------
Date: Mon, 26 Jan 2004 22:36:44 +0100
From: Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <pan.2004.01.26.21.36.40.694333@knm.org.pl>
On Mon, 26 Jan 2004 22:18:20 +0100, Pascal Costanza wrote:
> Generally speaking, layering or staging of approaches is probably a good
> idea. But there might be situations in which I need to mix up the
> layers/stages. If a proposed solution doesn't provide a back door for
> these things, it sucks IMHO.
The same module can be independently imported to multiple stages,
so I don't see a problem.
--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
------------------------------
Date: Mon, 26 Jan 2004 17:00:10 -0500
From: Joe Marshall <jrm@ccs.neu.edu>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <ad4aid5h.fsf@ccs.neu.edu>
Pascal Costanza <costanza@web.de> writes:
> Marcin 'Qrczak' Kowalczyk wrote:
>
>> On Tue, 20 Jan 2004 00:18:17 +0000, David wrote:
>>
>>>This means that the macro definitions must executed at compile time
>>>(obviously) hence function definitions must be executed at compile time.
>>>I don't think there should really be such a distinction between compile
>>>time and runtime.
>> I think there should. Please read
>> <http://www.cs.utah.edu/plt/publications/macromod.pdf>
>
> Oh dear. This is just another one of those bad examples of unbreakable
> abstractions. Unbreakability sucks.
>
> Generally speaking, layering or staging of approaches is probably a
> good idea. But there might be situations in which I need to mix up the
> layers/stages. If a proposed solution doesn't provide a back door for
> these things, it sucks IMHO.
In this case, you don't want to mix up the layers or stages. Really.
The macro/module system that Matthew is describing is one that allows
the system to determine what to load and when to load it in order to
ensure that you have the macro-expansion code in place *before* you
attempt to expand the macros that use it.
Mixing up the layers or stages means that you want to have circular
dependencies in your macro expansions, i.e., macro FOO needs the
QUASIQUOTE library to expand, but the QUASIQUOTE library is written
using the macro FOO.
------------------------------
Date: Mon, 26 Jan 2004 23:35:20 +0100
From: Pascal Costanza <costanza@web.de>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <bv44n7$3mi$1@newsreader2.netcologne.de>
Marcin 'Qrczak' Kowalczyk wrote:
> On Mon, 26 Jan 2004 22:18:20 +0100, Pascal Costanza wrote:
>
>>Generally speaking, layering or staging of approaches is probably a good
>>idea. But there might be situations in which I need to mix up the
>>layers/stages. If a proposed solution doesn't provide a back door for
>>these things, it sucks IMHO.
>
> The same module can be independently imported to multiple stages,
> so I don't see a problem.
I haven't analyzed the issues in all details, but someone reported to me
that my implementation of dynamically scoped functions wouldn't be
possible because of the separation of stages in that module system.
I don't see how my code would cause any real problems, so if a module
system doesn't allow me to write it, there's something wrong with that
module system, and not with my code.
See my paper about DSF at http://www.pascalcostanza.de/dynfun.pdf that
also includes the source code.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
------------------------------
Date: 26 Jan 2004 17:14:45 -0600
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <m1hdyii9p6.fsf@tti5.uchicago.edu>
Joe Marshall <jrm@ccs.neu.edu> writes:
> Pascal Costanza <costanza@web.de> writes:
>
> > Marcin 'Qrczak' Kowalczyk wrote:
> >
> >> On Tue, 20 Jan 2004 00:18:17 +0000, David wrote:
> >>
> >>>This means that the macro definitions must executed at compile time
> >>>(obviously) hence function definitions must be executed at compile time.
> >>>I don't think there should really be such a distinction between compile
> >>>time and runtime.
> >> I think there should. Please read
> >> <http://www.cs.utah.edu/plt/publications/macromod.pdf>
> >
> > Oh dear. This is just another one of those bad examples of unbreakable
> > abstractions. Unbreakability sucks.
> >
> > Generally speaking, layering or staging of approaches is probably a
> > good idea. But there might be situations in which I need to mix up the
> > layers/stages. If a proposed solution doesn't provide a back door for
> > these things, it sucks IMHO.
>
> In this case, you don't want to mix up the layers or stages. Really.
>
> The macro/module system that Matthew is describing is one that allows
> the system to determine what to load and when to load it in order to
> ensure that you have the macro-expansion code in place *before* you
> attempt to expand the macros that use it.
>
> Mixing up the layers or stages means that you want to have circular
> dependencies in your macro expansions, i.e., macro FOO needs the
> QUASIQUOTE library to expand, but the QUASIQUOTE library is written
> using the macro FOO.
I agree with Pascal: being able to go only forward in time really sucks.
:-)
------------------------------
Date: Tue, 27 Jan 2004 01:45:58 GMT
From: Joe Marshall <prunesquallor@comcast.net>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <wu7emaek.fsf@comcast.net>
Matthias Blume <find@my.address.elsewhere> writes:
>
> I agree with Pascal: being able to go only forward in time really sucks.
For you, there's continuations.
--
~jrm
------------------------------
Date: 27 Jan 2004 10:19:21 -0600
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <m1n089xt2u.fsf@tti5.uchicago.edu>
Joe Marshall <prunesquallor@comcast.net> writes:
> Matthias Blume <find@my.address.elsewhere> writes:
>
> >
> > I agree with Pascal: being able to go only forward in time really sucks.
>
> For you, there's continuations.
I just hope you are trying to continue (no pun intended) my attempt at
being sarcastic...
------------------------------
Date: Tue, 27 Jan 2004 23:39:41 +0000
From: David <hhdave@SPAMAROONEY.blueyonder.co.uk>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <PDCRb.440$Pw5.354@news-binary.blueyonder.co.uk>
Thomas F. Burdick wrote:
> David <hhdave@SPAMAROONEY.blueyonder.co.uk> writes:
>
>
>>Thomas F. Burdick wrote:
>>
>>
>>>I'm sitting on it, pending my thinking about how much time/effort it
>>>would take to make it useful to the general public, and if there's a
>>>market for it or not. And it's a mess of unfactored hacks, because I
>>>was concentrating on the systems I was supposed to be writing, not the
>>>compiler itself.
>>
>>I know the feeling. There are lots of improvements I want to make to
>>mine as well. For one thing I want to change the way the whole thing
>>works as I've used a bit of a hack to get things like this to work:-
>>
>>(define (f x)
>> ...some function of x...)
>>
>>(defmacro my-macro (a b)
>> (list 'foo a (f b)))
>>
>>Basically, in order that the macro can use the function defined before
>>it the function must be evaluated at compile time as well as runtime.
>
>
> Since your system is self-hosting, that shouldn't be a problem. Do
> you have something like Common Lisp's eval-when? If not, you should
> read the page in the spec
>
> http://www.lispworks.com/reference/HyperSpec/Body/s_eval_w.htm#eval-when
>
> especially the Notes section at the bottom. In CL, forms like defun
> and defmacro (when they're toplevel) cause the function to be known at
> compile time by using eval-when. It also lets you write your own
> forms of this type.
>
>
>>I
>>think the root of this problem is that I want to be able to translate
>>the lisp code into a perl script which can be executed in the normal
>>way. I don't want to have to read in the lisp code and translate and
>>execute each form one by one. This means that the macro definitions must
>>executed at compile time (obviously) hence function definitions must be
>>executed at compile time. I don't think there should really be such a
>>distinction between compile time and runtime.
>
>
> Actually, I think the answer is probably having a clearer concept of
> time(s) in your Lisp dialect. When the compiler sees a toplevel form
> that macroexpands into (eval-when (compile) ...), it should
> recursively invoke itself, to deal with the eval-when, evaluate that
> in the Perl interpreter, then get back to the job at hand.
>
>
>>I have found a solution
>>though, which lies in having an intermediate lisp representation which
>>is just fully macro expanded lisp code which is generated as a side
>>effect of 'running' a lisp file. This means that you can't just compile
>>the lisp to perl as such, you have to run it, and it gets compiled
>>(partially) as a side effect. Separate modules could then be linked, and
>>fully translated to perl, later. Of course, running a file is not a
>>problem if all it does is define things (functions and macros).
>>
>>Does this seem sane?
>
>
> It seems messy. You should be able to start Perl, load all the
> functions that your macros use, compile the files defining and using
> them, then quit Perl and load the resulting .pl files. Using a
> CL-like concept of times (compile/macroexpand, load, and eval) would
> help keep things cleaner.
>
> (In my system, the macros are run in the hosting Common Lisp, so my
> issues were different. You define Perl functions with perlisp:defun,
> but they're not available at compile-time. Macros can use functions
> defined with common-lisp:defun).
>
>
Hmmm. Yes, that does seem a sensible solution. Thanks for the pointers.
I think I get the general idea of (eval-when). Its _sort of_ how I've
implemented function definitions at the moment - some things macro
expand to a special form which is evaluated at compile time as well as
runtime. I might just implement something closer to the common lisp
eval-when approach (seems a bit cleaner than what I did).
My main concern with all this was how to ensure that I can handle
dependencies between lisp files. If a file of lisp code uses macros
defined in another file then clearly the macro file must be loaded into
the compiler before the first one can be compiled. I wanted to try and
make sure that the required files would be recompiled as necessary (if
they had changed) and then loaded.
Perhaps, though, the thing to do is, as you say, just to load the
required files into the running lisp/perl interpreter by hand before
attempting to compile something which uses them. I wondered how common
lisp handles these sort of things (essentially: building of projects)
and it seems that it doesn't natively. I noticed that there are lisp
libraries for handling this sort of problem, which make it possible to
write build scripts (sort of like make files I guess).
I suppose, then, that the thing to do for a complex, multi file project
is to have a lisp program whose job it is to build the thing, which it
would do by compiling (if required) and loading the lisp source code in
the required order so that macros are defined before they are used.
Then, in my case, the ultimate product of the compilation (a perl
script) would be generated by running that compilation program (with a
repl, say).
Would that be a sensible approach, or am I missing something obvious?
I can see the point of 2 namespaces by the way (particularly when it
comes to macros). I may change to that, or do something like check the
lexical scope to implement some kind of hybrid approach. I thought there
must be a reason for it.
------------------------------
Date: Wed, 28 Jan 2004 18:54:08 +0100
From: Pascal Costanza <costanza@web.de>
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <bv8t00$3t0$1@newsreader2.netcologne.de>
Pascal Costanza wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
>
>> On Tue, 20 Jan 2004 00:18:17 +0000, David wrote:
>>
>>> This means that the macro definitions must executed at compile time
>>> (obviously) hence function definitions must be executed at compile time.
>>> I don't think there should really be such a distinction between compile
>>> time and runtime.
>>
>> I think there should. Please read
>> <http://www.cs.utah.edu/plt/publications/macromod.pdf>
>
> Oh dear. This is just another one of those bad examples of unbreakable
> abstractions. Unbreakability sucks.
I stand corrected on the approach taken in that paper. Sorry for
misrepresenting it.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
------------------------------
Date: 28 Jan 2004 12:20:18 -0800
From: tfb@famine.OCF.Berkeley.EDU (Thomas F. Burdick)
Subject: Re: Lisp2Perl - Lisp to perl compiler
Message-Id: <xcvhdyfesfx.fsf@famine.OCF.Berkeley.EDU>
David <hhdave@SPAMAROONEY.blueyonder.co.uk> writes:
> My main concern with all this was how to ensure that I can handle
> dependencies between lisp files. If a file of lisp code uses macros
> defined in another file then clearly the macro file must be loaded into
> the compiler before the first one can be compiled. I wanted to try and
> make sure that the required files would be recompiled as necessary (if
> they had changed) and then loaded.
>
> Perhaps, though, the thing to do is, as you say, just to load the
> required files into the running lisp/perl interpreter by hand before
> attempting to compile something which uses them. I wondered how common
> lisp handles these sort of things (essentially: building of projects)
> and it seems that it doesn't natively. I noticed that there are lisp
> libraries for handling this sort of problem, which make it possible to
> write build scripts (sort of like make files I guess).
Yeah, system construction is extra-standard in CL. It's generally
done with a defsystem facility (eg, ASDF http://www.cliki.net/asdf).
You make a file containing a defsystem form, which is a declarative
way of describing the dependencies in the system. If you want to
compile the system, you tell your defsystem to do so, and it figures
out what order things need to be compiled in, and when/if to load
files during compilation.
> I suppose, then, that the thing to do for a complex, multi file project
> is to have a lisp program whose job it is to build the thing, which it
> would do by compiling (if required) and loading the lisp source code in
> the required order so that macros are defined before they are used.
> Then, in my case, the ultimate product of the compilation (a perl
> script) would be generated by running that compilation program (with a
> repl, say).
>
> Would that be a sensible approach, or am I missing something obvious?
Sounds about right. Remember also, you sometimes have control the
order that the resulting files are loaded.
> I can see the point of 2 namespaces by the way (particularly when it
> comes to macros). I may change to that, or do something like check the
> lexical scope to implement some kind of hybrid approach. I thought there
> must be a reason for it.
Just like eval-when, most of the decisions made in the design of
Common Lisp are worth considering carefully; in a lot of ways, it's
the collected wisdom of an era of Lisp development. It's far from
perfect, but it is very well designed.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 6020
***************************************
