From: Adrian DOZSA
Subject: (read) problem with packages
Date: 
Message-ID: <1177272910.154507.47290@o5g2000hsb.googlegroups.com>
I have a little problem with the read function when packages are
involved:

CL-USER 1 > (read)
(foo:bar)
Error: No package named "FOO".
  1 (abort) Return to level 0.
  2 Return to top loop level 0.

The idea is that when i read a form it tries to check if the package
exists. How can i make it ignore if the package exists and only read
it (like for any function, it doesn't check if it exists).

From: Geoff Wozniak
Subject: Re: (read) problem with packages
Date: 
Message-ID: <1177301867.703317.228250@y5g2000hsa.googlegroups.com>
On Apr 22, 4:15 pm, Adrian DOZSA <·········@gmail.com> wrote:
> The idea is that when i read a form it tries to check if the package
> exists. How can i make it ignore if the package exists and only read
> it (like for any function, it doesn't check if it exists).

This is not at all easy.

The colon is considered to be a constituent character of a token.
Constituent characters have traits (CLHS, 2.1.4.2 Constituent
Traits).  The trait of the colon is "package marker."  The CLHS says:

"...no mechanism is provided for changing the constituent trait of a
character."

(See http://www.lispworks.com/documentation/HyperSpec/Body/02_adb.htm)

You'll have to do some serious changing of the reader for this to
work.

Depending on what you're doing, you may want to use read-line to get a
string and then substitute colon with another character that you can
define as a macro character to get the name of the symbol without the
package qualifier.  I used this technique when writing a quick and
dirty reader for CVS files.

-- Geoff
From: Tim Howe
Subject: Re: (read) problem with packages
Date: 
Message-ID: <87odlfg7sm.fsf@rash.quadium.net>
Adrian DOZSA <·········@gmail.com> writes:

> The idea is that when i read a form it tries to check if the package
> exists. How can i make it ignore if the package exists and only read
> it (like for any function, it doesn't check if it exists).

This isn't possible.  Symbols have a package.  If no package with the
name (or a nickname) specified exists, there is no way to represent that
symbol, short of automatically creating the package.  (If you threw away
the package you would end up with #:BAR, an entirely different thing
than FOO:BAR).

-- 
vsync
http://quadium.net/~vsync/

The beauty of Amendment II is that it protects the ability to deal
with both a tyrannical government and a zombie apocalypse.
        -- Eochada,
           http://forums.fark.com/cgi/fark/comments.pl?IDLink=2749371
From: Kent M Pitman
Subject: Re: (read) problem with packages
Date: 
Message-ID: <u4pn7wx13.fsf@nhplace.com>
Tim Howe <·····@quadium.net> writes:

> Adrian DOZSA <·········@gmail.com> writes:
> 
> > The idea is that when i read a form it tries to check if the package
> > exists. How can i make it ignore if the package exists and only read
> > it (like for any function, it doesn't check if it exists).
> 
> This isn't possible.  Symbols have a package.  If no package with the
> name (or a nickname) specified exists, there is no way to represent that
> symbol, short of automatically creating the package.  (If you threw away
> the package you would end up with #:BAR, an entirely different thing
> than FOO:BAR).

Well, it depends on whether you plan to immediately feed the symbol to
something computational or not as to whether there's now way to represent
it.  There are lots of representations.

And it's a weakness of CL (not a fatal one, but an annoyance) that it
doesn't choose to have a standard representation for that.  Nothing would
have kept us from having a *READ-PSUEDO-SYMBOLS* that, if T, would take
advantage of some
 (defstruct pseudo-symbol package-name symbol-name)
and would return a token representing the symbol error.

One thing that's in most of CL as an unspoken design principle is that you
don't manipulate syntax, you manipulate structure. When the reader doesn't
give you valid structure, though, what are you to do but write parsers?
And who wants to do that?  So let's at least be honest and say that the OP
is asking for something rational and that it's just harder than it should be
to achieve, without saying "of course it can't be done".  The issues that
held us back is, as happens so often in life, failure of imagination.

But let's employ some imagination and see where it gets us even given
what we have to work with today...

(1) It's true that package errors aren't portably possible to handle.
That's a pity. It's possible to poke around in ad hoc ways on a 
per-implementation basis.  Even for implementations that don't provide
a restart for the error (which would make things easier), if you are able
to rewind the stream, you could create the package and then retry the read.
It's clumsy, but depending on the application it might work.

(2) It's also kind of sad that some implementations won't let this work either:
 (defvar *my-readtable*)
 (set-syntax-from-char #\: #\A *my-readtable*)
 (defun reed (&rest args)
   (let ((*readtable* *my-readtable*))
     (apply #'read args)))
I think this is a specificational gray area, but I don't think an 
implementation is prohibited from allowing this.  And it would handy
in many cases.

(3) It's slightly possible that you could win with something like this, 
depending on your need:
(defun read-tolerant (&optional (stream *standard-input*) &rest more-args) 
  (flet ((prescan (text)
           ;; Do whatever you want to find and fix package prefixes here.
           ;; This is just an example of a trivial hack that injects a
           ;; backslash in front of any colons it sees.
           (with-output-to-string (scanned-str)
             (let ((backslash nil) (string-quotes nil) (vertical-bars nil))
               (dotimes (i (length text))
                 (let ((ch (char text i)))
                   (cond (backslash (setq backslash nil))
                         ((eql ch #\\)
                          (setq backslash t))
                         ((eql ch #\")
                          (setq string-quotes (not string-quotes)))
                         ((eql ch #\|)
                          (setq vertical-bars (not vertical-bars)))
                         ((eql ch #\:)
                          (write-char #\\ scanned-str)))
                   (write-char ch scanned-str)))))))
       (let ((text-to-read
               (with-output-to-string (str)
                 (let ((copy-stream (make-echo-stream stream str))
                       (*read-suppress* t))
                   ;; This call to read is only to get the bounds of 
                   ;; the expression to scan
                   (apply #'read copy-stream more-args)))))
         (apply #'read-from-string (prescan text-to-read) more-args))))
This hack won't reall do the right thing with : in the presence of vertical
bars because:

(read-tolerant)
(foo:bar foo::bar #\: "foo:bar" 'foo:|bar : baz|)
(FOO\:BAR FOO\:\:BAR #\: "foo:bar" (QUOTE |FOO:bar : baz|))

You can see it blurs the :'s that were outside with the ones that were
inside. But you could write something to instead recognize the packages
you need, create them temporarily, and then delete them at the end of the
read... or whatever it is that you do need.

(4) As a last resort, I think it might be theoretically possible to
portably define your own constituent non-breaking token reader by
making every constituent character into a readmacro that knows how to
parse a symbol itself and offers better handling of errors.  I've
never tried and maybe there are obstacles I've not thought of.  Maybe
some ambitious reader of this group will try it and report the
results.

- - - - 

So my real point, to reiterate, is just to be creative about your
needs and your tools.  The tools that are there are not perfect for
everything, and I think we fell short on the language design here in
ways that make things a little more of a struggle, but even what we
gave users is more than what most langagues do, and there are some
real opportunities to overcome the language weaknesses if you work at
it a bit.  The tools we did offer are a lot more flexible than people
may give them credit for.
From: Geoff Wozniak
Subject: Re: (read) problem with packages
Date: 
Message-ID: <1177307909.907830.249590@n59g2000hsh.googlegroups.com>
On Apr 23, 12:10 am, Kent M Pitman <······@nhplace.com> wrote:
> (4) As a last resort, I think it might be theoretically possible to
> portably define your own constituent non-breaking token reader by
> making every constituent character into a readmacro that knows how to
> parse a symbol itself and offers better handling of errors.  I've
> never tried and maybe there are obstacles I've not thought of.  Maybe
> some ambitious reader of this group will try it and report the
> results.
>

I tried this once and the problem I had was correctly classifying the
syntax type of a character.  There's no interface function for
readtables that returns the syntax type of characters (that I know of
-- did I miss it?  That's been known to happen) nor is there a
reliable way to compare syntax types to the standard readtable.

When I started writing the readmacro function for constituent
characters, I couldn't be sure what the syntax type of the next
character actually was.  For example, if someone did

  (set-syntax-from-char #\a #\|)

then I couldn't tell that #\a was actually a multiple escape
character.

If you were to define your own readtable based on the standard
readtable and assume it was never modified by anyone, then the
approach should work.  If you want to let others build on your custom
readtable, then I think you're out of luck.

-- Geoff
From: Kent M Pitman
Subject: Re: (read) problem with packages
Date: 
Message-ID: <uy7kjus0b.fsf@nhplace.com>
Geoff Wozniak <·············@gmail.com> writes:

> On Apr 23, 12:10 am, Kent M Pitman <······@nhplace.com> wrote:
> > (4) As a last resort, I think it might be theoretically possible to
> > portably define your own constituent non-breaking token reader by
> > making every constituent character into a readmacro that knows how to
> > parse a symbol itself and offers better handling of errors.  I've
> > never tried and maybe there are obstacles I've not thought of.  Maybe
> > some ambitious reader of this group will try it and report the
> > results.
> >
> 
> I tried this once and the problem I had was correctly classifying the
> syntax type of a character.  There's no interface function for
> readtables that returns the syntax type of characters (that I know of
> -- did I miss it?

No interface provided that I know of either.  But I think you can
create one that's reasonably portable from whole cloth if you work at
it ... it's just that the implementation technique is not even
remotely straightforward.  If I get more time, perhaps in a week or
two, I'll try to find and post the one I wrote.  For now you'll just
have to call me Fermat... ;)

> That's been known to happen) nor is there a
> reliable way to compare syntax types to the standard readtable.

Once you have a way of getting the syntax type, that's easy.
From: Geoff Wozniak
Subject: Re: (read) problem with packages
Date: 
Message-ID: <1177337015.726785.227960@y5g2000hsa.googlegroups.com>
On Apr 23, 9:42 am, Kent M Pitman <······@nhplace.com> wrote:
> No interface provided that I know of either.  But I think you can
> create one that's reasonably portable from whole cloth if you work at
> it ... it's just that the implementation technique is not even
> remotely straightforward.  If I get more time, perhaps in a week or
> two, I'll try to find and post the one I wrote.  For now you'll just
> have to call me Fermat... ;)
>

"I have this remarkable little program..."

The first idea I had was to try to see how the reader behaved when
compared to the standard readtable.  This would mean coming up with
tests to see whether a character acted like a constituent, whitespace,
etc.  This gets a bit tricky when dealing with terminating and non-
terminating macro characters, as far as I could tell, but didn't
strike me as impossible.  I doubt it be all that pleasant, though. :)

I'd be interested in seeing what you came up with.  If I get really
ambitious, I'll try to come up with something as well.

-- Geoff
From: Rob Warnock
Subject: Re: (read) problem with packages
Date: 
Message-ID: <lo-dnY03R9VJ7rDbnZ2dnUVZ_vKunZ2d@speakeasy.net>
Kent M Pitman  <······@nhplace.com> wrote:
+---------------
| Geoff Wozniak <·············@gmail.com> writes:
| > There's no interface function for readtables that returns
| > the syntax type of characters (that I know of -- did I miss it?)
| 
| No interface provided that I know of either.  But I think you can
| create one that's reasonably portable from whole cloth if you work
| at it ... it's just that the implementation technique is not even
| remotely straightforward.  ...
| 
| > ...nor is there a
| > reliable way to compare syntax types to the standard readtable.
| 
| Once you have a way of getting the syntax type, that's easy.
+---------------

Having dug into the guts of CMUCL once upon a time [when trying
(successfully, I think) to build a CL reader in C] I know that
CMUCL doesn't store "the syntax type" as a single "thing", and
that SET-SYNTAX-FROM-CHAR *doesn't* always copy all of the "minor"
attributes of a character:

    (defun set-syntax-from-char (to-char from-char &optional
					 (to-readtable *readtable*)
					 (from-readtable ()))
      "Causes the syntax of to-char to be the same as from-char in the 
      optional readtable (defaults to the current readtable).  The
      from-table defaults the standard lisp readtable by being nil."
      (let ((from-readtable (or from-readtable std-lisp-readtable)))
	;;copy from-char entries to to-char entries, but make sure that if
	;;from char is a constituent you don't copy non-movable secondary
	;;attributes (constituent types), and that said attributes magically
	;;appear if you transform a non-constituent to a constituent.
	(let ((att (get-cat-entry from-char from-readtable)))
	  (if (constituentp from-char from-readtable)
	      (setq att (get-secondary-attribute to-char)))
	  (set-cat-entry to-char att to-readtable)
	  (set-cmt-entry to-char
			 (get-cmt-entry from-char from-readtable)
			 to-readtable)))
      t)

Some explanation: In CMUCL, readtables contain a CHARACTER-MACRO-TABLE
and a separate CHARACTER-ATTRIBUTE-TABLE, which describes a few
"primary" character attributes, WHITESPACE, TERMINATING-MACRO,
ESCAPE, and CONSTITUENT, as well as a whole bunch of secondary
attributes that are related to the "primary" by having a numerical
ordering relationship. E.g.:

    > (list lisp::whitespace
	    lisp::terminating-macro
	    lisp::escape
	    lisp::constituent
	    lisp::constituent-dot
	    lisp::constituent-expt
	    lisp::constituent-slash
	    lisp::constituent-digit
	    lisp::constituent-sign
	    lisp::multiple-escape
	    lisp::package-delimiter
	    lisp::delimiter
	    lisp::constituent-decimal-digit
	    lisp::constituent-digit-or-expt
	    lisp::constituent-invalid)

    (0 1 2 3 4 5 6 7 8 10 11 12 13 14 15)
    > (lisp::character-attribute-table *readtable*)

    #(3 3 3 3 3 3 3 3 15 0 0 3 0 0 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      0 3 1 3 3 3 3 1 1 1 3 8 1 8 4 6 7 7 7 7 7 7 7 7 7 7 11 1 3 3 3 3
      3 3 3 3 5 5 5 3 3 3 3 3 5 3 3 3 3 3 3 5 3 3 3 3 3 3 3 3 2 3 3 3 1
      3 3 3 5 5 5 3 3 3 3 3 5 3 3 3 3 3 3 5 3 3 3 3 3 3 3 3 10 3 3 15 3
      3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3)
    >

There's also a static [initialized at startup] SECONDARY-ATTRIBUTE-TABLE
that contains such "secondary" attributes -- *which cannot be changed* --
but which (as you can see in the code above) are copied to the target
of a SET-SYNTAX-FROM-CHAR *instead* of the current attributes if the 
"from" character is a constituent:

    > lisp::secondary-attribute-table  

    #(3 3 3 3 3 3 3 3 15 15 15 3 15 15 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      3 15 3 3 3 3 3 3 3 3 3 3 8 3 8 4 6 7 7 7 7 7 7 7 7 7 7 11 3 3 3 3 3
      3 3 3 3 5 5 5 3 3 3 3 3 5 3 3 3 3 3 3 5 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      3 3 5 5 5 3 3 3 3 3 5 3 3 3 3 3 3 5 3 3 3 3 3 3 3 3 10 3 3 15 3 3 3
      3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
      3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3)
    > 

These two differ in the following places:

    > (loop for cat across (lisp::character-attribute-table *readtable*)
	    and sat across lisp::secondary-attribute-table
	    and i from 0
	when (/= cat sat)
	  collect (list i (code-char i) cat sat))

    ((9 #\Tab 0 15) (10 #\Newline 0 15) (12 #\Page 0 15) (13 #\Return 0 15)
     (32 #\Space 0 15) (34 #\" 1 3) (39 #\' 1 3) (40 #\( 1 3) (41 #\) 1 3)
     (44 #\, 1 3) (59 #\; 1 3) (92 #\\ 2 3) (96 #\` 1 3))
    > 

E.g., many characters that are normally whitespace are considered
"constituent-invalid" if the character has been changed into a
constituent, and likewise many characters that are normally
terminating macro characters are considered constituents if
the character has been changed into a constituent. [At least,
I *think* that's what it means... I'm not entirely sure!!]

Anyway, this is just meant to show that extracting "the" syntax of
a character from a given implementation is sometimes... complicated.



-Rob

p.s. There's also a DISPATCH-TABLES element, "which is an alist from
dispatch characters to vectors of CHAR-CODE-LIMIT functions, for use
in defining dispatching macros", but I'm going to ignore that here.

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Adrian DOZSA
Subject: Re: (read) problem with packages
Date: 
Message-ID: <1177350766.251491.16090@q75g2000hsh.googlegroups.com>
Thanks for all the details.
I've took the simplest solution: prescaned the text and replaced all
the ":" and "::" where they were package delimiters.

But this kind of hacking around doesn't feel right.
If you can create packages and intern symbols dynamically, then why
does it is different from simple (as in current package) symbols (read
doesn't check the existence of any symbol in current package) ?

Btw, read also checks if the referenced symbol exists and is exported,
not only the existence of the package.
From: Tim Howe
Subject: Re: (read) problem with packages
Date: 
Message-ID: <87abwyfq20.fsf@rash.quadium.net>
Adrian DOZSA <·········@gmail.com> writes:

> Thanks for all the details.
> I've took the simplest solution: prescaned the text and replaced all
> the ":" and "::" where they were package delimiters.
>
> But this kind of hacking around doesn't feel right.

May I ask what the goal of your project is, and the type of the source
text?

I'm guessing you're doing some sort of processing on Lisp source, but I
could be wildly wrong.

And, everyone: what's the current prevailing opinion on the
appropriateness of using symbols for arbitrary text, compared to, say,
hashtables with string keys?  It seems that for multiple data sets one
would end up creating a lot of packages dynamically.  Also, given that
I have heard property lists are out of vogue, it seems one would need to
create various hashtables anyway.

-- 
vsync
http://quadium.net/~vsync/

The beauty of Amendment II is that it protects the ability to deal
with both a tyrannical government and a zombie apocalypse.
        -- Eochada,
           http://forums.fark.com/cgi/fark/comments.pl?IDLink=2749371
From: Adrian DOZSA
Subject: Re: (read) problem with packages
Date: 
Message-ID: <1177407644.472300.325600@s33g2000prh.googlegroups.com>
On Apr 24, 5:45 am, Tim Howe <····@quadium.net> wrote:
>
> May I ask what the goal of your project is, and the type of the source
> text?
>
> I'm guessing you're doing some sort of processing on Lisp source, but I
> could be wildly wrong.
>
> And, everyone: what's the current prevailing opinion on the
> appropriateness of using symbols for arbitrary text, compared to, say,
> hashtables with string keys?  It seems that for multiple data sets one
> would end up creating a lot of packages dynamically.  Also, given that
> I have heard property lists are out of vogue, it seems one would need to
> create various hashtables anyway.
>
> --
> vsynchttp://quadium.net/~vsync/
>
> The beauty of Amendment II is that it protects the ability to deal
> with both a tyrannical government and a zombie apocalypse.
>         -- Eochada,
>            http://forums.fark.com/cgi/fark/comments.pl?IDLink=2749371

Yes, you're right. I am doing some kind of Lisp source processing; i
am extracting models from large Lisp systems (EMOF compliant models).
From: Richard M Kreuter
Subject: Re: (read) problem with packages
Date: 
Message-ID: <87k5w3cd43.fsf@tan-ru.localdomain>
Kent M Pitman <······@nhplace.com> writes:

> (2) It's also kind of sad that some implementations won't let this
> work either:
>  (defvar *my-readtable*)
>  (set-syntax-from-char #\: #\A *my-readtable*)
>  (defun reed (&rest args)
>    (let ((*readtable* *my-readtable*))
>      (apply #'read args)))
> I think this is a specificational gray area, but I don't think an 
> implementation is prohibited from allowing this.  And it would handy
> in many cases.

This isn't a gray area, unfortunately: #\: already has the same syntax
type as #\A (they're constituents, see Figure 2.7).  The difference is
the characters' constituent traits (Figure 2.8), which there's no
standard interface for changing.

--
RmK
From: Pascal Bourguignon
Subject: Re: (read) problem with packages
Date: 
Message-ID: <877is3ezvd.fsf@voyager.informatimago.com>
Kent M Pitman <······@nhplace.com> writes:
> [...]
> And it's a weakness of CL (not a fatal one, but an annoyance) that it
> doesn't choose to have a standard representation for that.  Nothing would
> have kept us from having a *READ-PSUEDO-SYMBOLS* that, if T, would take
> advantage of some
>  (defstruct pseudo-symbol package-name symbol-name)
> and would return a token representing the symbol error.
>
> One thing that's in most of CL as an unspoken design principle is that you
> don't manipulate syntax, you manipulate structure. When the reader doesn't
> give you valid structure, though, what are you to do but write parsers?
> And who wants to do that?  So let's at least be honest and say that the OP
> is asking for something rational and that it's just harder than it should be
> to achieve, without saying "of course it can't be done".  The issues that
> held us back is, as happens so often in life, failure of imagination.
>
> But let's employ some imagination and see where it gets us even given
> what we have to work with today...
>
> (1) It's true that package errors aren't portably possible to handle.
> [...]
> (2) It's also kind of sad that some implementations won't let this work either:
> [...]
> (3) It's slightly possible that you could win with something like this, 
> [...]
> (4) As a last resort, I think it might be theoretically possible to
> [...]
> So my real point, to reiterate, is just to be creative about your
> needs and your tools.  The tools that are there are not perfect for
> everything, and I think we fell short on the language design here in
> ways that make things a little more of a struggle, but even what we
> gave users is more than what most langagues do, and there are some
> real opportunities to overcome the language weaknesses if you work at
> it a bit.  The tools we did offer are a lot more flexible than people
> may give them credit for.

Or you'd just need a hook on the parse-token function in the lisp
reader, once the token string have been accumulated (with the
character traits), the user may want to build a different object from
it than what the standard  specifies for the reader.

The weakness being that you have to implement the whole lisp reader to
get this hook, since it's not standardized. (and since implementing
portably a lisp reader is easier than to modify the standard and have
all implementaters implement the change).

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
From: Pascal Bourguignon
Subject: Re: (read) problem with packages
Date: 
Message-ID: <87647nezt6.fsf@voyager.informatimago.com>
Adrian DOZSA <·········@gmail.com> writes:

> I have a little problem with the read function when packages are
> involved:
>
> CL-USER 1 > (read)
> (foo:bar)
> Error: No package named "FOO".
>   1 (abort) Return to level 0.
>   2 Return to top loop level 0.
>
> The idea is that when i read a form it tries to check if the package
> exists. How can i make it ignore if the package exists and only read
> it (like for any function, it doesn't check if it exists).

You could use my new source-text package, but you wouldn't get a
symbol, as Tim explained, symbols have a package.  But from the
objects you'd read with my source reader, you could build a symbol in
any existing package if you will.

http://darcs.informatimago.com/lisp/common-lisp/source-text.lisp
http://darcs.informatimago.com/lisp/common-lisp/reader.lisp
http://darcs.informatimago.com/lisp/common-lisp/source-form.lisp


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
From: Adrian DOZSA
Subject: Re: (read) problem with packages
Date: 
Message-ID: <1177496997.278323.46720@r30g2000prh.googlegroups.com>
On Apr 23, 9:00 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Adrian DOZSA <·········@gmail.com> writes:
> > I have a little problem with the read function when packages are
> > involved:
>
> > CL-USER 1 > (read)
> > (foo:bar)
> > Error: No package named "FOO".
> >   1 (abort) Return to level 0.
> >   2 Return to top loop level 0.
>
> > The idea is that when i read a form it tries to check if the package
> > exists. How can i make it ignore if the package exists and only read
> > it (like for any function, it doesn't check if it exists).
>
> You could use my new source-text package, but you wouldn't get a
> symbol, as Tim explained, symbols have a package.  But from the
> objects you'd read with my source reader, you could build a symbol in
> any existing package if you will.
>
> http://darcs.informatimago.com/lisp/common-lisp/source-text.lisphttp://darcs.informatimago.com/lisp/common-lisp/reader.lisphttp://darcs.informatimago.com/lisp/common-lisp/source-form.lisp
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
>
> PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
> manner whatsoever, will increase the amount of disorder in the
> universe. Although no liability is implied herein, the consumer is
> warned that this process will ultimately lead to the heat death of
> the universe.

Thanks for the tip. But i've run into the same problem:

CL-USER 11 > (COM.INFORMATIMAGO.COMMON-LISP.READER:read)
(foo:bar)
Error: There is no package with name "FOO"
  1 (abort) Return to level 0.
  2 Return to top loop level 0.

How could i avoid this? if it can be done with your reader.
From: Pascal Bourguignon
Subject: Re: (read) problem with packages
Date: 
Message-ID: <871wi7fhei.fsf@voyager.informatimago.com>
Adrian DOZSA <·········@gmail.com> writes:

> On Apr 23, 9:00 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>> Adrian DOZSA <·········@gmail.com> writes:
>> > I have a little problem with the read function when packages are
>> > involved:
>>
>> > CL-USER 1 > (read)
>> > (foo:bar)
>> > Error: No package named "FOO".
>> >   1 (abort) Return to level 0.
>> >   2 Return to top loop level 0.
>>
>> > The idea is that when i read a form it tries to check if the package
>> > exists. How can i make it ignore if the package exists and only read
>> > it (like for any function, it doesn't check if it exists).
>>
>> You could use my new source-text package, but you wouldn't get a
>> symbol, as Tim explained, symbols have a package.  But from the
>> objects you'd read with my source reader, you could build a symbol in
>> any existing package if you will.
>>
>> http://darcs.informatimago.com/lisp/common-lisp/source-text.lisphttp://darcs.informatimago.com/lisp/common-lisp/reader.lisphttp://darcs.informatimago.com/lisp/common-lisp/source-form.lisp
>>
>> --
>> __Pascal Bourguignon__                    http://www.informatimago.com/
>>
>> PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
>> manner whatsoever, will increase the amount of disorder in the
>> universe. Although no liability is implied herein, the consumer is
>> warned that this process will ultimately lead to the heat death of
>> the universe.
>
> Thanks for the tip. But i've run into the same problem:
>
> CL-USER 11 > (COM.INFORMATIMAGO.COMMON-LISP.READER:read)
> (foo:bar)
> Error: There is no package with name "FOO"
>   1 (abort) Return to level 0.
>   2 Return to top loop level 0.
>
> How could i avoid this? if it can be done with your reader.

By using the source-text package instead of the reader package, that
just re-implements the CLHS specfied lisp reader.

So instead of reading symbols, you read source-token objects and you
can interpret the token  slot of these objects as you want: you could
just keep the string, or you could intern it making symbols named
|FOO:SOME| and |BAR:SYMBOL|, or skip over the colon, whatever.

Note that the token is not determined as either a symbol or something
else, because tokens such as: ABC are potential numbers, depending on
the read time value of *READ-BASE*.  So you need to interpret the read
structure.


C/USER[4]> (inspect
            (with-input-from-string (src "(foo:some bar:symbol)")
              (COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:source-read src)))
#<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-LIST #x2073BFCE>:  standard object
 type: COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-LIST
0 [MACRO-CHARACTER]:  #\(
1 [FILE]:  NIL
2 [POSITION]:  0
3 [TEXT]:  "(foo:some bar:symbol)"
4 [ELEMENTS]:  
(#<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073B2B6>
 #<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073BF7E>)
INSPECT-- type :h for help; :q to return to the REPL ---> 4
(#<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073B2B6>
 #<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073BF7E>):  Cons
 a list of length 2
0:  #<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073B2B6>
1:  #<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073BF7E>
INSPECT-- type :h for help; :q to return to the REPL ---> 0
#<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073B2B6>:  standard object
 type: COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN
0 [FILE]:  NIL
1 [POSITION]:  1
2 [TEXT]:  "foo:some "
3 [TOKEN]:  "FOO:SOME"
4 [TRAITS]:  #<ARRAY (UNSIGNED-BYTE 16) (8) FILL-POINTER=8 #x2073ACDE>
INSPECT-- type :h for help; :q to return to the REPL ---> :u
(#<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073B2B6>
 #<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073BF7E>):  Cons
 a list of length 2
0:  #<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073B2B6>
1:  #<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073BF7E>
INSPECT-- type :h for help; :q to return to the REPL ---> 1
#<COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN #x2073BF7E>:  standard object
 type: COM.INFORMATIMAGO.COMMON-LISP.SOURCE-TEXT:SOURCE-TOKEN
0 [FILE]:  NIL
1 [POSITION]:  10
2 [TEXT]:  "bar:symbol"
3 [TOKEN]:  "BAR:SYMBOL"
4 [TRAITS]:  #<ARRAY (UNSIGNED-BYTE 16) (40) FILL-POINTER=10 #x2073B826>
INSPECT-- type :h for help; :q to return to the REPL ---> :q

C/USER[5]> 


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"This machine is a piece of GAGH!  I need dual Opteron 850
processors if I am to do battle with this code!"