Problem with read-from-string

[proton]

If I understand the CLHS correctly, read-from-string accepts a start keyword which should mark the beginning of the read process.
However, if I do:

(read-from-string "1234" :start 2)

I get 1234. I would expect to get 34.

How can I read the string from any given character (withouth having to use subseq, which creates unnecesary objects)?

Thanks for any help.

[serge de marre]

CL-USER> (read-from-string "1234" :start 2)
STYLE-WARNING:
:START as EOF-ERROR-P argument to READ-FROM-STRING: probable error. Two
optional arguments must be provided before the first keyword argument.
1234
4
CL-USER> (read-from-string "1234" nil nil :start 2)
34
4
CL-USER>

[Elias Mårtenson]

This is because READ-FROM-STRING has both &optional and &key arguments. In order for that to work properly, you need to include all the &optional arguments:

(read-from-string "1234" t nil :start 2)

Frankly, having bother &optional and &key at the same time is always messy, and shouldn't be allowed much less being used by standard functions.

[proton]

Of course, silly me! I shouldn't start programming before I've had at least three cups of coffee.:)

Thanks very much Serge.

[Barry Margolin]

In article <fce20170-9dac-4380...@googlegroups.com>,

Blast from the past. This question is one of the ones that prompted me
to create the Common Lisp FAQ about 20 years ago.

P.S. Please switch to a real newsreader. The new Google Groups really
messes up nested quotes -- it either fills them so that the ">"
characters are all in the middle of the lines, or it double spaces them
like your message. Anyone enlightened enough to program in Lisp should
not be so technically challenged that they have to use GG.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Pascal J. Bourguignon]

Barry Margolin <bar...@alum.mit.edu> writes:

> Blast from the past. This question is one of the ones that prompted me
> to create the Common Lisp FAQ about 20 years ago.
>
> P.S. Please switch to a real newsreader. The new Google Groups really
> messes up nested quotes -- it either fills them so that the ">"
> characters are all in the middle of the lines, or it double spaces them
> like your message. Anyone enlightened enough to program in Lisp should
> not be so technically challenged that they have to use GG.

This also, is a netiquette algorithm that has existed for more than 30
years, how come those smart google employees can't implement it
correctly (even when doing that on their 20%)?!?

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Pascal J. Bourguignon]

Indeed, and it is not allowed even for standard functions, but a few
reading function exceptions, for compatibility with precursor lisps,
which is the main point of Common Lisp.

[Marco Antoniotti]

On Tuesday, August 7, 2012 2:12:42 PM UTC+3, informatimago wrote:

Yep. What is 'strcmp' doing in the C standard? A standard function should not be named with such a shorthand. :)

Cheers
--
MA

[WJ]

Pascal J. Bourguignon wrote:

> Elias Mårtenson <lok...@gmail.com> writes:
>
> > On Tuesday, 7 August 2012 14:59:06 UTC+8, proton wrote:
> >> If I understand the CLHS correctly, read-from-string accepts a start keyword which should mark the beginning of the read process.
> >>
> >> However, if I do:
> >>
> >> (read-from-string "1234" :start 2)
> >>
> >> I get 1234. I would expect to get 34.
> >>
> >> How can I read the string from any given character (withouth having to use subseq, which creates unnecesary objects)?
> >
> > This is because READ-FROM-STRING has both &optional and &key arguments.
> > In order for that to work properly, you need to include
> > all the &optional arguments:
> >
> > (read-from-string "1234" t nil :start 2)
> >
> > Frankly, having bother &optional and &key at the same time is always
> > messy, and shouldn't be allowed much less being used by standard
> > functions.
>
> Indeed, and it is not allowed even for standard functions, but a few
> reading function exceptions, for compatibility with precursor lisps,
> which is the main point of Common Lisp.

Pascal is always perfectly content with what his deity (CL) allows him.
He never, ever questions or doubts his deity. After all, that would
be heresy.

It is telling that he admits that the purpose of creating CL was
not to create a good programming language; it was merely to create
a crude, clunky, crippled, ugly, gargantuan, bloated Blub that was
compatible with its "precursors".

Bigloo allows optional and key parameters to the same function,
and the optional arguments are truly optional.

1:=> (define (baz fst #!optional snd #!key final) (list fst snd final))
baz
1:=> (baz 'rook)
(rook #f #f)
1:=> (baz 'rook :final 'pit)
(rook #f pit)
1:=> (baz 'rook 500 :final 'pit)
(rook 500 pit)

It's similar in Racket:

> (define (baz fst [snd #f] #:final [final #f]) (list fst snd final))
> (baz 'rook)
'(rook #f #f)
> (baz 'rook #:final 'pit)
'(rook #f pit)
> (baz 'rook 500 #:final 'pit)
'(rook 500 pit)
> (baz 'rook #:final 'pit 500)
'(rook 500 pit)

Once again we see that CL (COBOL-Like, Commode Language)
is a sick joke. "Blub" is its true name.
It and its disciples are the worst enemies of Lispy programming.