From: Ray Dillinger
Subject: How do I use the read-table to collapse symbol-table references?
Date:
Message-ID: <4069C0C9.3AD2B799@sonic.net>
Is there any way I can key on the '%' character to use the readtable
to transform
foo%bar
in source into
(get 'foo 'bar)
in data structure?
I'd also like to collapse
foo%bar%<datum>
in source into
(setf (get 'foo 'bar) <datum>)
in data structure.
Just looking for a way to make property-list references more concise.
Am I missing something about the readtable, or do I have to use a
prefix character before 'foo'? ie, as
%foo%bar
and
%foo%bar%<datum>
it looks like there's a straightforward way to do this.
Bear
In article <·················@sonic.net>,
Ray Dillinger <····@sonic.net> wrote:
> Just looking for a way to make property-list references more concise.
> Am I missing something about the readtable, or do I have to use a
> prefix character before 'foo'? ie, as
>
> %foo%bar
> and
> %foo%bar%<datum>
>
> it looks like there's a straightforward way to do this.
Yes, reader macros only work as prefixes. There's no way for a macro
character to get at the stuff that preceded it and change how it was
parsed. Any parts of the lexical syntax that work like this (e.g. the
':' package indicator) are built into the reader or use
implementation-dependent features; they can't be implemented using the
standard reader macro mechanism.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Ray Dillinger wrote:
> Just looking for a way to make property-list references more concise.
> Am I missing something about the readtable, or do I have to use a
> prefix character before 'foo'? ie, as
>
> %foo%bar
> and
> %foo%bar%<datum>
>
> it looks like there's a straightforward way to do this.
You can also change the read macro for #\f. ;)
(I am only half-joking.)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Ray Dillinger <····@sonic.net> wrote in message news:<·················@sonic.net>...
> Just looking for a way to make property-list references more concise.
> Am I missing something about the readtable, or do I have to use a
> prefix character before 'foo'? ie, as
>
> %foo%bar
> and
> %foo%bar%<datum>
>
> it looks like there's a straightforward way to do this.
Here is one more idea. Don't use the reader at all, but change the
syntax to:
(foo % bar ...)
then use your Lisp system's *MACROEXPAND-HOOK* extension, if it has
one, to recognize all forms that have the % symbol in their second
position, and transliterate them to (% foo ...). Then have a % macro
do the rest of the job.
But really, what advantage then remains to the infix? You might as
well accept:
(% foo bar ...)
Using the reader you could make that into
%(foo bar ...)
which buys you nothing.
All these forms are still pretty concise compared to the property
access and manipulation expressions that they represent, off by only
one to two characters from your desired syntax.
From: Ray Dillinger
Subject: Re: How do I use the read-table to collapse symbol-table references?
Date:
Message-ID: <406B6409.D486A132@sonic.net>
Well, I had a somewhat broader agenda really.
What's the difference, really, between closures, objects, namespaces,
the package system, records, and property lists?
Think about it....
Answer: Nothing.
There's not really any semantic difference; all of them represent
a fundamental idea of sticking named values into hierarchies.
From a language design point of view, really, I don't think
there's a good reason to be using more than one construct here.
It just needs a good implementation that's not O(n).
So what I really wanted to do was to unify the
packagename:variable
and the
(get packagename 'variable)
and the
(rectype-variable packagename)
etc, syntaxes,
going with a most-succinct form that uses just an infix character to
denote a hierarchically dependent value.
I guess I'm just having an "elegance attack", because I see all these
redundant things and I'm wondering why burden people with learning all
those instead of just using one good implementation of one simple
idea?
Bear
In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
> Well, I had a somewhat broader agenda really.
>
> What's the difference, really, between closures, objects, namespaces,
> the package system, records, and property lists?
>
> Think about it....
>
> Answer: Nothing.
Not so. The package system does what it does at read-time. Closures do
what they do at compile time. And property lists work at run time. This
has real semantic consequences.
Notwithstanding all that, I sympathize with your agenda. In fact, I
recently wrote myself a read macro that lets me write:
@·······@baz --> (ref (ref foo 'bar) baz)
where ref is a generic function that subsumes a great many things,
including slot-value, aref, elt, nth, gethash, assoc, and getf. It would
be really nice to get rid of the leading @, e.g. if there were a
*token-processing-hook* or some such thing. It would also be nice to have
an *illegal-form-hook* that the user could intercept to do something with
((foo) ...) other than generate an error. I've actually implemented this
last one as an implementation hack in MCL (turns out to be very simple to
do), but of course this results in highly non-portable code.
E.
"Erann Gat" <·········@flownet.com> wrote in message
·······························@192.168.1.52...
> Notwithstanding all that, I sympathize with your agenda. In fact, I
> recently wrote myself a read macro that lets me write:
>
> @·······@baz --> (ref (ref foo 'bar) baz)
>
> where ref is a generic function that subsumes a great many things,
> including slot-value, aref, elt, nth, gethash, assoc, and getf. It would
> be really nice to get rid of the leading @, e.g. if there were a
> *token-processing-hook* or some such thing. It would also be nice to have
> an *illegal-form-hook* that the user could intercept to do something with
> ((foo) ...) other than generate an error. I've actually implemented this
> last one as an implementation hack in MCL (turns out to be very simple to
> do), but of course this results in highly non-portable code.
So, then, how hard is it to replace the CL Reader?
Can you create a CL-ERRAN package that shadows READ and, I guess, LOAD? Are
there any other functions that you'd need to replace?
It would be nice to not have to replace the entire reader and, rather,
supplement it, but, it's possible, and even portable though the build
environment may be more tricky than others.
But if the GattReader is essentially the same as the CLReader, with a few
more hooks, perhaps others will enjoy that capability enough to make it
their default reader.
Regards,
Will Hartung
(·····@msoft.com)
In article <···············@ID-197644.news.uni-berlin.de>, "Will Hartung"
<·····@msoft.com> wrote:
> "Erann Gat" <·········@flownet.com> wrote in message
> ·······························@192.168.1.52...
> > Notwithstanding all that, I sympathize with your agenda. In fact, I
> > recently wrote myself a read macro that lets me write:
> >
> > @·······@baz --> (ref (ref foo 'bar) baz)
> >
> > where ref is a generic function that subsumes a great many things,
> > including slot-value, aref, elt, nth, gethash, assoc, and getf. It would
> > be really nice to get rid of the leading @, e.g. if there were a
> > *token-processing-hook* or some such thing. It would also be nice to have
> > an *illegal-form-hook* that the user could intercept to do something with
> > ((foo) ...) other than generate an error. I've actually implemented this
> > last one as an implementation hack in MCL (turns out to be very simple to
> > do), but of course this results in highly non-portable code.
>
> So, then, how hard is it to replace the CL Reader?
Pretty hard actually. See section 11.1.2.1.2 of the spec.
> Can you create a CL-ERRAN package that shadows READ and, I guess, LOAD?
Yes, of course, but the REPL will still use CL:READ.
I think it would be easier to just make a read-table with a read macro for
every constituent character.
> It would be nice to not have to replace the entire reader and, rather,
> supplement it, but, it's possible, and even portable though the build
> environment may be more tricky than others.
>
> But if the GattReader is essentially the same as the CLReader, with a few
> more hooks, perhaps others will enjoy that capability enough to make it
> their default reader.
Perhaps. It's not very hard to write such a reader, but it is hard to
write it in a portable way because a lot of the functionality of the
reader (like token parsing) would need to be reproduced. Likewise, it's
not very hard to hack a particular implementation (at least when that
implementation is MCL) to support ((foo) ...) syntax, but doing it
portably requires a code walker.
E.
From: John Thingstad
Subject: Re: How do I use the read-table to collapse symbol-table references?
Date:
Message-ID: <opr5q5tdusxfnb1n@news.chello.no>
There is a big difference between object orientation and modularization.
One of the issues (more important in static lanuages) is polymorhism.
You wish to enforce all objects of some "class" to have a standard
behaviour.
This is difficult to enforce with closures (or some other mechansm.)
Comparing packages (controlling namespace clutter) and classes
(hiraricical classification of information) to me seems like comparing
apples and oranges.
That being said I belive object orientation is overused.
In particular going the way of java or smalltalk by forcing everything
to be a class is silly. Consider this
class nonsense
{
public static void main ()
{
// code ...
}
};
Immidiately the abstraction is broken.
Simularly functional inheritance (as in most windows libraries) has
nothing to do with object orientation.
I find the best discussion of this to be in "Object oriened analysis" by
Code/Yourdon.
Generally to find objects read a encyclopedia and undeline terminology and
isolate enteties. If you can "kick it" it's a class.
eg. Abstract class factory is not.
It is a flawed abstraction begging for a better design mechanism.
Norvig analyses Design batterns.. by Gamma et al ad finds that
16 out of 22 of the design patterns in this book has better representated
by
non oop abstractions in lisp.
Many times I find that design patterns are a futile attemt to force a
square
peg into a round hole.
I have never found a good reason to design a compiler object oriented for
example.
(functional is best)
A windows with subtrees are most naturally organized into a hirarcy of
classes.
(I wish someone would do it well. I have never seen a graphics context for
example.
Color and Pen however are abstractions i know.)
A good language for comparing modules and classes is python with has
reduced the
concept to bare bones. Here I find the differences in use and scope stand
out more clearly.
On Wed, 31 Mar 2004 23:14:13 GMT, Ray Dillinger <····@sonic.net> wrote:
>
> Well, I had a somewhat broader agenda really.
>
> What's the difference, really, between closures, objects, namespaces,
> the package system, records, and property lists?
>
> Think about it....
>
> Answer: Nothing.
>
> There's not really any semantic difference; all of them represent
> a fundamental idea of sticking named values into hierarchies.
>
> From a language design point of view, really, I don't think
> there's a good reason to be using more than one construct here.
> It just needs a good implementation that's not O(n).
>
> So what I really wanted to do was to unify the
>
> packagename:variable
>
> and the
>
> (get packagename 'variable)
>
> and the
>
> (rectype-variable packagename)
>
> etc, syntaxes,
>
> going with a most-succinct form that uses just an infix character to
> denote a hierarchically dependent value.
>
> I guess I'm just having an "elegance attack", because I see all these
> redundant things and I'm wondering why burden people with learning all
> those instead of just using one good implementation of one simple
> idea?
>
> Bear
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/