I have to develop a PHP web application to be used by a client of mine.
Since i learned Lisp it's really difficult to find motivation to use any
other programming language. This is a somewhat big project so using Lisp
might bring some nice benefits. The problem here is that the source code
must be readable PHP code to be maintained by someone else other than
me. Using Lisp all the way down is out of the question.
How to deal with this problem? I thought of two ways:
- Develop Lisp to PHP source code translator - difficult and time
consuming but more powerful. Will allow to develop almost 100% in Lisp.
- Wrap common PHP source snippets(security/user handling, logging,
database...) in Lisp functions/macros and let them return the
corresponding PHP + HTML code - easy but less powerful.
Any other solutions? I might end up using the second way since i still
have limited Lisp experience. Interested in hearing your opinions and
from people who have been through similar situations.
eMics <·····@emics.com> writes:
> The problem here is that the source code must be readable PHP code
> to be maintained by someone else other than me.
If the project requirement is that you must do it in PHP,
then I would suggest that you use PHP and *not* Lisp.
If you want to change something about the project,
you might want to discuss with them why they insist on PHP.
eMics wrote:
> I have to develop a PHP web application to be used by a client of
mine.
> Since i learned Lisp it's really difficult to find motivation to use
any
> other programming language. This is a somewhat big project so using
Lisp
> might bring some nice benefits. The problem here is that the source
code
> must be readable PHP code to be maintained by someone else other than
> me. Using Lisp all the way down is out of the question.
>
> How to deal with this problem? I thought of two ways:
> - Develop Lisp to PHP source code translator - difficult and time
> consuming but more powerful. Will allow to develop almost 100% in
Lisp.
Doing a whole Lisp to PHP translator will be a lot of work and probably
won't produce human readable code. But you can check out
ParenScript[1] for inspiration. It is a JavaScript disguised as Lisp
and you can have even reader and compiler macros.
I don't know if it'll work in your case though, because JavaScript has
a lot of the features of Lisp (e.g. first-class lexical closures),
while I don't know if PHP is close enough. Also I'm using ParenScript
in a toy project, and cannot comment of how well it'll scale.
> - Wrap common PHP source snippets(security/user handling, logging,
> database...) in Lisp functions/macros and let them return the
> corresponding PHP + HTML code - easy but less powerful.
>
> Any other solutions? I might end up using the second way since i
still
> have limited Lisp experience. Interested in hearing your opinions and
> from people who have been through similar situations.
I remember there was Scheme in PHP implementation or something like
that. Just google for it, if it makes sense for you.
[1] http://bknr.net/parenscript
On Tue, 05 Apr 2005 08:21:21 -0700, ivant wrote:
> eMics wrote:
>> I have to develop a PHP web application to be used by a client of
> mine.
>> Since i learned Lisp it's really difficult to find motivation to use
> any
>> other programming language. This is a somewhat big project so using
> Lisp
>> might bring some nice benefits. The problem here is that the source
> code
>> must be readable PHP code to be maintained by someone else other than
>
>> me. Using Lisp all the way down is out of the question.
>>
>> How to deal with this problem? I thought of two ways:
>> - Develop Lisp to PHP source code translator - difficult and time
>> consuming but more powerful. Will allow to develop almost 100% in
> Lisp.
>
> Doing a whole Lisp to PHP translator will be a lot of work and probably
> won't produce human readable code. But you can check out
> ParenScript[1] for inspiration. It is a JavaScript disguised as Lisp
> and you can have even reader and compiler macros.
>
> I don't know if it'll work in your case though, because JavaScript has
> a lot of the features of Lisp (e.g. first-class lexical closures),
> while I don't know if PHP is close enough. Also I'm using ParenScript
> in a toy project, and cannot comment of how well it'll scale.
>
>> - Wrap common PHP source snippets(security/user handling, logging,
>> database...) in Lisp functions/macros and let them return the
>> corresponding PHP + HTML code - easy but less powerful.
>>
>> Any other solutions? I might end up using the second way since i
> still
>> have limited Lisp experience. Interested in hearing your opinions and
>> from people who have been through similar situations.
One big advice: try _not_ to convince your environment about a language
you don't really master to a certain degree. You won't do yourself a
favor (nor your language of choice).
> I remember there was Scheme in PHP implementation or something like
> that. Just google for it, if it makes sense for you.
Hmm, don't you mix this up with "PHP compiler written in Scheme"?
AFAIK they used Bigloo to implement a PHP compiler.
Just my 0.02$
Ralf Mattes
>
> [1] http://bknr.net/parenscript
R. Mattes wrote:
> On Tue, 05 Apr 2005 08:21:21 -0700, ivant wrote:
> > I remember there was Scheme in PHP implementation or something like
> > that. Just google for it, if it makes sense for you.
>
> Hmm, don't you mix this up with "PHP compiler written in Scheme"?
> AFAIK they used Bigloo to implement a PHP compiler.
>
No, I meant PHPScheme
http://www.geocities.com/markoriedelde/scheme/index.html
On Wed, 06 Apr 2005 01:20:23 -0700, ivant wrote:
> http://www.geocities.com/markoriedelde/scheme/index.html
Eeeek!
Thanks for that link, that's ia Scheme i never have seen before ....
Cheers RalfD
On 2005-04-05 08:56:19, eMics wrote:
> The problem here is that the source code
> must be readable PHP code to be maintained by someone else other than
> me.
Then, how do you want to use Lisp as a PHP generator? Every change
in the PHP code must be recoded into the Lisp code. The work is done
twice.
On Tue, 5 Apr 2005 10:37:10 +0200, Stefan Scholl <······@no-spoon.de>
wrote:
>On 2005-04-05 08:56:19, eMics wrote:
>
>> The problem here is that the source code
>> must be readable PHP code to be maintained by someone else other than
>> me.
>
>Then, how do you want to use Lisp as a PHP generator? Every change
>in the PHP code must be recoded into the Lisp code. The work is done
>twice.
That's a recipe for a nightmare. Maybe the OP should check out this:
www.templatetamer.com
eMics wrote:
> How to deal with this problem? I thought of two ways:
> - Develop Lisp to PHP source code translator - difficult and time
> consuming but more powerful. Will allow to develop almost 100% in Lisp.
> - Wrap common PHP source snippets(security/user handling, logging,
> database...) in Lisp functions/macros and let them return the
> corresponding PHP + HTML code - easy but less powerful.
>
Write the program in PHP (like Christopher said, the requirement is
that it is in PHP). But... this app will need to be tested, so
write some automated testing in Lisp. If you want to do more, I
suggest you write the app twice, once in PHP and and in Lisp. It
would be a really good learning experience.
Wade
eMics wrote:
> I have to develop a PHP web application to be used by a client of mine.
> Since i learned Lisp it's really difficult to find motivation to use any
> other programming language. This is a somewhat big project so using Lisp
> might bring some nice benefits.
Do what one cll denizen does: quote them two prices, one for PHP, one
for Lisp. Yes, you may end up losing money because of the learning
curve, but not on the project per se if you allocate all curve-related
time to your training budget. :)
> The problem here is that the source code
> must be readable PHP code to be maintained by someone else other than
> me.
Throw in three copies (five, Peter?) of Practical Common Lisp (PCL) as a
deliverable. Oh, and wine and dine them at a local Lispnik get-together.
> Using Lisp all the way down is out of the question.
Think you can or think you can't, either way you'll be right. (New
England proverb).
ie, Your own attitude is the problem, not the client's. If you were more
convinced of Lisp's superiority, you would be jawboning the client
instead of preparing to waste hundreds of hours on Lip-PHP hybrids which
will be a joke in six months when PCL blows by the last Harry Potter book.
:)
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
eMics wrote:
> I have to develop a PHP web application to be used by a client of mine.
[...]
> The problem here is that the source code
> must be readable PHP code to be maintained by someone else other than
> me. Using Lisp all the way down is out of the question.
Add another tier. PHP is mainly for front ends (and does an "ok" job at
it) , so you do the hard work in Lisp and export a REST or XML-RPC API
which is used by the php front end. You get the lucrative maintainance
contract on the back-end too :).
Besides that, you have three choices :
1) Code in PHP. horrible thought i admit, but if you need the money it's
not much worse than selling your blood.
2) Educate the client. I've done as Kenny Tilton suggests and quote
(vastly) different prices for the projects. Also, i've written two
different proposals.
In the PHP/ASP/Whatever version, I lay out the shortcomings of the
langauge and how the development process will be stuctured to work
around them. Assuming you still want the contract, this still has to be
a good proposal, but it's not hard to do this right...
In the Lisp one i blather on about the virtues of Lisp from the clients
point of view. This is a something from a recent proposal (re-write of
an asp/mssql app and yes, we got the contract) :
--------
Where the previous application was written in a proprietary �Language Of
The Month�, and left as a binary compiled for a single system, /The
System/ will be designed primarily with longevity and ease of
maintanance/updates in mind. The Lisp langauge has been in popular use
for almost 50 years, and Common Lisp in particular is an ANSI standard....
....rather than use a language that is owned by a corporation and
subject to the whims of the marketing and support departments, it is
better to maintain an open platform which has a standard and 50 years of
momentum behind it....
...Just as an aside, the "first web application" was written in Common
Lisp. The author, Paul Graham, has an excellent write-up of the
advantages using this partcular language brought to the table.(See
�Beating The Averages� http://paulgraham.com/avg.html).
---------
I also offer a 10 year maintanance contract under "wonderful" terms for
the lisp code, vs. 1 year with the "Language of the Month". I'm
confident that my code, delivered using SBCL 0.8.21, will run with
minimal changes in 10 years (on SBCL 0.9.1873054 :) ). I'm not so
confident about PHP, having gone through the php3->php4 transition.
The main advantage that i stress is that i'll be able to deliver better
code. My clients are not programmers, and shouldn't care which language
i use... what they should care about is how easy it is to
create/change/grow/fix their system. Which brings me to the last option...
3) Fire the client. You want to work in Lisp, they want PHP ... does one
go work at McDonalds when aiming to be a chef?! You'll have much more
time to search for lisp work and learn more lisp if you are not busy
writing php :)
All that being said, early on in my lisping i wrote some code to
generate php. It was fun, and i learned a lot about macros, but i could
never deliver the generated code to a php developer and expect them to
understand it.
drewc
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
You have to do some work in a language other than Lisp, but you want to use
Lisp.
Check http://perso.wanadoo.fr/turle/lisp/utilities.html#file-updater for a
first step. It will allow you to insert code generated from your lisp
functions directly into your target code, as if you had hand-written it.
A second step is to define your shp (PHP s-exp based language) since it's
easier to manipulate s-exp than strings. (see
http://perso.wanadoo.fr/turle/lisp/sava.html for hints/ideas)
A third step is to build your app s-exp language in top of your new s-exp
based language. With all the power of lisp to create/generate your own
frameworks without restrictions.
As stated by others, you can also build all your test codes directly in
Lisp. Just define a way to communicate between your lisp code and your app.
In your case (php app), i may be a good idea that your lisp code sends http
requests and parse responses using html<->lisp library.
--
___________________________________________________________
Christophe Turle.
sava preview http://perso.wanadoo.fr/turle/lisp/sava.html
(format nil ···@~a.~a" 'c.turle 'wanadoo 'fr)
eMics <·····@emics.com> schrieb:
> I have to develop a PHP web application to be used by a client of
> mine. Since i learned Lisp it's really difficult to find motivation
> to use any other programming language.
As languages go PHP is still a lot closer to Lisp than, say, Java. It
has anonymous functions, higher-order functions, and faking closures
with globals, static variables, and/or objects is painful but not
agonizing. No macros, but how sophisticated a system does anyone expect
to build with PHP anyways?
Try this library for functional idiom support:
http://sourceforge.net/projects/functional-php/
Off topic: It blows my mind that PHP, designed *explicitly* for web
programming, is both more popular and demonstratably inferior to just
about every general-purpose language which has moved into the domain:
Lisp, Ruby, Python, Smalltalk, ...
Adrian Kubala wrote:
>
> Off topic: It blows my mind that PHP, designed *explicitly* for web
> programming, is both more popular and demonstratably inferior to just
> about every general-purpose language which has moved into the domain:
> Lisp, Ruby, Python, Smalltalk, ...
Why? Most programmers are bad at programming. PHP is good for the
bad programmers and it is good because it is a krappy little language.
It is simple and easy to learn, there are lots of
libraries/classes/whatever avalable for it and some even work. And if
it does not work then he can blame the crappy free/cheep tools, merited
or not, and continue billing away while waiting on a patch etc. And
there are lots of php jobs out there.
marc
From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: Re: Getting Lisp to do PHP
Date:
Message-ID: <d30dni$v6v$1@ulric.tng.de>
Adrian Kubala schrieb:
> Off topic: It blows my mind that PHP, designed *explicitly* for web
> programming, is both more popular and demonstratably inferior to just
> about every general-purpose language which has moved into the domain:
> Lisp, Ruby, Python, Smalltalk, ...
Why is that? I mean, why is it so inferior?
Andr�
--
Andr� Thieme <······························@justmail.de> schrieb:
>> Off topic: It blows my mind that PHP, designed *explicitly* for web
>> programming, is both more popular and demonstratably inferior to just
>> about every general-purpose language which has moved into the domain:
>> Lisp, Ruby, Python, Smalltalk, ...
>
> Why is that? I mean, why is it so inferior?
Let me add to what the other poster mentioned:
- The garbage collector (at least v4 which I use) can't collect circular
references.
- As of v4, there is no way to call-by-reference-value -- instead there
is a very wacky call-by-name -- and this makes data sharing painful.
v5 tries to fix this by switching completely to Java semantics. (Like
that won't break any code.)
- v4 doesn't have exceptions. v5 does though, thank goodness.
- I've heard it's one of the slowest scripting language used for webapps
(slower than Python, Perl, etc), though honestly this has never made a
noticable difference to me -- I have more problems with its atrocious
memory usage.
- As of v4 at least, there is no way to recover from a fatal error to
present the user a nice error screen (which I consider a requirement
for any serious webapp).
- This is just the blatant stuff, any of the languages I listed have
their own unique advantages which PHP will probably never overcome...
meanwhile the latest version of PHP adds support for "private"
methods. Yay!
The best way to explain it is that PHP has *no* special language
features except its "embedded code in HTML" which could have been added
to any language by a 5-line preprocessor... so I don't get why the PHP
devs had to invent their own crappy language from scratch when obviously
better languages already existed. NIH probably.
On 2005-04-06, Andr� Thieme <······························@justmail.de> wrote:
> Adrian Kubala schrieb:
>
>> Off topic: It blows my mind that PHP, designed *explicitly* for web
>> programming, is both more popular and demonstratably inferior to just
>> about every general-purpose language which has moved into the domain:
>> Lisp, Ruby, Python, Smalltalk, ...
>
> Why is that? I mean, why is it so inferior?
The main feature of PHP is that (almost) any HTML document is in fact a PHP
script that reproduce itself, and script pieces can be inserted by special
tags, to let the script run at that point. Initiallt this seems like a
nice feature, but very often PHP ends up in an incomprihensible, umaintainable
tag soup. You don't need to program PHP this way though , you can easily
write the HTML one place, and the functional code a different place. Then
you get a kind of perl-like dynamicly typed language. The problem is that
you are likely to come over other peoples code written in this manner.
Earlier it lacked most important controll structures, like the ability to
define your own types, but in the later versions it have added classes,
so at least in theory you can write in a more structured way, but this
require disipline.
PHP lends very heay on the CGI paradigm of web programming, that a URL invokes a
script that generates a web page. This is just the traditional way of doing
web programming, and I won't blaim PHP for that, just say that there are other
ways of doing web programming that makes it easier to make a good program
design. Another thing is that PHP language and libraries often has changed
significantly, so programs written in an old version of the language not
can be moved to the new vesion without a porting effort.
The last thing to mention is that PHP in the past have had a huge number of
security holes. While this is unrelated to the PHP as a programming
language, it have made the sysadmins here very skeptical to PHP, and
resists whenever someone wants a PHP-based web application installed.
This combines nicely with the incompatibilites between versions. The
sysadmin want to upgrade to the latest version to plug security holes,
while the web developer screems, because his program is incompatible
with the new version.
There is of cause good points with PHP as well, the main thing being that it
has quite a lot of libraries useful for web programming, and that a lot
of people know it. The last point to make is that you should not look at
what is wrong with PHP, but rather look at the nice features of the other
programming languages. They may have fewer libraries for web programming than
PHP, and may therefore require a bigger effort in the start, but it will
pay off in terms of easier maintainable applications.
--
Gisle S�lensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no | Complicated is easy, simple is hard.
Andr� Thieme <······························@justmail.de> writes:
> Adrian Kubala schrieb:
>
>> Off topic: It blows my mind that PHP, designed *explicitly* for web
>> programming, is both more popular and demonstratably inferior to just
>> about every general-purpose language which has moved into the domain:
>> Lisp, Ruby, Python, Smalltalk, ...
>
> Why is that? I mean, why is it so inferior?
It's hard to fully enumerate, but I found using it like
trying to cross a minefield. Most egregious seemed to be
the lack of any decent support for error handling. That,
and the fact that at every turn, the design seems to have
been to make the life of the language implementors easier,
rather than that of its users.
Of course, it seems to be by no means the only web scripting
language faulty in those respects; as a whole, the whole field
seems to have been invented by script kiddies who couln't be
bothered to learn something about prior art in language design.
It's just _unbelievably_ kludgy.
I think a good rule of thumb is: if a language doesn't have
an UNWIND-PROTECT or equivalent, it's probably a lost cause.
Alain Picard <············@memetrics.com> writes:
> I think a good rule of thumb is: if a language doesn't have
> an UNWIND-PROTECT or equivalent, it's probably a lost cause.
Which leaves how many languages ?
Jacek Generowicz <················@cern.ch> writes:
> Alain Picard <············@memetrics.com> writes:
>
>> I think a good rule of thumb is: if a language doesn't have
>> an UNWIND-PROTECT or equivalent, it's probably a lost cause.
>
> Which leaves how many languages ?
Ada, C++, Java, Perl (if you stretch it), Scheme (please, no continuation
flame war) and several others, I suspect. What I really meant, of
course, is some systematic and controlled way to trigger and take action
upon stack unwinding.
And I've been thinking about exceptions to my bold statement; I
think Forth is probably NOT a lost cause, even though it doesn't
provide an UNWIND-PROTECT. There may be others as well.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard wrote:
> Jacek Generowicz <················@cern.ch> writes:
>
>
>>Alain Picard <············@memetrics.com> writes:
>>
>>
>>>I think a good rule of thumb is: if a language doesn't have
>>>an UNWIND-PROTECT or equivalent, it's probably a lost cause.
>>
>>Which leaves how many languages ?
>
>
> Ada, C++, Java, Perl (if you stretch it), Scheme (please, no continuation
> flame war) and several others, I suspect. What I really meant, of
> course, is some systematic and controlled way to trigger and take action
> upon stack unwinding.
>
> And I've been thinking about exceptions to my bold statement; I
> think Forth is probably NOT a lost cause, even though it doesn't
> provide an UNWIND-PROTECT. There may be others as well.
>
Forth has exceptions (throw, catch), so you can do anything that
Java can do, too.
Alain Picard <············@memetrics.com> writes:
> Jacek Generowicz <················@cern.ch> writes:
>
> > Alain Picard <············@memetrics.com> writes:
> >
> >> I think a good rule of thumb is: if a language doesn't have
> >> an UNWIND-PROTECT or equivalent, it's probably a lost cause.
> >
> > Which leaves how many languages ?
>
> Ada, C++, Java, Perl (if you stretch it), Scheme (please, no continuation
> flame war) and several others, I suspect. What I really meant, of
> course, is some systematic and controlled way to trigger and take action
> upon stack unwinding.
>
> And I've been thinking about exceptions to my bold statement; I
> think Forth is probably NOT a lost cause, even though it doesn't
> provide an UNWIND-PROTECT. There may be others as well.
The presence of unwind-protect in some expressional form has long been
my simplest criterion for detecting a rational language.
I don't really count things like C++ that implement it accidentally as
a side-effect of some other situation (e.g., destructors for
stack-allocated objects). One of the many axes along which I measure
languages is expressional vs implementational. Expressional meaning
there's a conceptual isomorphism between things you want to do and the
intended uses of notations in the language; implementational meaning
they don't add syntax to the language when they figure you can just as
well bumble through existing syntax or functionality to get to the
effect you want. C is very implementational, and C++ relatively so.
Lisp is very expressional.
On your list of languages, please include ITS TECO, which runs the value
of qregister ..N upon unwinds. ITS TECO was the original implementation
language for Emacs, before Stallman wrote a Lisp for it.
I'm pretty sure Multics PL/1 had an unwind-protect-like facility, too,
even though I don't think standard PL/1 did. (For those who don't know,
Multics was an operating system that ran on a Honeywell processor in the
1970's when I was in college. It was a 72-bit processor with segmented
memory, extremely sophisticated security, etc. It was well ahead of its
time.) The Multics Pl/1 condition system is the conceptual parent of the
Lisp Machine condition system which is the conceptual parent of the Common
Lisp condition system.
Kent M Pitman <······@nhplace.com> writes:
> On your list of languages, please include ITS TECO, which runs the value
> of qregister ..N upon unwinds. ITS TECO was the original implementation
> language for Emacs, before Stallman wrote a Lisp for it.
By all means. My list was by no means meant to be complete
or authoritative: to wit, another poster already demonstrated
that I'm out of touch with respect to Forth. (Well, it has
been 20 years... :-)
Point taken about how klugy it is in different languages, btw.
The Multics runtime implemented an extended PL/I condition mechanism.
One feature was similar to unwind-protect: when a stack frame was being
abandoned due to a signal, the condition "cleanup" was raised in each
frame, giving the program owning the frame a chance to deallocate
storage, close devices, etc. Another feature was that when a condition
was signalled, the stack was searched for handlers; if no handler was
found, then "unclaimed_signal" was raised instead and the search
repeated.
(PL/I and Multics signals were different from Java, in that they had
continuation semantics: if a condition handler returned, the program
was restarted at the point of signal -- more or less.)
> Lisp is very expressional.
(Assuming you mean Common Lisp when you say Lisp.)
I sometimes find it annoying that CL exposes high-level functionality
but doesn't give me a handle on the underlying low-level stuff that I
know must be there. IMHO, the most egregious example of that is stack
unwinding: both throw and condition signalling do stack unwinding, but
neither is more primitive than the other, and the functionality that
underlies both is not exposed.
Other examples include DEFSTRUCT in pre-CLOS Common Lisp and the lack
of a standardised handle on the fasdumping mechanism.
Juliusz
From: Russell McManus
Subject: Re: Impementational and Expressional
Date:
Message-ID: <87vf6pxkgi.fsf@cl-user.org>
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> Other examples include DEFSTRUCT in pre-CLOS Common Lisp and the
> lack of a standardised handle on the fasdumping mechanism.
Does make-load-form do what you want? You can compile some code
containing data, and then load the compiled code.
-russ
>> Other examples include DEFSTRUCT in pre-CLOS Common Lisp and the
>> lack of a standardised handle on the fasdumping mechanism.
> Does make-load-form do what you want?
MAKE-LOAD-FORM is good. What I'm complaining about is an independent
issue -- the lack of a way to call the fasdumper other than COMPILE-FILE.
> You can compile some code containing data, and then load the
> compiled code.
Exactly. I have to call the compiler just to get at the fasdumper.
Juliusz
From: Russell McManus
Subject: Re: Impementational and Expressional
Date:
Message-ID: <87r7hcxoef.fsf@cl-user.org>
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
>>> Other examples include DEFSTRUCT in pre-CLOS Common Lisp and the
>>> lack of a standardised handle on the fasdumping mechanism.
>
>> Does make-load-form do what you want?
>
> MAKE-LOAD-FORM is good. What I'm complaining about is an independent
> issue -- the lack of a way to call the fasdumper other than COMPILE-FILE.
>
>> You can compile some code containing data, and then load the
>> compiled code.
>
> Exactly. I have to call the compiler just to get at the fasdumper.
In what way is this not a standardized fasdumping mechanism?
-russ
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> I sometimes find it annoying that CL exposes high-level functionality
> but doesn't give me a handle on the underlying low-level stuff that I
> know must be there. IMHO, the most egregious example of that is stack
> unwinding: both throw and condition signalling do stack unwinding, but
> neither is more primitive than the other, and the functionality that
> underlies both is not exposed.
Actually, signalling a condition does not unwind the stack -- that's
rather the point of separating handlers from restarts -- and isn't it
clear that the restart facility is built on top of throw/return?
> Other examples include DEFSTRUCT in pre-CLOS Common Lisp and the lack
> of a standardised handle on the fasdumping mechanism.
I'd be interested to know of your idea for a standardised handle on
the fasdumping mechanism.
Christophe
> Actually, signalling a condition does not unwind the stack -- that's
> rather the point of separating handlers from restarts
Fair enough.
> and isn't it clear that the restart facility is built on top of
> throw/return?
It's not obvious to me; there's a lot of extra mechanics in restarts,
embodied in COMPUTE-RESTARTS.
While it is in principle possible to implement that using THROW/CATCH,
dynamic variables, and magic, a more reasonable way is to have
introspection facilities that can walk the stack. I'd like to have
this functionality exported.
>> Other examples include DEFSTRUCT in pre-CLOS Common Lisp and the lack
>> of a standardised handle on the fasdumping mechanism.
> I'd be interested to know of your idea for a standardised handle on
> the fasdumping mechanism.
(with-open-data-file (s "data" :direction :output :if-exists :honk)
(dolist (a *list-full-of-very-large-but-heterogeneous-arrays*)
(dump-object a s)))
Juliusz
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
>> and isn't it clear that the restart facility is built on top of
>> throw/return?
>
> It's not obvious to me; there's a lot of extra mechanics in restarts,
> embodied in COMPUTE-RESTARTS.
>
> While it is in principle possible to implement that using THROW/CATCH,
> dynamic variables, and magic, a more reasonable way is to have
> introspection facilities that can walk the stack. I'd like to have
> this functionality exported.
Have you looked at how current implementations actually implement
restarts?
Christophe