How to read from a file which has `:'?
Raimondas Kiveris
In article <uvhzie...@WINTERMUTE.eagle>,
SDS <sshte...@cctrading.com> wrote:
>I have to read from a file (a stream) which contains some text with
>numbers, so I want the numbers to be parsed, but I don't want to be
>pestered by error messages that #zzz is undefined and xxx is not a valid
>package name (when the file has "xxx:" in it).
What a coincidence. I was wrestling with the same problem couple of
days ago.
The solution that worked for me was to make #\: a terminating
character with
(set-macro-character #\: (get-macro-character #\a)
nil *parser-rt*)
That leaves me with (XX |:2|) when reading token XX:2
so I have to filter the result of read through function that
assembles (XX |:2|) back into |XX:2|. Not very efficient.
I wonder too if there is an elegant solution to this problem
Thanks,
=Rai
Erik Naggum
* sshte...@cctrading.com
| I have to read from a file (a stream) which contains some text with
| numbers, so I want the numbers to be parsed, but I don't want to be
| pestered by error messages that #zzz is undefined and xxx is not a valid
| package name (when the file has "xxx:" in it).
bind a reader macro to each character that is to be considered text, and
assemble a _string_ from the read characters, instead. you can still use
`read', but you don't want the normal Lisp reader.
anyway, this is a lot easier if you pull the whole file into memory with
`read-sequence' first, since you can return (displaced) substrings of the
file instead of consing up new strings all the time. but even this is
wasteful if you have very large files. (it also isn't possible in some
smaller Lisp implementations that think `fixnum' should be 16 bits wide.)
I'd actually love to see a `stream-substring' function that could return an
arbitrary segment of a stream's contents from a position set as the
`stream-mark' to anywhere between the mark and the current position. the
most common way to use I/O buffers is to allocate one for a given direction
and reuse it as the buffer is exhausted at the character level. I suggest
the buffers should be kept around if a (structured) input token crosses a
buffer boundary, the start of which be maintained by the mark. the I/O
system would keep allocating I/O buffers until the mark moved, and free
them when it moved out of them. this would make it possible to grab
strings from an input stream without having to copy each character from one
string to another, which probably would have to be adjustable, too.
this isn't only a question of performance. I don't think collecting
characters into a string one by one from another string is elegant.
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://www.naggum.no/emacs/ for Emacs-20-related material.
Raimondas Kiveris
In article <usoule...@WINTERMUTE.eagle>,
SDS <sshte...@cctrading.com> wrote:
>>>>> In a very interesting message <60stcf$ru2$1...@nfs.kolumbus.fi>
>>>>> Sent on 1 Oct 1997 07:16:31 GMT
>>>>> Honorable rkiv...@u.comptel.fi (Raimondas Kiveris) writes
>>>>> on the subject of "Re: How to read from a file which has `:'?":
> >> >numbers, so I want the numbers to be parsed, but I don't want to be
> >> >pestered by error messages that #zzz is undefined and xxx is not a valid
> >> >package name (when the file has "xxx:" in it).
> >>
> >> character with
> >> (set-macro-character #\: (get-macro-character #\a)
> >> nil *parser-rt*)
>
>function, so this signals an error.
Bummer!
This must be implementation-dependant thing then.
On Allegro CL 4.3:
USER(1): (get-macro-character #\a)
#<Function READ-TOKEN>
T
USER(2): (apropos "READ-TOKEN")
EXCL::READ-TOKEN [function] (STREAM FIRSTCHAR)
Sorry about the confusion
=Rai