Re: LISP module from CPAN
On 9 May 2007, at 21:37, David Nicol wrote:
so if there were lisp-like macros available in perl, my sugar example
might be something like the following?
macro hashkeyaccessor(fieldname) { sub fieldname { $_[0]-
{fieldname}} };
hashkeyaccessor $_ for qw/FIELD NAMES GO HERE .../;
and I would save the trickiness of getting the interpolation level
right. That is
imagining a CPP macro... the LISP idea on macros is that the template
would be created at the optree level rather than the source level,
but its still
a template and replacement kind of deal. What am I missing?
You're missing that you can execute code at compile time that
determines what code you generate.
I'd recommend http://www.gigamonkeys.com/book/ as a reasonable into
to Lisp for those who want to play. Macro chapter is http://
www.gigamonkeys.com/book/macros-defining-your-own.html.
Some devils brew of source filters and eval is the closest you'll get
in Perl 5 Perl 6 with its explicit lexer/parser should give you
the full power of Lisp style macros.
Adrian (recovering Smug Lisp Weenie :-)
Re: LISP module from CPAN
--- David Nicol [EMAIL PROTECTED] wrote: Ever since reading Hackers and Painters http://www.amazon.com/exec/obidos/ISBN=0596006624/tipjartransactioA I've been defending Perl is a LISP! (which is actually quite easy, because nobody knows what I'm talking about) And for those who have not read the brilliant rebuttal to the Hackers and Painters article: http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
towards TERN::macro (was Re: LISP module from CPAN)
On 5/10/07, Adrian Howard [EMAIL PROTECTED] wrote:
On 9 May 2007, at 21:37, David Nicol wrote:
[proposed macro syntax example:]
macro hashkeyaccessor(fieldname) { sub fieldname { $_[0]-
{fieldname}} };
hashkeyaccessor $_ for qw/FIELD NAMES GO HERE .../;
[summary of benefits of approach] What am I missing?
You're missing that you can execute code at compile time that
determines what code you generate.
I disagree, I think I included that, and you didn't see that I had.
so to be fully lispy the extension would need to support
defmacro keylookup(key) { $_[0]-{key}}
defmacro hashkeyaccessor(fieldname) { sub fieldname {
(keylookup fieldname) } };
(hashkeyaccessor $_) for qw/FIELD NAMES GO HERE .../;
as well as
www.gigamonkeys.com/book/macros-defining-your-own.html
Some devils brew of source filters and eval is the closest you'll get
in Perl 5 Perl 6 with its explicit lexer/parser should give you
the full power of Lisp style macros.
the debate response to that is, show me something besides
syntax succinctness you can do with a LISP macro that you cannot
do with such a code-generated string eval
Adrian (recovering Smug Lisp Weenie :-)
That's fun link, the story of Mac the programmer, who eventually retires. The
article contains this:
* When you write macros, you're writing programs that will be
* used by the compiler to generate the code that will then be
* compiled. Only after all the macros have been fully expanded
* and the resulting code compiled can the program actually be run.
* The time when macros run is called macro expansion time; this
* is distinct from runtime, when regular code, including the code
* generated by macros, runs.
this separation of times sounds exactly the same as putting
an eval of generated source in a BEGIN block. Adding a source
filter to the brew has to potential to allow for succinctness and
clarity that is absent from the generated source situation due
to the trickiness of escaping sygills appropriately (easy to get
wrong, but you only have to get it once right, then it stays
working)
Later in the chapter, gigamonkeys admits that LISP macros also
suffer from the fact the human brain was not originially designed for
programming computers:
* In other words, you'll write a macro-writing macro: a
* macro that generates code that generates code. While
* complex macro-writing macros can be a bit confusing
* until you get used to keeping the various levels of code
* clear in your mind
LISP feature: macros that produce macros.
Perl equivalent: evalling generated source to produce functions to
eval generated source.
Can do it, yes. And it is a slightly bigger PITA than using LISP syntax.
If I find the time to put what I learned about source filters while
exploring writing a tail recursion optimizer (final result: there
are too many edge cases: if you really want tail recursion
optimization, learn about Cgoto subname and use it) into
making my own macro syntax filter which will work as
exampled above, it will work as follows:
(1) remove pods and comments and abstract out quoting constructs;
(2) identify defmacro constructions, whatever they look like, convert
them to coderefs that take parameters and return the body as
evallable strings;
(3) identify expressions including defined macros, and run those
expressions immediately
(4) expand macros, even embedded in expressions, in results from (3)
(5) allow for macros declared in macro expansions to join the list
of declared macros from that point on
(6) allow for lexical scoping of macros
(7) allow for predeclaration of macros (? is this useful)
(8,...) extend macro language
What's already on CPAN:
http://search.cpan.org/~segv/Macro-0.2/Macro.pod
Essentially what I'm describing, but with a clunky Parse::RecDescent
syntax that may be more complex than doing it yourself; and with
a bugs/todo list at the bottom that restates various points made
above -- I will start with Macro-02 instead of from scratch if I do this
http://search.cpan.org/~autrijus/Filter-Macro-0.11/lib/Filter/Macro.pm
misleadingly named, Filter::Macro appears to be Pollute::Persistent
plus hints accomplished through source filtering.
TERN (The Extensible Rewriting Notation) mailing list,
http://lists.nongnu.org/mailman/listinfo/TERN-discuss
The Take away David Nicol's internet access committee
mailing list, (...)
--
practical solutions to systemic problems
Re: LISP module from CPAN
On Tuesday 08 May 2007 01:40:09 pm David Nicol wrote:
On 5/8/07, Vadim [EMAIL PROTECTED] wrote:
no, it uses CFFI, so this should cover every implementation supporting
that.
Ever since reading Hackers and Painters
http://www.amazon.com/exec/obidos/ISBN=0596006624/tipjartransactioA
I've been defending Perl is a LISP! (which is actually quite easy,
because nobody knows what I'm talking about)
Are there a lot of libraries and things written to CFFI? Perl could
provide a CFFI interface, that would strengthen the perl is a lisp meme.
I think the LISP folks would like to use CPAN, not the other way around.
As for Perl being a LISP... Perl is missing macros (unless you count opgrep
and B::Generate) and continuations. Lisp is also dynamically typed
(originally), which you can admittedly emulate in Perl, i.e.
(let ((mk-adder (lambda (x) (lambda (y) (+ x y ... )
is
our $x;
sub mk_adder { return sub { my $y = shift; $x + $y } }
...
but much cleaner (in Perl-land) as:
sub mk_adder { my $x = shift; return sub { my $y = shift; $x + $y } }
Incidentally, emacs lisp is dynamically typed, but scheme isn't. Confused? I
am. :)
... wow, this is offtopic now.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgplQRObWB40O.pgp
Description: PGP signature
Re: LISP module from CPAN
Jonathan Rockway wrote:
On Tuesday 08 May 2007 01:40:09 pm David Nicol wrote:
On 5/8/07, Vadim [EMAIL PROTECTED] wrote:
no, it uses CFFI, so this should cover every implementation supporting
that.
Ever since reading Hackers and Painters
http://www.amazon.com/exec/obidos/ISBN=0596006624/tipjartransactioA
I've been defending Perl is a LISP! (which is actually quite easy,
because nobody knows what I'm talking about)
Are there a lot of libraries and things written to CFFI? Perl could
provide a CFFI interface, that would strengthen the perl is a lisp meme.
I think the LISP folks would like to use CPAN, not the other way around.
This is two-fold situation.
The opposite of what you said is true - the purpose of my module is to
gain access to numerous LISP packages (maxima, etc) from Perl.
I don't like socket approach, I like inter-language operations.
But what you said is also true.
I will be using the module to bring the power to my LISP programs also,
something like
(perl5re string ([\d.]+))
to extract all the numbers from string.
Yet I like the combination of Perl+Lisp+Tcl/Tk thus providing rich GUI,
rich mathematical packages, rich CPAN.
As for Perl being a LISP... Perl is missing macros (unless you count opgrep
I consider eval $string as a replacement of macros.
and B::Generate) and continuations. Lisp is also dynamically typed
(originally), which you can admittedly emulate in Perl, i.e.
(let ((mk-adder (lambda (x) (lambda (y) (+ x y ... )
is
our $x;
sub mk_adder { return sub { my $y = shift; $x + $y } }
...
but much cleaner (in Perl-land) as:
sub mk_adder { my $x = shift; return sub { my $y = shift; $x + $y } }
Incidentally, emacs lisp is dynamically typed, but scheme isn't. Confused? I
am. :)
... wow, this is offtopic now.
It's everywhere offtopic :) because this is all new unfortunately (it
was surprise to me to find only toy LISP implementations on CPAN, and no
real Lisp connectors).
I wonder whether there will be enough followers, so for it to create
Perl+Lisp mailing list...
Thank you for your ideas, BTW.
Best regards,
Vadim.
Re: LISP module from CPAN
On 5/9/07, Vadim [EMAIL PROTECTED] wrote:
I consider eval $string as a replacement of macros.
for instance, I did the following in a curl wrapper package, to make
the curlies optional around the fieldnames:
BEGIN { for (qw/
BUFFER CALLBACK DATA EVENT FAILURE FETCHTIMEOUT
GET MAXAGE MAXSTALE MESSAGE NOCACHE POST
READY STARTED UH URL USER/){
eval FIELD;
sub $_ : lvalue {
\$_[0]-{$_}
}
FIELD
}}
What would that look like in LISP?
Re: LISP module from CPAN
David Nicol wrote:
On 5/9/07, Vadim [EMAIL PROTECTED] wrote:
I consider eval $string as a replacement of macros.
for instance, I did the following in a curl wrapper package, to make
the curlies optional around the fieldnames:
BEGIN { for (qw/
BUFFER CALLBACK DATA EVENT FAILURE FETCHTIMEOUT
GET MAXAGE MAXSTALE MESSAGE NOCACHE POST
READY STARTED UH URL USER/){
eval FIELD;
sub $_ : lvalue {
\$_[0]-{$_}
}
FIELD
}}
What would that look like in LISP?
I'm LISP novice (although met it some 15 years ago, now I'm more serious
with our relationship at our second attempt :) :)
so I can be easily wrong
but my vision of your BEGIN block is:
(eval-when :when-compile
(dolist (fname '(BUFFER CALLBACK ETCETERA))
(eval (read-from-string (format nil (defun ~A ()
(do-something-useful)) fname)
Why didn't you placed functions in AUTOLOAD, and creating them only when
needed?
My Tcl::Tk module do heavy usage of AUTOLOADing, you may want to look at
the approach :)
Initially I did eval $string but then come to safer approach.
PS. now this *is* off-topic, sorry for that.
I'll try to be more on-topic from now on :)
Re: LISP module from CPAN
* Vadim [EMAIL PROTECTED] [2007-05-09 12:05]:
Jonathan Rockway wrote:
As for Perl being a LISP... Perl is missing macros (unless you
count opgrep
I consider eval $string as a replacement of macros.
Not even close. `eval EXPR` burdens you with generating
syntactically correct code and moves everything from compile time
to runtime.
It’s like the difference between doing
*foo = sub { $bar };
and
my $_bar = quotemeta $bar;
eval sub foo { \$_bar\ };
`eval EXPR` is useful, but a poor substitute for solid
metaprogramming facilities.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: LISP module from CPAN
# from Vadim # on Wednesday 09 May 2007 10:53 am: Why didn't you placed functions in AUTOLOAD, and creating them only when needed? Because then you must override can() or your code is broken. It is usually a lot simpler (and gives better diagnostics) to just generate and install everything in advance. Particularly if you're only doing it to save typing. If you *actually* want to delay the decision of whether $foo-can(bar) until run-time, then yes autoload is the way to go. --Eric -- Time flies like an arrow, but fruit flies like a banana. --Groucho Marx --- http://scratchcomputing.com ---
Re: LISP module from CPAN
so if there were lisp-like macros available in perl, my sugar example
might be something like the following?
macro hashkeyaccessor(fieldname) { sub fieldname { $_[0]-{fieldname}} };
hashkeyaccessor $_ for qw/FIELD NAMES GO HERE .../;
and I would save the trickiness of getting the interpolation level
right. That is
imagining a CPP macro... the LISP idea on macros is that the template
would be created at the optree level rather than the source level, but its still
a template and replacement kind of deal. What am I missing?
Re: LISP module from CPAN
* David Nicol [EMAIL PROTECTED] [2007-05-09 22:40]:
so if there were lisp-like macros available in perl, my sugar
example might be something like the following?
macro hashkeyaccessor(fieldname) { sub fieldname { $_[0]-{fieldname}} };
hashkeyaccessor $_ for qw/FIELD NAMES GO HERE .../;
and I would save the trickiness of getting the interpolation
level right. That is imagining a CPP macro... the LISP idea on
macros is that the template would be created at the optree
level rather than the source level, but its still a template
and replacement kind of deal. What am I missing?
Nothing. You got it.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: LISP module from CPAN
On Mon, May 07, 2007 at 08:39:28PM +0400, Vadim wrote: Adam Kennedy wrote: One alternative for the bridging stuff would be to look at using something like Language::LISP. ... That tends to be a more common area for bridges to languages. Although there are different approaches within Language:: namespace (bridge connections like Language::Haskell, etc, and also toy implementations like Language::Basic) it is indeed common area for bridges to languages. So, I'll stick with Language::Lisp name. If your module only connects to one LISP implementation, I'd urge you to make sure you put that name in the namespace, eg Language::Lisp::CMUCL. -- Benjamin Smith [EMAIL PROTECTED]
Re: LISP module from CPAN
Benjamin Smith wrote: On Mon, May 07, 2007 at 08:39:28PM +0400, Vadim wrote: Adam Kennedy wrote: One alternative for the bridging stuff would be to look at using something like Language::LISP. ... That tends to be a more common area for bridges to languages. Although there are different approaches within Language:: namespace (bridge connections like Language::Haskell, etc, and also toy implementations like Language::Basic) it is indeed common area for bridges to languages. So, I'll stick with Language::Lisp name. If your module only connects to one LISP implementation, I'd urge you to make sure you put that name in the namespace, eg Language::Lisp::CMUCL. no, it uses CFFI, so this should cover every implementation supporting that. I'm developing using CLISP, but not relying on its internals. Indeed, implementation-dependant things should be in their own packages. Vadim.
Re: LISP module from CPAN
On 5/8/07, Vadim [EMAIL PROTECTED] wrote: no, it uses CFFI, so this should cover every implementation supporting that. Ever since reading Hackers and Painters http://www.amazon.com/exec/obidos/ISBN=0596006624/tipjartransactioA I've been defending Perl is a LISP! (which is actually quite easy, because nobody knows what I'm talking about) Are there a lot of libraries and things written to CFFI? Perl could provide a CFFI interface, that would strengthen the perl is a lisp meme.
Re: LISP module from CPAN
David Nicol wrote: On 5/8/07, Vadim [EMAIL PROTECTED] wrote: no, it uses CFFI, so this should cover every implementation supporting that. Ever since reading Hackers and Painters http://www.amazon.com/exec/obidos/ISBN=0596006624/tipjartransactioA I've been defending Perl is a LISP! (which is actually quite easy, because nobody knows what I'm talking about) Are there a lot of libraries and things written to CFFI? Perl could provide a CFFI interface, that would strengthen the perl is a lisp meme. I'm not CFFI expert, so can't really comment. Looking at CFFI homepage at http://common-lisp.net/project/cffi/ this gives me an idea this is a LISP-only beastie... But, given SWIG provides support of CFFI, may be its already not so far distant from Perl... (answering to your other question) No, Inline:: approach is very different.. PS. I'll upload very first very unperfect version of Language::Lisp module to CPAN later today. Vadim.
Re: LISP module from CPAN
Hi, all, PS. I'll upload very first very unperfect version of Language::Lisp module to CPAN later today. finally I did it. the module is very small but it allows to tie together these three things: Perl, Lisp and, for example, Tcl/Tk, thus allowing to use tight integration of LISP-based CAS system (Maxima, axiom, etc) and use GUI w/o sockets, directly from Perl. Best regards, Vadim.
Re: LISP module from CPAN
Vadim wrote: Dear Douglas, given that your CPAN module did not got proper evolving, would you mind giving up on it and removing from CPAN? I would like to publish a bridge module that connects Perl to different Lisp implementations (CLISP, SBCL, CMUCL, GCL as a start), very much like currently my Tcl CPAN module do. All in all, I'll upload to CPAN anyway, and I would like to avoid collisions. Best regards, Vadim. One alternative for the bridging stuff would be to look at using something like Language::LISP. That tends to be a more common area for bridges to languages. Adam K
Re: LISP module from CPAN
Adam Kennedy wrote: One alternative for the bridging stuff would be to look at using something like Language::LISP. ... That tends to be a more common area for bridges to languages. Although there are different approaches within Language:: namespace (bridge connections like Language::Haskell, etc, and also toy implementations like Language::Basic) it is indeed common area for bridges to languages. So, I'll stick with Language::Lisp name. Thank you a lot. Vadim.
LISP module from CPAN
Dear Douglas, given that your CPAN module did not got proper evolving, would you mind giving up on it and removing from CPAN? I would like to publish a bridge module that connects Perl to different Lisp implementations (CLISP, SBCL, CMUCL, GCL as a start), very much like currently my Tcl CPAN module do. All in all, I'll upload to CPAN anyway, and I would like to avoid collisions. Best regards, Vadim.
