Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
announce: def-symbol-readmacro
94 views
Skip to first unread message
budden
Mar 13, 2012, 5:22:41 AM3/13/12
to
Hi people!
This topic was discussed some years ago. Currently I put my library at
google code. Some docs are outdated, many comments are in Russian. But
this library can do what many of you dreamed of:
- local package nicknames. Call package by short name and don't be
afraid of conflicts
- automatic and safe duplicate symbols resolution. When you define new
package with my library, conflicting symbols from used packages do not
break execution. Their names become forbidden in new package by
default. You just can't read them through the reader. You can
overwrite the default and use either of conflicting symbols. You can
also explicitly declare some symbol names as forbidden - useful to
combat trash symbols.
- symbol-readmacros. Now you can attach special reader functions to
symbols. So, you can have foo:[ ... ] and bar:[ ... ] special readers
with different sence and with no conflicts.
- named-readtables are included - address your readtables by their
name
- iterate-keyworks - use keywords in iterate (iter (:for ...)
(:collect ...)) - useful to avoid symbol names conflicts.
- and some more
Library used to pass tests in Allegro, CCL, CLISP, Lispworks, SBCL.
Tasks are:
- testing
- SLIME integration to make completion work via package aliases
- simplification and removal of redundant dependencies
- translation of docstrings
http://code.google.com/p/def-symbol-readmacro/
I'd like to thank all the people here who discussed various issues
related to the development of the library.
This topic was discussed some years ago. Currently I put my library at
google code. Some docs are outdated, many comments are in Russian. But
this library can do what many of you dreamed of:
- local package nicknames. Call package by short name and don't be
afraid of conflicts
- automatic and safe duplicate symbols resolution. When you define new
package with my library, conflicting symbols from used packages do not
break execution. Their names become forbidden in new package by
default. You just can't read them through the reader. You can
overwrite the default and use either of conflicting symbols. You can
also explicitly declare some symbol names as forbidden - useful to
combat trash symbols.
- symbol-readmacros. Now you can attach special reader functions to
symbols. So, you can have foo:[ ... ] and bar:[ ... ] special readers
with different sence and with no conflicts.
- named-readtables are included - address your readtables by their
name
- iterate-keyworks - use keywords in iterate (iter (:for ...)
(:collect ...)) - useful to avoid symbol names conflicts.
- and some more
Library used to pass tests in Allegro, CCL, CLISP, Lispworks, SBCL.
Tasks are:
- testing
- SLIME integration to make completion work via package aliases
- simplification and removal of redundant dependencies
- translation of docstrings
http://code.google.com/p/def-symbol-readmacro/
I'd like to thank all the people here who discussed various issues
related to the development of the library.
budden
Mar 13, 2012, 12:01:19 PM3/13/12
to
P.S. Code is rather mature, and there is a test suite. Some time ago
reader was able to load rather large set of libraries into SBCL.
For a last couple of years, it was mostly tested, developed and used
with
Lispworks 4.4 only. There may be obsolete, disappered or altered
libraries
in dependencies. It is very likely that I use altered version of
toposort,
so you might have troubles installing and building the library.
I'm looking for volunteers for testing and improving its state.
I'd also like to thank Tim Bradshaw and Tobias C. Rittweiler as my
library is built on top of hierarchical package and named readtables.
reader was able to load rather large set of libraries into SBCL.
For a last couple of years, it was mostly tested, developed and used
with
Lispworks 4.4 only. There may be obsolete, disappered or altered
libraries
in dependencies. It is very likely that I use altered version of
toposort,
so you might have troubles installing and building the library.
I'm looking for volunteers for testing and improving its state.
I'd also like to thank Tim Bradshaw and Tobias C. Rittweiler as my
library is built on top of hierarchical package and named readtables.
D Herring
Mar 13, 2012, 6:34:49 PM3/13/12
to
On 03/13/2012 05:22 AM, budden wrote:
> This topic was discussed some years ago. Currently I put my library at
> google code. Some docs are outdated, many comments are in Russian. But
> this library can do what many of you dreamed of:
Glad you followed through with this. Several times, I've been thought
> This topic was discussed some years ago. Currently I put my library at
> google code. Some docs are outdated, many comments are in Russian. But
> this library can do what many of you dreamed of:
of digging up those old posts, but always found an excuse to do
something a else.
I'll have to take a look at the new stuff.
- Daniel
RG
Mar 13, 2012, 8:52:24 PM3/13/12
to
In article
<7fe9f05f-61cd-4ec2...@p7g2000yqk.googlegroups.com>,
Wow, so much code.
Here's a lighter weight version:
http://www.flownet.com/ron/lisp/symbol-reader-macros.lisp
rg
<7fe9f05f-61cd-4ec2...@p7g2000yqk.googlegroups.com>,
Here's a lighter weight version:
http://www.flownet.com/ron/lisp/symbol-reader-macros.lisp
rg
budden
Mar 14, 2012, 6:28:52 PM3/14/12
to
Hi Daniel
managed to build this library with SBCL yesterday. There's many things
to bring
into order before it can be really useful, but these are mostly
missing English docs, removing some dead code, giving more
consistent names to things etc. I believe the core of library
is pretty healthy.
> I'll have to take a look at the new stuff.
That's nice! I'd like to have a feedback. One person here in Russia
managed to build this library with SBCL yesterday. There's many things
to bring
into order before it can be really useful, but these are mostly
missing English docs, removing some dead code, giving more
consistent names to things etc. I believe the core of library
is pretty healthy.
budden
Mar 14, 2012, 6:35:25 PM3/14/12
to
Hi Ron!
> http://www.flownet.com/ron/lisp/symbol-reader-macros.lisp
I remember this and you can even find a copy of your code in my repo.
But mine, at least, allows for assigning several distinct
meanings to [],{} which can be interpreted as symbols, e.g.
foo:[ runs readmacro from (intern "[" :foo)
bar:[ runs readmacro from (intern "[" :bar)
And you can import either of foo:[ or bar:[ to your package.
> http://www.flownet.com/ron/lisp/symbol-reader-macros.lisp
I remember this and you can even find a copy of your code in my repo.
But mine, at least, allows for assigning several distinct
meanings to [],{} which can be interpreted as symbols, e.g.
foo:[ runs readmacro from (intern "[" :foo)
bar:[ runs readmacro from (intern "[" :bar)
And you can import either of foo:[ or bar:[ to your package.
Kaz Kylheku
Mar 14, 2012, 6:58:21 PM3/14/12
to
On 2012-03-14, budden <budde...@mail.ru> wrote:
> Hi Ron!
>> http://www.flownet.com/ron/lisp/symbol-reader-macros.lisp
> I remember this and you can even find a copy of your code in my repo.
Looks like some symboltons are getting together, to exchange their
> Hi Ron!
>> http://www.flownet.com/ron/lisp/symbol-reader-macros.lisp
> I remember this and you can even find a copy of your code in my repo.
symbol-minded opinions on some symblistic code.
:)
RG
Mar 14, 2012, 8:25:45 PM3/14/12
to
In article
<bfba2f65-8aca-471e...@n19g2000yqk.googlegroups.com>,
You can do that with mine too:
? (require :symbol-reader-macros)
:SYMBOL-READER-MACROS
NIL
? (make-package :p1)
#<Package "P1">
? (make-package :p2)
#<Package "P2">
? (set-macro-symbol 'p1::foo (lambda (stream symbol) (cons symbol 'p1)))
T
? (set-macro-symbol 'p2::foo (lambda (stream symbol) (cons symbol 'p2)))
T
? (in-readtable symbol-reader-macros)
NIL
? (import 'p1::foo)
T
? 'Foo
(FOO . P1)
? (shadowing-import 'p2::foo)
T
? 'Foo
(FOO . P2)
<bfba2f65-8aca-471e...@n19g2000yqk.googlegroups.com>,
? (require :symbol-reader-macros)
:SYMBOL-READER-MACROS
NIL
? (make-package :p1)
#<Package "P1">
? (make-package :p2)
#<Package "P2">
? (set-macro-symbol 'p1::foo (lambda (stream symbol) (cons symbol 'p1)))
T
? (set-macro-symbol 'p2::foo (lambda (stream symbol) (cons symbol 'p2)))
T
? (in-readtable symbol-reader-macros)
NIL
? (import 'p1::foo)
T
? 'Foo
(FOO . P1)
? (shadowing-import 'p2::foo)
T
? 'Foo
(FOO . P2)
RG
Mar 14, 2012, 9:57:45 PM3/14/12
to
In article <rNOSPAMon-902B2...@news.albasani.net>,
Actually don't need to muck with all the importing:
? (unintern 'foo)
T
? 'P1::foo
(P1::FOO . P1)
? 'P2::foo
(P2::FOO . P2)
?
rg
? (unintern 'foo)
T
? 'P1::foo
(P1::FOO . P1)
? 'P2::foo
(P2::FOO . P2)
?
rg
RG
Mar 14, 2012, 10:04:14 PM3/14/12
to
In article <rNOSPAMon-98333...@news.albasani.net>,
Oh, note that there's also a Lisp-1 hack in there:
? (setf x (lambda () 123))
#<Anonymous Function #x302000E1B88F>
? (X)
; Warning: X is not defined as a function, using value instead.
; While executing: (:INTERNAL SYMBOL-READER-MACRO-READER), in process
Listener(7).
123
?
:-)
(NOTE: There was a bug in this part of the code. I've just uploaded a
fix.)
rg
? (setf x (lambda () 123))
#<Anonymous Function #x302000E1B88F>
? (X)
; Warning: X is not defined as a function, using value instead.
; While executing: (:INTERNAL SYMBOL-READER-MACRO-READER), in process
Listener(7).
123
?
:-)
(NOTE: There was a bug in this part of the code. I've just uploaded a
fix.)
rg
budden
Mar 15, 2012, 6:25:49 AM3/15/12
to
> You can do that with mine too...
Yes, you can do
p1::foo and p2::foo,
but you can't do that for "["
as you recognize only capital alpha
characters at the beginning of a macro.
This seem to be very convinient to write something like:
(import (find-symbol "[" :sql))
[ select * from foo] ; sql::|[| readmacro
html::[ <body>....</body>]; html::|[| readmacro
etc.
You can change this easily though if you add your macro-character for #
\[
On the other hand, my lib allows for portable local package nicknames:
BUDDEN> (def-merge-packages::!4 :p (:local-nicknames :a :alexandria))
#<PACKAGE P>
BUDDEN> (in-package :p)
#<PACKAGE P>
P> describe 'a:appendf
....
One need to dive deeper into reader internals to make this work.
Yes, you can do
p1::foo and p2::foo,
but you can't do that for "["
as you recognize only capital alpha
characters at the beginning of a macro.
This seem to be very convinient to write something like:
(import (find-symbol "[" :sql))
[ select * from foo] ; sql::|[| readmacro
html::[ <body>....</body>]; html::|[| readmacro
etc.
You can change this easily though if you add your macro-character for #
\[
On the other hand, my lib allows for portable local package nicknames:
BUDDEN> (def-merge-packages::!4 :p (:local-nicknames :a :alexandria))
#<PACKAGE P>
BUDDEN> (in-package :p)
#<PACKAGE P>
P> describe 'a:appendf
....
One need to dive deeper into reader internals to make this work.
RG
Mar 15, 2012, 12:54:54 PM3/15/12
to
In article
<4cc48408-0955-432b...@fk28g2000vbb.googlegroups.com>,
letters is an easily changed designed decision. Personally, I think
it's a good idea to have a visual distinction between strings that are
guaranteed to read as symbols and those that aren't. But if you
disagree you can just do something like this:
(defun set-macro-symbol (symbol readfn)
(setf (get symbol 'symbol-reader-macro) readfn)
(set-macro-character (char (symbol-name symbol) 0)
'symbol-reader-macro-reader t
(find-readtable 'symbol-reader-macros))
t)
rg
<4cc48408-0955-432b...@fk28g2000vbb.googlegroups.com>,
budden <budde...@mail.ru> wrote:
> > You can do that with mine too...
> Yes, you can do
> p1::foo and p2::foo,
> but you can't do that for "["
> as you recognize only capital alpha
> characters at the beginning of a macro.
>
> This seem to be very convinient to write something like:
> (import (find-symbol "[" :sql))
> [ select * from foo] ; sql::|[| readmacro
> html::[ <body>....</body>]; html::|[| readmacro
> etc.
>
> You can change this easily though if you add your macro-character for #
> \[
Restricting symbol reader macros to symbol names starting with capital
> > You can do that with mine too...
> Yes, you can do
> p1::foo and p2::foo,
> but you can't do that for "["
> as you recognize only capital alpha
> characters at the beginning of a macro.
>
> This seem to be very convinient to write something like:
> (import (find-symbol "[" :sql))
> [ select * from foo] ; sql::|[| readmacro
> html::[ <body>....</body>]; html::|[| readmacro
> etc.
>
> You can change this easily though if you add your macro-character for #
> \[
letters is an easily changed designed decision. Personally, I think
it's a good idea to have a visual distinction between strings that are
guaranteed to read as symbols and those that aren't. But if you
disagree you can just do something like this:
(defun set-macro-symbol (symbol readfn)
(setf (get symbol 'symbol-reader-macro) readfn)
(set-macro-character (char (symbol-name symbol) 0)
'symbol-reader-macro-reader t
(find-readtable 'symbol-reader-macros))
t)
rg
budden
Mar 20, 2012, 5:42:07 AM3/20/12
to
Hi Ron, List!
> Restricting symbol reader macros to symbol names starting with capital
> letters is an easily changed designed decision.
Yes, I agree that you give a sufficient solution to macro-character
scalability problem.
But, as I said before, mine also intercepts all attempts to read a
symbol, so it
has additional capabilities.
I think that either yours or mine code or approach should become
popular and using
symbol-readmacros should become a good style for library writers. I
like
mine better, but it seems that not many other lisp people appreciate
either of them.
It'd be fine to promote either style and I do what I can for that.
I think our topic is likely to be exhausted at the point
:-)
> Restricting symbol reader macros to symbol names starting with capital
> letters is an easily changed designed decision.
scalability problem.
But, as I said before, mine also intercepts all attempts to read a
symbol, so it
has additional capabilities.
I think that either yours or mine code or approach should become
popular and using
symbol-readmacros should become a good style for library writers. I
like
mine better, but it seems that not many other lisp people appreciate
either of them.
It'd be fine to promote either style and I do what I can for that.
I think our topic is likely to be exhausted at the point
:-)
RG
Mar 20, 2012, 2:15:22 PM3/20/12
to
In article
<a2e83ef8-64c8-4669...@gr6g2000vbb.googlegroups.com>,
Aww, just when we were starting to have fun ;-)
rg
<a2e83ef8-64c8-4669...@gr6g2000vbb.googlegroups.com>,
rg
0 new messages