lisp introspection/reflection question
in [Lisp]
|
Prev: Do as the Romans do
Next: managing large table of data
From: Duane Rettig on 2 Feb 2010 15:53 On Feb 2, 11:49 am, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > Rainier, Duane, I agree that I could have choosen a better analogy > than buffer overflow. I'm a little lazy. > > "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > >> If your application depends on the availability of the list of > >> arguments, then you cannot count on function-lambda-expression any > >> more than you can count on buffer overflows working. > > > I can count on what the implementation I use does. > > Maybe I have even chosen this implementation because it > > provides that feature. Once I use that, the feature > > will not be there or absent by random. It's just > > a question of configuration. > > > What some other implementations might do or not - I don't care unless > > I need to run my software there. > > Well, it depends on the circumstances. Note that Rainer and I don't see things the same here, and I agree with you on this one. Of course, Rainer's point of view is a valid one, and if he doesn't care about other CL implementations, it makes it easier for him. > For my scripts, (what goes in ~/bin and starts with #!/usr/bin/clisp, > I've made indeed this choice of an implementation, and I use freely > enough stuff in the EXT packages (I still prefix it by #+clisp most of > the time, with #-clisp(error "How to do ~S" 'that) alternatives). > > However, for the rest of my lisp code, I try to target Common Lisp, > not a specific implementation. This is where I scratch my head. Do you use sockets? Do you use foreign functions? Do you use the MOP? If so, then you do not use Common Lisp, in as pure a sense as you're implying. There are of course other extensions to CL which you may or may not use, but these three to me seem to be big ones, likely to be used in some way by any CL user. The point is that CL is not fully specified; it was a snapshot of 1994 work in progress. And to hold to that particular snapshot, which was a painful one to take, and to not allow other extensions in as de-facto standards, would be ludicrous. > Now more specifically for FUNCTION-LAMBDA-EXPRESSION and ARGLIST, I > maintain my objections, given this later mind set of writing Common > Lisp, and not SBCL or clisp (or a set of implementation) code. I have no quarrel with you about f-l-e, for the same reasons you state, and which same reasons I also gave in one of my previous replies. [ ... ] > The requirements on introspection doesn't depend on the size or speed > constraints so definitely FUNCTION-LAMBDA-EXPRESSION whose result is > linked to this size constraint doesn't fit the bill. Agreed. > As for ARGLIST, while I agree that it would be nice if it was standard > (CDR) and implemented by all implementations, this is not the case, > and since I want to be able to escalate the choice of the target > implementation at a later time, I cannot depend on it either > (without, as I explained, providing myself an implementation which > would hten work everywhere). What CL version do you use that doesn't have an arglist function? And what does that vendor say when you complain about it? > Of course, it it was only for a small clisp script, or other > implementation specific code, there'd be no problem in using the > implementation specific API. clisp? clisp certainly has arglist - it is external in their ext package. Duane
From: joswig on 2 Feb 2010 16:37 On 2 Feb., 21:53, Duane Rettig <du...(a)franz.com> wrote: > On Feb 2, 11:49 am, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: > > > > > > > Rainier, Duane, I agree that I could have choosen a better analogy > > than buffer overflow. I'm a little lazy. > > > "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > > >> If your application depends on the availability of the list of > > >> arguments, then you cannot count on function-lambda-expression any > > >> more than you can count on buffer overflows working. > > > > I can count on what the implementation I use does. > > > Maybe I have even chosen this implementation because it > > > provides that feature. Once I use that, the feature > > > will not be there or absent by random. It's just > > > a question of configuration. > > > > What some other implementations might do or not - I don't care unless > > > I need to run my software there. > > > Well, it depends on the circumstances. > > Note that Rainer and I don't see things the same here, and I agree > with you on this one. Of course, Rainer's point of view is a valid > one, and if he doesn't care about other CL implementations, it makes > it easier for him. If I want to write a web-based development environment and XYZ CL would be the only one Lisp implementation that provides me the ARGLIST for Lisp functions, then XYZ CL would enable me to ship the application. The others not. If I had the choice between not shipping the app and shipping it, would my choice in any way influenced in what the standard says about availability of the functionality? Definitely not. I need the functionality in a reliable way in some Lisp implementation. I don't need to convert all other Lisp implementations - future or past. I would not care much. If another Lisp then decides to add this functionality in a reliable way, then I would be happy if it uses the same name that the standard 'reserves' for that functionality. .... ....
From: Duane Rettig on 2 Feb 2010 19:24 On Feb 2, 1:37 pm, "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> wrote: > On 2 Feb., 21:53, Duane Rettig <du...(a)franz.com> wrote: > > > > > > > On Feb 2, 11:49 am, p...(a)informatimago.com (Pascal J. Bourguignon) > > wrote: > > > > Rainier, Duane, I agree that I could have choosen a better analogy > > > than buffer overflow. I'm a little lazy. > > > > "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > > > What some other implementations might do or not - I don't care unless > > > > I need to run my software there. > > > > Well, it depends on the circumstances. > > > Note that Rainer and I don't see things the same here, and I agree > > with you on this one. Of course, Rainer's point of view is a valid > > one, and if he doesn't care about other CL implementations, it makes > > it easier for him. > > If I want to write a web-based development environment and XYZ CL > would be the only one Lisp implementation that provides me the > ARGLIST for Lisp functions, then XYZ CL would enable me to ship > the application. The others not. ARGLIST is not such a good example here, because many more than just XYZ lisp implementation provide an ARGLIST function. Instead, let's generalize your statement to say that XYZ lisp implementation has a function ABC which you need, and which other lisp implementations do not have. If I had the choice between not > shipping the app and shipping it, would my choice in any way > influenced in what the standard says about availability of the > functionality? Definitely not. I need the functionality in > a reliable way in some Lisp implementation. I don't need to > convert all other Lisp implementations - future or past. > I would not care much. If another Lisp then decides to > add this functionality in a reliable way, then I would be > happy if it uses the same name that the standard 'reserves' > for that functionality. I agree completely with this, and that is why I wrote that your point of view is a valid one. However, for the ARGLIST function, this should not be of concern anyway, because most CLs (if not all) have some form of the function or other. Duane
From: D Herring on 2 Feb 2010 21:28 On 02/02/2010 02:13 AM, Duane Rettig wrote: > Someone else also mentioned an internal function called arglist (in > the implementation's internal package), and I submit that that is more > likely to be of use to you if it really is the arglist you want. I > recall someone (but I don't remember who it was, sorry) who posted on > c.l.l. an implementation independent version of arglist for all of the > CLs on which he was working, which called whatever version of arglist > was appropriate for the implementation (Allegro CL's is excl:arglist, > by the way). Maybe a google search (or perhaps a reminder from > someone who created or who uses that definition) might be helpful > here. The reason why I think it is a better bet than f-l-e is because > although the lambda source is mostly expendable when a function is > compiled, the argument list is not; it must be used by debuggers to > decide where arguments actually reside; it allows IDEs to name > argument lists while you are in the editor writing code; it allows > programs to decide arity, etc., and it is also less likely to be > elided from an implementation because of its necessity. So it is more > likely that the tradeoffs in whether to keep the argument list or not > are more in your favor than that of the entire source for the > function. Again, I will recommend that people check out Conium. Its basically the Slime CL code, stripped of all Slime's client/server and emacs code. http://gitorious.org/conium - Daniel
From: Madhu on 2 Feb 2010 22:01
* D Herring <hkan0f$9ug$1(a)news.eternal-september.org> : Wrote on Tue, 02 Feb 2010 21:28:31 -0500: | Again, I will recommend that people check out Conium. Its basically | the Slime CL code, stripped of all Slime's client/server and emacs | code. | | http://gitorious.org/conium And it adds at least 5 gratuituous dependencies dependencies on at least five 3rd party libraries (directly) This is not a good thing unles youre in the library selling business -- Madhu |