From CMUCL news on CMUCL website,
--8<----------------
2003-02-05
Support for generalized function names has been added, thanks to Gerd
Moellman. Standard function names are restricted to symbol like FOO,
and the special case of (SETF FOO). This patch allows general names of
the form (FOO BAR BAZ), which should be particularly useful for naming
CLOS-related functions.
--8<----------------
Anyone want to slap me with a cluestick and provide an example of why
these are/aren't cool/useful? I seem to be having a (hopefully
temporary) imagination failure at the moment.
David Golden
--
Don't eat yellow snow.
In article <··························@posting.google.com>,
David Golden <············@oceanfree.net> wrote:
>From CMUCL news on CMUCL website,
>
>--8<----------------
>2003-02-05
>
>Support for generalized function names has been added, thanks to Gerd
>Moellman. Standard function names are restricted to symbol like FOO,
>and the special case of (SETF FOO). This patch allows general names of
>the form (FOO BAR BAZ), which should be particularly useful for naming
>CLOS-related functions.
>--8<----------------
>
>
>Anyone want to slap me with a cluestick and provide an example of why
>these are/aren't cool/useful? I seem to be having a (hopefully
>temporary) imagination failure at the moment.
Symbolics has them. They were often used to provide names for various
types of internal functions, which allows you to pass those function names
to DISASSEMBLE, TRACE, etc.
For instance, lexical closures have names like (:INTERNAL
<containing-function> <index>), and methods have names like (:METHOD
<generic-func> <class-specifiers>).
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> In article <··························@posting.google.com>,
> David Golden <············@oceanfree.net> wrote:
> >From CMUCL news on CMUCL website,
> >
> >--8<----------------
> >2003-02-05
> >
> >Support for generalized function names has been added, thanks to Gerd
> >Moellman. Standard function names are restricted to symbol like FOO,
> >and the special case of (SETF FOO). This patch allows general names of
> >the form (FOO BAR BAZ), which should be particularly useful for naming
> >CLOS-related functions.
> >--8<----------------
> >
> >
> >Anyone want to slap me with a cluestick and provide an example of why
> >these are/aren't cool/useful? I seem to be having a (hopefully
> >temporary) imagination failure at the moment.
>
> Symbolics has them. They were often used to provide names for various
> types of internal functions, which allows you to pass those function names
> to DISASSEMBLE, TRACE, etc.
>
> For instance, lexical closures have names like (:INTERNAL
> <containing-function> <index>), and methods have names like (:METHOD
> <generic-func> <class-specifiers>).
Allegro CL also has them; we call them "function specs", and they are
an extended subset of function names which are in list form. We also
provide a programming interface to them, called def-function-spec-handler,
which allows the programmer to create new namespaces and also gives the
programmer control over how to manage the namespace which the function
spec represents.
See
http://www.franz.com/support/documentation/6.2/doc/implementation.htm#function-specs-1
and
http://www.franz.com/support/documentation/6.2/doc/pages/operators/excl/def-function-spec-handler.htm
The reference in the above CMUCL description to usefulness in CLOS
naming probably refers to the ability to find methods easily by name:
CL-USER(1): (defmethod foo ((x integer)) (1+ x))
#<STANDARD-METHOD FOO (INTEGER)>
CL-USER(2): (fdefinition '(method foo (integer)))
#<Interpreted Function (METHOD FOO (INTEGER))>
CL-USER(3):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Allegro CL also has them; we call them "function specs", and they are
> an extended subset of function names which are in list form. We also
> provide a programming interface to them, called def-function-spec-handler,
> which allows the programmer to create new namespaces and also gives the
> programmer control over how to manage the namespace which the function
> spec represents.
Likewise in CMUCL, with EXT:DEFINE-FUNCTION-NAME-SYNTAX.
> The reference in the above CMUCL description to usefulness in CLOS
> naming probably refers to the ability to find methods easily by
> name:
Methods = method functions?
CMUCL's CLOS generates quite a number of internal functions, method
functions being only one sort, which suffer from the usual problems of
symbol concing. All of these use generalized function names in my
PCL, which will hit CMUCL after the release of 18e.
Gerd Moellmann <··············@t-online.de> writes:
> Duane Rettig <·····@franz.com> writes:
> > Allegro CL also has them; we call them "function specs", and they are
> > an extended subset of function names which are in list form. We also
> > provide a programming interface to them, called def-function-spec-handler,
> > which allows the programmer to create new namespaces and also gives the
> > programmer control over how to manage the namespace which the function
> > spec represents.
>
> Likewise in CMUCL, with EXT:DEFINE-FUNCTION-NAME-SYNTAX.
Likewise in LispWorks. We call them definition specs now, because the
function names are integrated with the names in other namespaces, so
that the source location facility has unified interfaces to manage all
of them. Also stuff like the IDE's Undefine command works through
definition specs.
The set of definitions and namespaces is also extensible, but the doc
hasn't been published. Dig around in the DSPEC package if you're
feeling adventurous.
--
Pekka P. Pirinen
Those who do not understand Lisp are condemned to reinvent it, poorly.
- Far�, without apologies to Henry Spencer.
(or should that be "Those who do not know Genera..."?)
Barry Margolin <··············@level3.com> writes:
> In article <··························@posting.google.com>,
> David Golden <············@oceanfree.net> wrote:
> >From CMUCL news on CMUCL website,
> >
> >--8<----------------
> >2003-02-05
> >
> >Support for generalized function names has been added, thanks to Gerd
> >Moellman. Standard function names are restricted to symbol like FOO,
> >and the special case of (SETF FOO). This patch allows general names of
> >the form (FOO BAR BAZ), which should be particularly useful for naming
> >CLOS-related functions.
> >--8<----------------
> >
> >Anyone want to slap me with a cluestick and provide an example of why
> >these are/aren't cool/useful? I seem to be having a (hopefully
> >temporary) imagination failure at the moment.
>
> Symbolics has them. They were often used to provide names for various
> types of internal functions, which allows you to pass those function names
> to DISASSEMBLE, TRACE, etc.
>
> For instance, lexical closures have names like (:INTERNAL
> <containing-function> <index>), and methods have names like (:METHOD
> <generic-func> <class-specifiers>).
Additionally, any place where you create an internal function or
method based on a user-supplied name benefits from generalized
function names. The usual way of creating secret function names --
appending something to the print name of the supplied symbol and
reinterning it -- is vulnerable to all sorts of problems.
Tim
Timothy Moore <·····@bricoworks.com> writes:
> Barry Margolin <··············@level3.com> writes:
> > In article <··························@posting.google.com>,
> > David Golden <············@oceanfree.net> wrote:
> > >From CMUCL news on CMUCL website,
> > >
> > >--8<----------------
> > >2003-02-05
> > >
> > >Support for generalized function names has been added, thanks to Gerd
> > >Moellman. Standard function names are restricted to symbol like FOO,
> > >and the special case of (SETF FOO). This patch allows general names of
> > >the form (FOO BAR BAZ), which should be particularly useful for naming
> > >CLOS-related functions.
> > >--8<----------------
> > >
> > >Anyone want to slap me with a cluestick and provide an example of why
> > >these are/aren't cool/useful? I seem to be having a (hopefully
> > >temporary) imagination failure at the moment.
> >
> > Symbolics has them. They were often used to provide names for various
> > types of internal functions, which allows you to pass those function names
> > to DISASSEMBLE, TRACE, etc.
> >
> > For instance, lexical closures have names like (:INTERNAL
> > <containing-function> <index>), and methods have names like (:METHOD
> > <generic-func> <class-specifiers>).
>
> Additionally, any place where you create an internal function or
> method based on a user-supplied name benefits from generalized
> function names. The usual way of creating secret function names --
> appending something to the print name of the supplied symbol and
> reinterning it -- is vulnerable to all sorts of problems.
While it's useful for CMU to have this facility, I'd like to urge a little
"go slow" and "think" in all of this. Some of the risks:
- The system needs to reserve some of these for its own use and/or
there needs to be some talk of namespacing. While indeed it saves
you from dreaded "symbolconc'ing", it's still the case that if user
applications grab interesting car's of lists, that makes it harder
for "the system" (or even "other modules") to win later becuase they
might take those same ones.
- There are open questions about whether if (SETF FOO) is taken, you can
store into (SETF FOO BAR), that is, other tuples that start with the
first symbol.
- Some systems do (symbol obj obj...) but the facility described here
is (symbol symbol symbol ...)
- There are unresolved issues of whether storing in some of these
places require "additional bookkeeping". This makes it all the more
important not to accidentally store into these.
- Examining history, the Lisp Machine facilities for these required you
to pre-define a key symbol that you were going to use (:INTERNAL ...)
and then you owned that namespace. This was important for several
reasons:
- if you accidentally store in a misnamed place, it gets caught
- it simply isn't that every (FOO BAR BAZ) takes arbitrary objects
in some 'argument' positions (BAR and BAZ) but not in others;
the error checking that could be done is best thought of as being
dispatched off of the car of the expression, probably.
- some of these don't require storage [i'll come back to this below]
e.g., (:INTERNAL FOO 3) requires storage but
(:TRACED-FUNCTION FOO) might be stored back into FOO's value cell.
- there may be other useful services you want to associate with
these, like encapsulation/de-encapsulation support, asking the
function what its "parent" function is, etc.
e.g., (:TRACED-FUNCTION (:INTERNAL FOO 3))
is something that you can ask the source file of by chasing its
parent to find it's in the function FOO and then asking the source
file for that.
- There are issues [see Lispm discussion above] of whether in fact every
(FOO BAR BAZ) tuple requires storage. It's useful to have a facility
that is capable of providing the storage mapping service for those that
do, but that's a different question than whether every one SHOULD map
to a different location. Some tuples map to concrete locations, some
to virtual ones that might be representationally shared. No definition
facility sounds like it goes with the stuff CMU offers for separating
these two issues.
- There are equality issues in whether (FOO (BAR BAZ)) is compared at
the subcomponent level by EQUAL or EQ or something else. Before you
dismiss the "something else" consider that there may be items that
are "information-only" in some definition specs and are not part of the
selector for "where to store". The CMU facility is conservative in
offering only symbols, but that may create a lot of baggage that depends
on implicit assumptions that the community needs to think about more
explicitly.
The issue here is that surely someone will clone this facility or something
like it for other implementations at one point or another. And if any
of these design points vary, then the community may get into a mess.
Kent M Pitman wrote:
> And if any
> of these design points vary, then the community may get into a mess.
Another good reason to start some sort of community standards process.
Standards (even informal ones) make it harder for folks to take off on the
wrong track.
Many of these ideas (or ones like them) have been tried in the past. Many
are not widely documented.
The elders of the Lisp community aren't getting any younger and a lot of
wisdom (and folklore) is going to be lost over the next couple decades. A
standards process could bring those with this knowledge together with
younger members of the Lisp community and help prevent the loss of this
information, saving those who follow a lot of recovery time.
faa
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>While it's useful for CMU to have this facility, I'd like to urge a little
>"go slow" and "think" in all of this. Some of the risks:
>
> - The system needs to reserve some of these for its own use and/or
> there needs to be some talk of namespacing. While indeed it saves
> you from dreaded "symbolconc'ing", it's still the case that if user
> applications grab interesting car's of lists, that makes it harder
> for "the system" (or even "other modules") to win later becuase they
> might take those same ones.
As long as arbitrary symbols are allowed in the car of the generalized
function name, the package system should work well. Users should not use
keywords or symbols in the COMMON-LISP package to mark their generalized
function names.
> - There are open questions about whether if (SETF FOO) is taken, you can
> store into (SETF FOO BAR), that is, other tuples that start with the
> first symbol.
I haven't seem CMUCL's documentation, but I would be surprised if the
handling were done any other way than by a dispatch on the car of the
generalized function name.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >While it's useful for CMU to have this facility, I'd like to urge a little
> >"go slow" and "think" in all of this. Some of the risks:
> >
> > - The system needs to reserve some of these for its own use and/or
> > there needs to be some talk of namespacing. While indeed it saves
> > you from dreaded "symbolconc'ing", it's still the case that if user
> > applications grab interesting car's of lists, that makes it harder
> > for "the system" (or even "other modules") to win later becuase they
> > might take those same ones.
>
> As long as arbitrary symbols are allowed in the car of the generalized
> function name, the package system should work well. Users should not use
> keywords or symbols in the COMMON-LISP package to mark their generalized
> function names.
You missed my point (though you're thinking along the same lines).
I didn't mean packages in the literal sense. I meant there has to be a
line that partitions "my use" from "your use". In symbols, I claim a package
and you claim a different package since we made packages to be for that
purpose. In these consish specs, the symbol in the car is something I or
you claim, but hopefully not both, so they function as the namespaces
I was referring to here. If you believe that they use packaged symbols
that they own, then indeed, that's a sufficient rule. But since the example
of the CMU stuff was the list (SETF FOO) or some such, using a CL-related
symbol, it's importnat to note what the key is [the car]. For example,
an equally good rule might be "always use at least one symbol packaged"
(as happens for symbols/properties) note that the problem with that is
that you can't say you're choosing a list like (foo bar baz) where BAR
is the symbol in your package since someone else might have a conflicting
convention that clashes. I saw nothing in the c.l.l post about the CMU
facility that noted that the car of the list was privileged and something
that good style requires users to partition. It's important to do that
is all I was saying, and I think from what you wrote that you agree with me.
> > - There are open questions about whether if (SETF FOO) is taken, you can
> > store into (SETF FOO BAR), that is, other tuples that start with the
> > first symbol.
>
> I haven't seem CMUCL's documentation, but I would be surprised if the
> handling were done any other way than by a dispatch on the car of the
> generalized function name.
I haven't read it either. It sounded to me from what was posted like
they'd just made EQUAL hash tables and you could write programs that
store into any arbitrary (X Y Z), which would be underconstrained.
But hopefully I'm wrong. Anyway, I didn't think posting a list of things
for people to think about would hurt anyone.
Kent M Pitman <······@world.std.com> writes:
> I saw nothing in the c.l.l post about the CMU facility that noted
> that the car of the list was privileged and something that good
> style requires users to partition.
The car is privileged in CMU, and in the docs I'm telling users to use
symbols from their own packages, if they don't want to take the risk
of scribbling over internally used names.