Hi there,
How best to do introspection to the object-function? Specifically -
need know by its arguments. I.e.:
(... (fn) (...I want to know which arguments can accept fn...) (apply
fn ...)...)
On 17 ÁÐÒ, 03:16, Ilshad Habibullin <··········@gmail.com> wrote:
> Hi there,
>
> How best to do introspection to the object-function? Specifically -
> need know by its arguments. I.e.:
>
> (... (fn) (...I want to know which arguments can accept fn...) (apply
> fn ...)...)
(Common Lisp)
In article
<····································@e18g2000yqo.googlegroups.com>,
Ilshad Habibullin <··········@gmail.com> wrote:
> Hi there,
>
> How best to do introspection to the object-function? Specifically -
> need know by its arguments. I.e.:
>
> (... (fn) (...I want to know which arguments can accept fn...) (apply
> fn ...)...)
FUNCTION-LAMBDA-EXPRESSION
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Apr 17, 6:26 am, Barry Margolin <······@alum.mit.edu> wrote:
> In article
> <····································@e18g2000yqo.googlegroups.com>,
> Ilshad Habibullin <··········@gmail.com> wrote:
>
> > Hi there,
>
> > How best to do introspection to the object-function? Specifically -
> > need know by its arguments. I.e.:
>
> > (... (fn) (...I want to know which arguments can accept fn...) (apply
> > fn ...)...)
>
> FUNCTION-LAMBDA-EXPRESSION
With the caveat that the standard has the utterly evil "an
implementation can do whatever" (in this case return NIL) for FUNCTION-
LAMBDA-EXPRESSION.
There is no foolproof portable way of doing this, although all
implementations I know of have an ARGLIST function of some kind.
Cheers
--
Marco
www.european-lisp-symposium.org
On Apr 16, 11:17 pm, Marco Antoniotti <·······@gmail.com> wrote:
> On Apr 17, 6:26 am, Barry Margolin <······@alum.mit.edu> wrote:
>
> > In article
> > <····································@e18g2000yqo.googlegroups.com>,
> > Ilshad Habibullin <··········@gmail.com> wrote:
>
> > > Hi there,
>
> > > How best to do introspection to the object-function? Specifically -
> > > need know by its arguments. I.e.:
>
> > > (... (fn) (...I want to know which arguments can accept fn...) (apply
> > > fn ...)...)
>
> > FUNCTION-LAMBDA-EXPRESSION
>
> With the caveat that the standard has the utterly evil "an
> implementation can do whatever" (in this case return NIL) for FUNCTION-
> LAMBDA-EXPRESSION.
It's not utterly evil; there's a reason why users would _not_ ant
their implementations to provide function-lambda-expressions: space.
When you compile a function, you lose the original source code; it is
the idea behind compilation (i.e. to get from source into some more-
efficient form which can be executed more directly). To save the
original source for any kind of introspection purposes should always
be a choice; otherwise, the user who needs to be able to build his
base lisp image less than a megabyte in size would not be successful.
In Allegro CL we obey the value of the global-variable excl:*save-
function-lambda-expression* (http://www.franz.com/support/
documentation/current/doc/variables/excl/s_save-function-lambda-
expression_s.htm) which when true will cause compilation to save off
the lambda expression, but which will save the space taken by this
source when the variable is false.
Duane
On Apr 17, 9:10 am, ·····@franz.com wrote:
> On Apr 16, 11:17 pm, Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
> > On Apr 17, 6:26 am, Barry Margolin <······@alum.mit.edu> wrote:
>
> > > In article
> > > <····································@e18g2000yqo.googlegroups.com>,
> > > Ilshad Habibullin <··········@gmail.com> wrote:
>
> > > > Hi there,
>
> > > > How best to do introspection to the object-function? Specifically -
> > > > need know by its arguments. I.e.:
>
> > > > (... (fn) (...I want to know which arguments can accept fn...) (apply
> > > > fn ...)...)
>
> > > FUNCTION-LAMBDA-EXPRESSION
>
> > With the caveat that the standard has the utterly evil "an
> > implementation can do whatever" (in this case return NIL) for FUNCTION-
> > LAMBDA-EXPRESSION.
>
> It's not utterly evil; there's a reason why users would _not_ ant
> their implementations to provide function-lambda-expressions: space.
> When you compile a function, you lose the original source code; it is
> the idea behind compilation (i.e. to get from source into some more-
> efficient form which can be executed more directly). To save the
> original source for any kind of introspection purposes should always
> be a choice; otherwise, the user who needs to be able to build his
> base lisp image less than a megabyte in size would not be successful.
> In Allegro CL we obey the value of the global-variable excl:*save-
> function-lambda-expression* (http://www.franz.com/support/
> documentation/current/doc/variables/excl/s_save-function-lambda-
> expression_s.htm) which when true will cause compilation to save off
> the lambda expression, but which will save the space taken by this
> source when the variable is false.
>
> Duane
Hmm, A couple of typos here:
1. There's a reason why users would not want ...
2. The link to the documentation for function-lambda-expression did
not come out completely; I'll try again and hope for the best:
http://www.franz.com/support/documentation/current/doc/variables/excl/s_save-function-lambda-expression_s.htm
Hopefully these make it correctly in this post. Ah, to have my old
gnus interface again :-(
Duane
On Apr 17, 6:10 pm, ·····@franz.com wrote:
> On Apr 16, 11:17 pm, Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
> > On Apr 17, 6:26 am, Barry Margolin <······@alum.mit.edu> wrote:
>
> > > In article
> > > <····································@e18g2000yqo.googlegroups.com>,
> > > Ilshad Habibullin <··········@gmail.com> wrote:
>
> > > > Hi there,
>
> > > > How best to do introspection to the object-function? Specifically -
> > > > need know by its arguments. I.e.:
>
> > > > (... (fn) (...I want to know which arguments can accept fn...) (apply
> > > > fn ...)...)
>
> > > FUNCTION-LAMBDA-EXPRESSION
>
> > With the caveat that the standard has the utterly evil "an
> > implementation can do whatever" (in this case return NIL) for FUNCTION-
> > LAMBDA-EXPRESSION.
>
> It's not utterly evil; there's a reason why users would _not_ ant
> their implementations to provide function-lambda-expressions: space.
> When you compile a function, you lose the original source code; it is
> the idea behind compilation (i.e. to get from source into some more-
> efficient form which can be executed more directly). To save the
> original source for any kind of introspection purposes should always
> be a choice; otherwise, the user who needs to be able to build his
> base lisp image less than a megabyte in size would not be successful.
> In Allegro CL we obey the value of the global-variable excl:*save-
> function-lambda-expression* (http://www.franz.com/support/
> documentation/current/doc/variables/excl/s_save-function-lambda-
> expression_s.htm) which when true will cause compilation to save off
> the lambda expression, but which will save the space taken by this
> source when the variable is false.
Yes. I agree with that. What I am griping (for years now) is that
the freedom is not for the user, but for two implementations to do
things differently and in what is essentially a random way from the
user's point of view.
Allegro does it right (as well as other implementations). But, given
your argument, the excl:*save-function-lambda-expression* (ora an
equivalent global variable *ARGLIST-AVAILABLE-P*, name it as you wish,
with similar semantics) *should have been* in the standard. Instead
we got the *evil* "implementation dependent" verbiage.
If there is one simple starting point from which to improve the
standard, that is the swatting away of most of (all?!?) the
"implementation dependent" locutions. At least some other people on
the ilc09.scheming.org fora seem to agree with it.
Cheers
--
Marco
Marco Antoniotti <·······@gmail.com> wrote:
+---------------
| Allegro does it right (as well as other implementations).
+---------------
Most implementations at least get DESCRIBE right, if all the OP
wanted was args, types, and doumentation string.
+---------------
| If there is one simple starting point from which to improve the
| standard, that is the swatting away of most of (all?!?) the
| "implementation dependent" locutions. At least some other people on
| the ilc09.scheming.org fora seem to agree with it.
+---------------
Note: "ilc09.scheming.org" just gets Anton's consulting business's
home page. One needs to use "ilc2009.scheming.org" to get to the forum.
[Thus illustrating once again the evils of DNS wildcards!! ;-} ;-} ]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Duane Rettig wrote:
> It's not utterly evil; there's a reason why users would _not_ ant
> their implementations to provide function-lambda-expressions: space.
> To save the original source for any kind of introspection purposes
> should always be a choice;
Yes, but while this choice is indeed at the user-level, the way to
implement it still an implementor's choice, and this is bad. It could
have been standardized. Using the debug quality at a particular level
would have made sense for instance, or even standardizing your
> excl:*save- function-lambda-expression*
(or another implementation's name for it ;-).
--
European Lisp Symposium, May 2009: http://www.european-lisp-symposium.org
European Lisp Workshop, July 2009: http://elw.bknr.net/2009
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
On Apr 18, 12:24 am, Didier Verna <······@lrde.epita.fr> wrote:
> Duane Rettig wrote:
> > It's not utterly evil; there's a reason why users would _not_ ant
> > their implementations to provide function-lambda-expressions: space.
> > To save the original source for any kind of introspection purposes
> > should always be a choice;
>
> Yes, but while this choice is indeed at the user-level, the way to
> implement it still an implementor's choice, and this is bad. It could
> have been standardized. Using the debug quality at a particular level
> would have made sense for instance, or even standardizing your
>
> > excl:*save- function-lambda-expression*
>
> (or another implementation's name for it ;-).
True; I've been thinking about adding another of what we call
"compiler-switches" (functions in Allegro CL whose values are a
function of the major optimization qualities) and giving it some
component that depends at least on the space quality (i.e. when space
is higher, the switch turns off). I suppose it should also be
dependent on the debug quality as well, so perhaps (or (> space 1) (>
debug 2)) ...
This would place the interface back into the area of the standard
optimization qualities. If you want to consider the glass half-empty,
you can note that _none_ of the optimization qualities are
standardized; an implementation is free to interpret for itself what
(optimize (speed 1)) actually means. We recognize this issue, and
that's why w place these "switches" in between the optimization
qualities and the compiler, to allow the user to change what
optimization levels a particular compiler feature fires or does not
fire.
However, I also believe that it is important to figure out good
defaults for such qualities, and the glass-half-full viewpoint is that
most of the CL implementations provide reasonable defaults for these
qualities.
Duane
[Correcting a typo]:
On Apr 18, 9:01 am, ·····@franz.com wrote:
> I suppose it should also be dependent on the debug quality
> as well, so perhaps (or (> space 1) (> debug 2)) ...
This should have been (or (< space 1) (> debug 2))
Duane
On Apr 17, 2:17 am, Marco Antoniotti <·······@gmail.com> wrote:
> On Apr 17, 6:26 am, Barry Margolin <······@alum.mit.edu> wrote:
>
> > In article
> > <····································@e18g2000yqo.googlegroups.com>,
> > Ilshad Habibullin <··········@gmail.com> wrote:
>
> > > Hi there,
>
> > > How best to do introspection to the object-function? Specifically -
> > > need know by its arguments. I.e.:
>
> > > (... (fn) (...I want to know which arguments can accept fn...) (apply
> > > fn ...)...)
>
> > FUNCTION-LAMBDA-EXPRESSION
>
> With the caveat that the standard has the utterly evil "an
> implementation can do whatever" (in this case return NIL) for FUNCTION-
> LAMBDA-EXPRESSION.
>
> There is no foolproof portable way of doing this, although all
> implementations I know of have an ARGLIST function of some kind.
>
> Cheers
> --
> Marcowww.european-lisp-symposium.org
fwiw, as marco knows from writing clazy, implementations often provide
more useful functions:
ccl:
? (function-lambda-expression #'+)
NIL
NIL
+
;; not in the standard:
? (ccl::arglist #'+)
(CCL::&LEXPR CCL::NUMBERS)
:ANALYSIS
?
lispworks:
CL-USER 1 > (function-lambda-expression #'+)
NIL
NIL
+
;; not in the standard:
CL-USER 2 > (function-lambda-list #'+)
(&REST SYSTEM::ARGS)
CL-USER 3 >
Hi!
For knowing how implementations do introspection, look at the code
of
libraries/tools which use/require/supply introspection:
1. SLIME
2. TINAA
etc...