What is the cannonical method of "exporting" read macro characters from
packages?
Just stick the (set-macro-character ... ) bit at the end and let the
user figure out the character changed, or maybe export the function and
let the user decide whether or not they want to modify their read
table?
Thanks!
Tel A. wrote:
> What is the cannonical method of "exporting" read macro characters from
> packages?
>
> Just stick the (set-macro-character ... ) bit at the end and let the
> user figure out the character changed, or maybe export the function and
> let the user decide whether or not they want to modify their read
> table?
I don't have the impression that changing the read table occurs so often
that there is a "canonical" approach for this. My guess would be that
exporting the read macro function, or maybe a function that performs the
modification of the read table, is better because it avoids surprises.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
On Sun, 4 Jun 2006, Pascal Costanza wrote:
> Tel A. wrote:
>> What is the cannonical method of "exporting" read macro characters from
>> packages?
>>
> I don't have the impression that changing the read table occurs so often that
> there is a "canonical" approach for this. My guess would be that exporting
> the read macro function, or maybe a function that performs the modification
> of the read table, is better because it avoids surprises.
The latter is at least what CLSQL does for its sql syntax. It exports
functions enable-sql-reader-syntax, disable-sql-reader-syntax, and a
couple of other related functions. See the documentation for more
information on these and their "local" counterparts.
-Mikko
Mikko Heikelä wrote:
> On Sun, 4 Jun 2006, Pascal Costanza wrote:
> > Tel A. wrote:
> >> What is the cannonical method of "exporting" read macro characters from
> >> packages?
> >>
> > I don't have the impression that changing the read table occurs so often that
> > there is a "canonical" approach for this. My guess would be that exporting
> > the read macro function, or maybe a function that performs the modification
> > of the read table, is better because it avoids surprises.
>
> The latter is at least what CLSQL does for its sql syntax. It exports
> functions enable-sql-reader-syntax, disable-sql-reader-syntax, and a
> couple of other related functions. See the documentation for more
> information on these and their "local" counterparts.
>
> -Mikko
That's what I was leaning towards as well. I would expect that users
would want to explicitly have control to modify the read table. I just
wondered if perhaps the import itself was considered explicit enough.
Thank you
+ "Tel A." <············@gmail.com>:
| That's what I was leaning towards as well. I would expect that users
| would want to explicitly have control to modify the read table.
Indeed, and if you consider the ASDF world, the loading of your
package may not be the direct result of the user loading it, but
rather the indirect result of some other package requiring it. And
then an altered readtable might mess things up for a third package
that is being loaded after yours.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen <······@math.ntnu.no> wrote:
+---------------
| Indeed, and if you consider the ASDF world, the loading of your
| package may not be the direct result of the user loading it, but
| rather the indirect result of some other package requiring it. And
| then an altered readtable might mess things up for a third package
| that is being loaded after yours.
+---------------
As "R. Mattes" pointed out in another branch, what you're calling
"package" is really "module" or even just "file", yes? Not a CL
PACKAGE per se, right?
Anyway, one of the things one can do is make use of the fact that
both LOAD & COMPILE-FILE bind *READTABLE*... and thus restore it!
So putting this at the top of a file will confine the effects to
that file alone:
(eval-when (:compile-toplevel :load_toplevel :execute)
(setf *readtable* (copy-readtable))
(setf (readtable-case *readtable* :whatever))
(set-syntax-from-char ...whatever...)
(set-dispatch-macro-character ...whatever...)
...etc...)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
+ ····@rpw3.org (Rob Warnock):
| Harald Hanche-Olsen <······@math.ntnu.no> wrote:
| +---------------
| | Indeed, and if you consider the ASDF world, the loading of your
| | package may not be the direct result of the user loading it, but
| | rather the indirect result of some other package requiring it. And
| | then an altered readtable might mess things up for a third package
| | that is being loaded after yours.
| +---------------
|
| As "R. Mattes" pointed out in another branch, what you're calling
| "package" is really "module" or even just "file", yes? Not a CL
| PACKAGE per se, right?
Absolutely right. I was aware of the confused terminology, but chose
(perhaps foolishly) to not correct it.
| Anyway, one of the things one can do is make use of the fact that
| both LOAD & COMPILE-FILE bind *READTABLE*... and thus restore it!
Indeed. But if I understood the OP right, he wanted the loaded file
to change the reader syntax for the user's later benefit. And that
change, IMO, should be left to the user to do at the appropriate time.
Just supply the function to do it with.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
On Sun, 04 Jun 2006 12:01:14 -0700, Tel A. wrote:
>
> Mikko Heikel� wrote:
>> On Sun, 4 Jun 2006, Pascal Costanza wrote:
>> > Tel A. wrote:
>> >> What is the cannonical method of "exporting" read macro characters from
>> >> packages?
>> >>
>> > I don't have the impression that changing the read table occurs so often that
>> > there is a "canonical" approach for this. My guess would be that exporting
>> > the read macro function, or maybe a function that performs the modification
>> > of the read table, is better because it avoids surprises.
>>
>> The latter is at least what CLSQL does for its sql syntax. It exports
>> functions enable-sql-reader-syntax, disable-sql-reader-syntax, and a
>> couple of other related functions. See the documentation for more
>> information on these and their "local" counterparts.
>>
>> -Mikko
>
> That's what I was leaning towards as well. I would expect that users
> would want to explicitly have control to modify the read table. I just
> wondered if perhaps the import itself was considered explicit enough.
There seems to be a small missunderstang here: CL packages are about
_names_. One doesn't (and can't) export functions/readtables/classes etc.
AFAIK there's no way to change the active readtable (i guess that's what
the OP means by "exporting read macro characters") by means of using a
package.
Cheers RalfD
> Thank you