Discussion:
How to implement property list
(too old to reply)
none) (albert
2020-09-09 07:50:38 UTC
Permalink
I finally understand that property lists are much more
essential to lisp than I thought. Also it seems that
different properties may not at all be related even if they
happen to apply to the same symbol.

A naive approach for implementation is :
- assuming a symbol has a token (probably a memory address or an index)
- assuming a property has a name.

1 Establish for each property a hash table of an appropriate length p.
2 Use the symbol's token as a hash, probably just index%p .

Would this simplistic approach work?

Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Zyni Moë
2020-09-09 11:24:21 UTC
Permalink
Post by none) (albert
I finally understand that property lists are much more
essential to lisp than I thought.
Don't think many modern impls, or programs, use plists very much.
Sometimes of course.
Post by none) (albert
- assuming a symbol has a token (probably a memory address or an index)
- assuming a property has a name.
1 Establish for each property a hash table of an appropriate length p.
2 Use the symbol's token as a hash, probably just index%p .
Would this simplistic approach work?
No. Need to be able to have duplicate keys so can shadow older ones. If
you want property lists use property *lists*.
--
the small snake
His Kennyness
2020-09-09 11:38:40 UTC
Permalink
Post by Zyni Moë
Post by none) (albert
I finally understand that property lists are much more
essential to lisp than I thought.
Don't think many modern impls, or programs, use plists very much.
Sometimes of course.
Post by none) (albert
- assuming a symbol has a token (probably a memory address or an index)
- assuming a property has a name.
1 Establish for each property a hash table of an appropriate length p.
2 Use the symbol's token as a hash, probably just index%p .
Would this simplistic approach work?
No. Need to be able to have duplicate keys so can shadow older ones. If
you want property lists use property *lists*.
--
the small snake
I'll give a +1 on the small role of property lists in today's Lisp coding. Well, *my* coding.
none) (albert
2020-09-10 14:40:20 UTC
Permalink
Post by Zyni Moë
Post by none) (albert
I finally understand that property lists are much more
essential to lisp than I thought.
Don't think many modern impls, or programs, use plists very much.
Sometimes of course.
Post by none) (albert
- assuming a symbol has a token (probably a memory address or an index)
- assuming a property has a name.
1 Establish for each property a hash table of an appropriate length p.
2 Use the symbol's token as a hash, probably just index%p .
Would this simplistic approach work?
No. Need to be able to have duplicate keys so can shadow older ones. If
you want property lists use property *lists*.
That is hardly an argument. In Forth implementations the possibility of
redefinition is mandatory and hash tables are routinely used.
A Forth dictionary is a name-value set.
Post by Zyni Moë
--
the small snake
Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Zyni Moë
2020-09-10 14:59:04 UTC
Permalink
Post by none) (albert
That is hardly an argument. In Forth implementations the possibility of
redefinition is mandatory and hash tables are routinely used.
A Forth dictionary is a name-value set.
Is nothing to do with redefinition. Is to do with possibility of new
value shadowing (not replacing, shadowing) old one. Your suggested
implementation totally fails to do that, or to support disembodied property
lists). Sorry you do not understand this.
--
the small snake
none) (albert
2020-09-15 10:00:19 UTC
Permalink
Post by Zyni Moë
Post by none) (albert
That is hardly an argument. In Forth implementations the possibility of
redefinition is mandatory and hash tables are routinely used.
A Forth dictionary is a name-value set.
Is nothing to do with redefinition. Is to do with possibility of new
value shadowing (not replacing, shadowing) old one. Your suggested
implementation totally fails to do that, or to support disembodied property
lists). Sorry you do not understand this.
You may not understand Forth systems. I may not understand what you mean
by "shadowing".
In a Forth system I can redefine a word and it is henceforth
used with that meaning. Then I can remove that redefinition and the
old definition is again valid.
I naively thought that was what you mean by shadowing, but of course
that is just a term, and there may be more to it.
Post by Zyni Moë
--
the small snake
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
***@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
paul wallich
2020-09-15 13:47:25 UTC
Permalink
Post by none) (albert
Post by Zyni Moë
Post by none) (albert
That is hardly an argument. In Forth implementations the possibility of
redefinition is mandatory and hash tables are routinely used.
A Forth dictionary is a name-value set.
Is nothing to do with redefinition. Is to do with possibility of new
value shadowing (not replacing, shadowing) old one. Your suggested
implementation totally fails to do that, or to support disembodied property
lists). Sorry you do not understand this.
You may not understand Forth systems. I may not understand what you mean
by "shadowing".
In a Forth system I can redefine a word and it is henceforth
used with that meaning. Then I can remove that redefinition and the
old definition is again valid.
I naively thought that was what you mean by shadowing, but of course
that is just a term, and there may be more to it.
Shadowing is more akin to local variables. Multiple values can coexist,
and different ones apply in different scopes. (That's not exact, but the
best I can do in one sentence.) What you describe in Forth sounds more
globals. (Btw, I haven't kept up with Forth since the old, tiny days,
when dictionaries were mostly monolithic, so that removing the
definition of one word would also remove the definitions of words
defined after that one; sounds as if that characteristic, which was
useful in some ways, has been removed.)

paul
Paul Rubin
2020-09-16 01:15:25 UTC
Permalink
What you describe in Forth sounds more globals.
It's more like shallow binding, but with early rather than late binding.
Most things in Forth are designed to be implemented the simplest
possible way, even if that makes actual usage complicated.

Zyni Moë
2020-09-15 18:39:07 UTC
Permalink
Post by none) (albert
In a Forth system I can redefine a word and it is henceforth
used with that meaning. Then I can remove that redefinition and the
old definition is again valid.
Yes you can. *But you cannot in your suggested implementation* (still less
can you support disembodyd plists), which was point.
--
the small snake
Paul Rubin
2020-09-10 05:23:35 UTC
Permalink
Post by none) (albert
I finally understand that property lists are much more
essential to lisp than I thought.
Historically maybe true (pre-1980s, say) but not since then imho.

Normally you'd just put a plist cell in the symbol. The plist was a
linear list (PROPNAME VALUE PROPNAME VALUE ...). You wouldn't use a
hash for it and there were builtin functions to search those lists for a
given property. You also wouldn't use large numbers of properties.
They weren't a substitute for hashes, but rather a place where you could
stick particular data that you wanted to associate with the symbol.

I think early on, some plist entries were used for specific important
things, but I can't think of any offhand that CL uses.

Seriously if you're interested in programming in Lisp, there are decent
reasons to choose CL for that purpose. But if you're more interested in
studying it to know how it works rather than as a dev tool, you're
probably better off starting with Scheme and reading SICP.
Loading...