is it ok to (setf (get :const :prop) :val)?

Hi group!
Just the subject.
CLHS says it is ok. Is it really ok in implementations?
It is needed to fix iterate's conflict to other packages defining
'for macro.
It if is ok, I'll do

(in-package :iterate)
(defsynonym :for for)
(defsynonym :in in)
(defsynonym :collect collect)
.....
(in-package :my-package)
(import iter::iter)
(iter (:for i :in '(1 2 3)) (:collect i))

Synonym mechanism in iterate relies upon setting a property of a
symbol which we want to become a synonym. I want this synonym to be
from keyword package. So I need put a property on a keyword.

This works in lispworks, clisp and sbcl and this should work in any cl
implementation.
Are there some advices if it does really work?

With best regards,
Budden

Additionally, is it ok to
(defun :foo () 1)
This works in those three cl implementation and I found nothing in a
standard which would forbid that.

It is required for allow iterate special clauses like "finally" to be
keywords too.

På Sun, 02 Nov 2008 17:36:03 +0100, skrev budden <budden01@mtu-net.ru>:

> Additionally, is it ok to
> (defun :foo () 1)
> This works in those three cl implementation and I found nothing in a
> standard which would forbid that.
>
> It is required for allow iterate special clauses like "finally" to be
> keywords too.

No, that is not OK. Keywords are exported to all packages. This if OK if
ONLY symbol-name is defined. Think of it. Keywords are just stand in for a
string so it is parsed more efficeintly. So even if it is used in
diffenent context's it doesn't matter. But if you start defining
symbol-function or symbol-value as well then it becomes context dependent
and all sorts of conflicts can occur. So let variables and functions
belong to a package and only use :notation for keywords.

-------------
John Thingstad

Thanks John. I was not talking about a symbol-value.

Finally I found a way to fix iterate so that symbol-function is not
required to bind. Only property lists of several keywords are altered.
This patch allows co-existance of iterate with such macros as for,
collecting, etc. which can be found in misc libraries. No import from
iterate package (except iter:iter maybe) is required now to make
iterate work peacefully in any package.
If someone is interested, I might publish it.

Definitely, iterate can be altered more deeply to avoid putting even a
properties on a :keyword, but I'm too lazy to do that.

I think no-one would ever use a property list of keyword, and if one
would, he would put/get one's own properties, not that defined by
iterate package. So, property conflict seem to be unlikely.

Though this seem to be a bit messy... I didn't expect CL allows any
bindings to a constants, but it does.

budden <budden01@mtu-net.ru> writes:

> > (setf (get :const rop) :val)

If rop is a global property of :const, then why not. But most
probably it's something that concerns only your program, so you should
put the property in your own package:

(defpackage "MY-PROPERTIES" (:export "PROP"))

then it's would be ok to do:

(setf (get :const 'MY-PROPERTIES:PROP) :val)

since it would not imply any collision with other libraries and
programs in the same image.

However, it would still imply a time impact, since property lists are
scanned linearly. How happy would you be if all the property lists
you use are thousands of elements long just because all libraries had
put their data there?

So it would still be better to use your own symbols:

(defpackage "MY-SYMBOL" (:export "CONST"))

In that case, you can use a keyword as key for the property:

(setf (get MY-SYMBOL:CONST rop) :val)



> Additionally, is it ok to
> (defun :foo () 1)
> This works in those three cl implementation and I found nothing in a
> standard which would forbid that.

In this case, technically it's indeed possible to fbind a keyword, but
it is a global namespace so if it was often done, any library could
override your function :foo with their own. Better to use your own
symbols to name functions.


> It is required for allow iterate special clauses like "finally" to be
> keywords too.

You should find a better way.


--
__Pascal Bourguignon__

På Mon, 03 Nov 2008 13:58:43 +0100, skrev budden <budden01@mtu-net.ru>:

> Thanks John. I was not talking about a symbol-value.
>
> Finally I found a way to fix iterate so that symbol-function is not
> required to bind. Only property lists of several keywords are altered.
> This patch allows co-existance of iterate with such macros as for,
> collecting, etc. which can be found in misc libraries. No import from
> iterate package (except iter:iter maybe) is required now to make
> iterate work peacefully in any package.
> If someone is interested, I might publish it.
>
> Definitely, iterate can be altered more deeply to avoid putting even a
> properties on a :keyword, but I'm too lazy to do that.
>
> I think no-one would ever use a property list of keyword, and if one
> would, he would put/get one's own properties, not that defined by
> iterate package. So, property conflict seem to be unlikely.
>
> Though this seem to be a bit messy... I didn't expect CL allows any
> bindings to a constants, but it does.

I think you missed my point completely. I thought you knew how keywords
worked, but apparently you don't.
I can try to explain what I meant. When you enter :name it is captured by
the reader. The reader translates that to something like (intern "name"
"KEYWORD").
KEYWORD is a separate package. Intern means if it doesn't exist a symbol
is created, otherwise the pointer to the existing one is returned. So each
symbol with a : is front of it gets allocated in the keyword package. This
is convenient as you need a place to store then. Byound that look up
SYMBOL. (apropos "SYMBOL") You have symbol-name, symbol-function,
symbol-variable, symbol-plist and others. When you write (defun :foo
(...)) it translates to something along the lines as
(setf (symbol-function (intern "FOO" "KEYWORD)) (compile '(...)))
I hope in ligt of this my previous post makes more sense.

--------------
John Thingstad

John, I think I understood well what you said. No need to explain how
lisp works. I know it rather well. The question was more about style/
caveats/portability.

I don't like to make any bindings to keywords too, but iterate
( http://common-lisp.net/project/iterate/doc/
) uses "clause indexing" which makes it is not so easy to modify it.
Whan defining a synonym for iterate clause, iterate adds a property to
a symbol. Iterate is a common use utility. I don't want to
write
(iter:iter (iter:for i in '(1 2 3)) (iter:collecting x))


But when I try to (use-package :iterate), it conflicts with, say, cl-
utilities.
The best way to avoid a conflict seem to make keywords behave as a
heads of
iterate clauses:

(iter:iter (:for i :in '(1 2 3)) (:collecting i))
vs loopy
(loop :for i :in '(1 2 3) :collect i)

And now I have that done with an expence of:
i) modifying couple lines in iterate
ii) putting a property 'iter::synonym to that
keywords :for , :collecting, etc.
It is not good to add even a properties to constants (I know it), but
for me it is an acceptable price for that convinience.

On Mon, 03 Nov 2008 13:08:47 -0800, budden wrote:

> But when I try to (use-package :iterate), it conflicts with, say, cl-
> utilities.

(defpackage my-lisp-project
(:use :common-lisp :iter :cl-utilities)
(:shadowing-import-from :iterate :collecting :collect))

You get the idea.

HTH,

Tamas

> (defpackage my-lisp-project
> * (:use :common-lisp :iter :cl-utilities)
> * (:shadowing-import-from :iterate :collecting :collect))

I first faced to this problem while playing to Symbolicweb. This
package was previously like this:

(defpackage symbolicweb
(:use :common-lisp :cl-utilities)
or maybe
(:import-from :cl-utilities :collecting))

To fix that, I'd need either modify all Lars's code. I.e., change
`collecting' to `cl-utilities:collecting' everywhere and so on. It was
impossible, of course for me as a new developer with very limited
"responsibility area". Making new, second package for me was not an
option too. Currently I'm not participating in Symbolicweb, and Lars
ain't using iterate still. Would he like to have this inconvinience?

What goes to style, loop uses :keywords, iterate is promoted as a
substitute for loop. Why should iterate be less convinient than loop?

On Mon, 03 Nov 2008 14:18:19 -0800, budden wrote:

>> (defpackage my-lisp-project
>> Â* (:use :common-lisp :iter :cl-utilities) (:shadowing-import-from
>> Â* :iterate :collecting :collect))
>
> I first faced to this problem while playing to Symbolicweb. This package
> was previously like this:
>
> (defpackage symbolicweb
> (:use :common-lisp :cl-utilities)
> or maybe
> (:import-from :cl-utilities :collecting))

I am baffled by what you are trying to do or what your problems are.
What does "playing to Symbolicweb" mean? If you are experimenting with
something, define your own package, import what you need, and resolve
conflicts to your liking.

> To fix that, I'd need either modify all Lars's code. I.e., change
> `collecting' to `cl-utilities:collecting' everywhere and so on. It was

I never had to modify anyone's packages because of symbol name clashes.
Either your import them or you don't, in the latter case if symbols
clash, you shadow some of them, end of the story.

> "responsibility area". Making new, second package for me was not an
> option too.

Why not?

> What goes to style, loop uses :keywords, iterate is promoted as a
> substitute for loop. Why should iterate be less convinient than loop?

Iterate is very convenient to use. You just don't grok packages. Please

1) read the appropriate chapter in PCL,
2) if you still don't get it, give up on Lisp. Seriously. It will save
a lot of frustration for you in the long run.

HTH,

Tamas