Is there a way to tell if a string as a whole can be parsed as a
number? In the specific case I'm working on, I only need to make sure
a string can be parsed as an integer, but I have no doubt that there's
a general purpose solution.
I know about PARSE-INTEGER, but the main problem is that it just bombs
out if there's a problem, and it returns success as soon as it finds
an integer value. That is,
(parse-integer "1A")
returns successfully, and instead of NIL,
(parse-integer "A1")
signals a SIMPLE-PARSE-ERROR.
My attempt at figuring this out returned T no matter what was passed
to it, even NIL. Here's where I got:
(defun parseable-integer-p (string-num)
(handler-case
(progn
(parse-integer string-num :junk-allowed nil)
t)
(system::simple-parse-error (c)
(declare (ignore c))
nil)))
No matter what I pass into that, T is returned. I'm using CLISP
version 2.43.
Any ideas?
Lee Crabtree
On Dec 13, 7:51 pm, "lee.crabtree" <············@gmail.com> wrote:
> Is there a way to tell if a string as a whole can be parsed as a
> number? In the specific case I'm working on, I only need to make sure
> a string can be parsed as an integer, but I have no doubt that there's
> a general purpose solution.
For integers I think the simplest way would be just (every #'digit-
char-p "somestring"). For a more general case maybe:
(defun string-number-p (string)
(multiple-value-bind (potential-number read-length) (read-from-
string string)
(and (= read-length (length string))
(numberp potential-number))))
In article
<····································@d27g2000prf.googlegroups.com>,
········@gmail.com wrote:
> On Dec 13, 7:51 pm, "lee.crabtree" <············@gmail.com> wrote:
> > Is there a way to tell if a string as a whole can be parsed as a
> > number? In the specific case I'm working on, I only need to make sure
> > a string can be parsed as an integer, but I have no doubt that there's
> > a general purpose solution.
>
> For integers I think the simplest way would be just (every #'digit-
> char-p "somestring").
The definition I've always heard for "integers" includes negative
numbers.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Dec 13, 1:51 pm, "lee.crabtree" <············@gmail.com> wrote:
> Is there a way to tell if a string as a whole can be parsed as a
> number? In the specific case I'm working on, I only need to make sure
> a string can be parsed as an integer, but I have no doubt that there's
> a general purpose solution.
>
> I know about PARSE-INTEGER, but the main problem is that it just bombs
> out if there's a problem, and it returns success as soon as it finds
> an integer value. That is,
>
> (parse-integer "1A")
>
> returns successfully, and instead of NIL,
That should have signaled a parse error.
> (parse-integer "A1")
>
> signals a SIMPLE-PARSE-ERROR.
>
> My attempt at figuring this out returned T no matter what was passed
> to it, even NIL. Here's where I got:
>
> (defun parseable-integer-p (string-num)
> (handler-case
> (progn
> (parse-integer string-num :junk-allowed nil)
> t)
> (system::simple-parse-error (c)
> (declare (ignore c))
> nil)))
>
> No matter what I pass into that, T is returned. I'm using CLISP
> version 2.43.
Weird, what platform?...
[6]> (loop for x in '("1A" "A1" "45" "65 " " 99 " "3.141519" "45
test")
collect (ignore-errors (parse-integer x)))
(NIL NIL 45 65 99 NIL NIL)
[7]> (lisp-implementation-version)
"2.43 (2007-11-18) (built on stnt067 [192.168.0.1])"
[8]>
---
Geoff
In article
<····································@b1g2000pra.googlegroups.com>,
"lee.crabtree" <············@gmail.com> wrote:
> Is there a way to tell if a string as a whole can be parsed as a
> number? In the specific case I'm working on, I only need to make sure
> a string can be parsed as an integer, but I have no doubt that there's
> a general purpose solution.
>
> I know about PARSE-INTEGER, but the main problem is that it just bombs
> out if there's a problem, and it returns success as soon as it finds
> an integer value. That is,
>
> (parse-integer "1A")
>
> returns successfully, and instead of NIL,
>
> (parse-integer "A1")
>
> signals a SIMPLE-PARSE-ERROR.
>
> My attempt at figuring this out returned T no matter what was passed
> to it, even NIL. Here's where I got:
>
> (defun parseable-integer-p (string-num)
> (handler-case
> (progn
> (parse-integer string-num :junk-allowed nil)
> t)
> (system::simple-parse-error (c)
> (declare (ignore c))
> nil)))
>
> No matter what I pass into that, T is returned. I'm using CLISP
> version 2.43.
>
> Any ideas?
>
> Lee Crabtree
Works for me in CLISP 2.41 on an Intel Mac.
--
http://lispm.dyndns.org/
Grrrrr.
If I run it, I get T no matter what.
(parseable-integer-p "1")
returns T, which is right. However,
(parseable-integer-p "A")
returns T, which is wrong. Empty strings, strings with no numbers,
strings of ALL numbers, long strings, short strings, and NIL all give
back T.
I can't imagine it would make a difference in this case, but I'm
running on Windows, and using SLIME.
Lee Crabtree
On Dec 13, 1:01 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@b1g2000pra.googlegroups.com>,
>
>
>
> "lee.crabtree" <············@gmail.com> wrote:
> > Is there a way to tell if a string as a whole can be parsed as a
> > number? In the specific case I'm working on, I only need to make sure
> > a string can be parsed as an integer, but I have no doubt that there's
> > a general purpose solution.
>
> > I know about PARSE-INTEGER, but the main problem is that it just bombs
> > out if there's a problem, and it returns success as soon as it finds
> > an integer value. That is,
>
> > (parse-integer "1A")
>
> > returns successfully, and instead of NIL,
>
> > (parse-integer "A1")
>
> > signals a SIMPLE-PARSE-ERROR.
>
> > My attempt at figuring this out returned T no matter what was passed
> > to it, even NIL. Here's where I got:
>
> > (defun parseable-integer-p (string-num)
> > (handler-case
> > (progn
> > (parse-integer string-num :junk-allowed nil)
> > t)
> > (system::simple-parse-error (c)
> > (declare (ignore c))
> > nil)))
>
> > No matter what I pass into that, T is returned. I'm using CLISP
> > version 2.43.
>
> > Any ideas?
>
> > Lee Crabtree
>
> Works for me in CLISP 2.41 on an Intel Mac.
>
> --http://lispm.dyndns.org/
In article
<····································@i12g2000prf.googlegroups.com>,
"lee.crabtree" <············@gmail.com> wrote:
> Grrrrr.
>
> If I run it, I get T no matter what.
>
> (parseable-integer-p "1")
>
> returns T, which is right. However,
>
> (parseable-integer-p "A")
>
> returns T, which is wrong. Empty strings, strings with no numbers,
> strings of ALL numbers, long strings, short strings, and NIL all give
> back T.
>
> I can't imagine it would make a difference in this case, but I'm
> running on Windows, and using SLIME.
>
> Lee Crabtree
RJMBP:~ joswig$ clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Welcome to GNU CLISP 2.41 (2006-10-13) <http://clisp.cons.org/>
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
Type :h and hit Enter for context help.
[1]> (defun parseable-integer-p (string-num)
(handler-case
(progn
(parse-integer string-num :junk-allowed nil)
t)
(system::simple-parse-error (c)
(declare (ignore c))
nil)))
PARSEABLE-INTEGER-P
[2]> (PARSEABLE-INTEGER-P "10")
T
[3]> (PARSEABLE-INTEGER-P "1A")
NIL
[4]> (parseable-integer-p "A")
NIL
[5]>
>
> On Dec 13, 1:01 pm, Rainer Joswig <······@lisp.de> wrote:
> > In article
> > <····································@b1g2000pra.googlegroups.com>,
> >
> >
> >
> > "lee.crabtree" <············@gmail.com> wrote:
> > > Is there a way to tell if a string as a whole can be parsed as a
> > > number? In the specific case I'm working on, I only need to make sure
> > > a string can be parsed as an integer, but I have no doubt that there's
> > > a general purpose solution.
> >
> > > I know about PARSE-INTEGER, but the main problem is that it just bombs
> > > out if there's a problem, and it returns success as soon as it finds
> > > an integer value. That is,
> >
> > > (parse-integer "1A")
> >
> > > returns successfully, and instead of NIL,
> >
> > > (parse-integer "A1")
> >
> > > signals a SIMPLE-PARSE-ERROR.
> >
> > > My attempt at figuring this out returned T no matter what was passed
> > > to it, even NIL. Here's where I got:
> >
> > > (defun parseable-integer-p (string-num)
> > > (handler-case
> > > (progn
> > > (parse-integer string-num :junk-allowed nil)
> > > t)
> > > (system::simple-parse-error (c)
> > > (declare (ignore c))
> > > nil)))
> >
> > > No matter what I pass into that, T is returned. I'm using CLISP
> > > version 2.43.
> >
> > > Any ideas?
> >
> > > Lee Crabtree
> >
> > Works for me in CLISP 2.41 on an Intel Mac.
> >
> > --http://lispm.dyndns.org/
--
http://lispm.dyndns.org/
In article <····························@news-europe.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@i12g2000prf.googlegroups.com>,
> "lee.crabtree" <············@gmail.com> wrote:
>
> > Grrrrr.
> >
> > If I run it, I get T no matter what.
> >
> > (parseable-integer-p "1")
> >
> > returns T, which is right. However,
> >
> > (parseable-integer-p "A")
> >
> > returns T, which is wrong. Empty strings, strings with no numbers,
> > strings of ALL numbers, long strings, short strings, and NIL all give
> > back T.
> >
> > I can't imagine it would make a difference in this case, but I'm
> > running on Windows, and using SLIME.
Can you run it without SLIME? What would be the result then?
> >
> > Lee Crabtree
>
>
> RJMBP:~ joswig$ clisp
> i i i i i i i ooooo o ooooooo ooooo ooooo
> I I I I I I I 8 8 8 8 8 o 8 8
> I \ `+' / I 8 8 8 8 8 8
> \ `-+-' / 8 8 8 ooooo 8oooo
> `-__|__-' 8 8 8 8 8
> | 8 o 8 8 o 8 8
> ------+------ ooooo 8oooooo ooo8ooo ooooo 8
>
> Welcome to GNU CLISP 2.41 (2006-10-13) <http://clisp.cons.org/>
>
> Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> Copyright (c) Sam Steingold, Bruno Haible 2001-2006
>
> Type :h and hit Enter for context help.
>
> [1]> (defun parseable-integer-p (string-num)
> (handler-case
> (progn
> (parse-integer string-num :junk-allowed nil)
> t)
> (system::simple-parse-error (c)
> (declare (ignore c))
> nil)))
> PARSEABLE-INTEGER-P
> [2]> (PARSEABLE-INTEGER-P "10")
> T
> [3]> (PARSEABLE-INTEGER-P "1A")
> NIL
> [4]> (parseable-integer-p "A")
> NIL
> [5]>
>
>
> >
> > On Dec 13, 1:01 pm, Rainer Joswig <······@lisp.de> wrote:
> > > In article
> > > <····································@b1g2000pra.googlegroups.com>,
> > >
> > >
> > >
> > > "lee.crabtree" <············@gmail.com> wrote:
> > > > Is there a way to tell if a string as a whole can be parsed as a
> > > > number? In the specific case I'm working on, I only need to make sure
> > > > a string can be parsed as an integer, but I have no doubt that there's
> > > > a general purpose solution.
> > >
> > > > I know about PARSE-INTEGER, but the main problem is that it just bombs
> > > > out if there's a problem, and it returns success as soon as it finds
> > > > an integer value. That is,
> > >
> > > > (parse-integer "1A")
> > >
> > > > returns successfully, and instead of NIL,
> > >
> > > > (parse-integer "A1")
> > >
> > > > signals a SIMPLE-PARSE-ERROR.
> > >
> > > > My attempt at figuring this out returned T no matter what was passed
> > > > to it, even NIL. Here's where I got:
> > >
> > > > (defun parseable-integer-p (string-num)
> > > > (handler-case
> > > > (progn
> > > > (parse-integer string-num :junk-allowed nil)
> > > > t)
> > > > (system::simple-parse-error (c)
> > > > (declare (ignore c))
> > > > nil)))
> > >
> > > > No matter what I pass into that, T is returned. I'm using CLISP
> > > > version 2.43.
> > >
> > > > Any ideas?
> > >
> > > > Lee Crabtree
> > >
> > > Works for me in CLISP 2.41 on an Intel Mac.
> > >
> > > --http://lispm.dyndns.org/
--
http://lispm.dyndns.org/
Looks like it's something to do with either Emacs or SLIME. Running
CLISP straight from cmd.exe gave the expected results. What would
keep that from working?
Lee Crabtree
On Dec 13, 1:59 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <····························@news-europe.giganews.com>,
> Rainer Joswig <······@lisp.de> wrote:
>
>
>
> > In article
> > <····································@i12g2000prf.googlegroups.com>,
> > "lee.crabtree" <············@gmail.com> wrote:
>
> > > Grrrrr.
>
> > > If I run it, I get T no matter what.
>
> > > (parseable-integer-p "1")
>
> > > returns T, which is right. However,
>
> > > (parseable-integer-p "A")
>
> > > returns T, which is wrong. Empty strings, strings with no numbers,
> > > strings of ALL numbers, long strings, short strings, and NIL all give
> > > back T.
>
> > > I can't imagine it would make a difference in this case, but I'm
> > > running on Windows, and using SLIME.
>
> Can you run it without SLIME? What would be the result then?
>
>
>
>
>
> > > Lee Crabtree
>
> > RJMBP:~ joswig$ clisp
> > i i i i i i i ooooo o ooooooo ooooo ooooo
> > I I I I I I I 8 8 8 8 8 o 8 8
> > I \ `+' / I 8 8 8 8 8 8
> > \ `-+-' / 8 8 8 ooooo 8oooo
> > `-__|__-' 8 8 8 8 8
> > | 8 o 8 8 o 8 8
> > ------+------ ooooo 8oooooo ooo8ooo ooooo 8
>
> > Welcome to GNU CLISP 2.41 (2006-10-13) <http://clisp.cons.org/>
>
> > Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> > Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> > Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> > Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> > Copyright (c) Sam Steingold, Bruno Haible 2001-2006
>
> > Type :h and hit Enter for context help.
>
> > [1]> (defun parseable-integer-p (string-num)
> > (handler-case
> > (progn
> > (parse-integer string-num :junk-allowed nil)
> > t)
> > (system::simple-parse-error (c)
> > (declare (ignore c))
> > nil)))
> > PARSEABLE-INTEGER-P
> > [2]> (PARSEABLE-INTEGER-P "10")
> > T
> > [3]> (PARSEABLE-INTEGER-P "1A")
> > NIL
> > [4]> (parseable-integer-p "A")
> > NIL
> > [5]>
>
> > > On Dec 13, 1:01 pm, Rainer Joswig <······@lisp.de> wrote:
> > > > In article
> > > > <····································@b1g2000pra.googlegroups.com>,
>
> > > > "lee.crabtree" <············@gmail.com> wrote:
> > > > > Is there a way to tell if a string as a whole can be parsed as a
> > > > > number? In the specific case I'm working on, I only need to make sure
> > > > > a string can be parsed as an integer, but I have no doubt that there's
> > > > > a general purpose solution.
>
> > > > > I know about PARSE-INTEGER, but the main problem is that it just bombs
> > > > > out if there's a problem, and it returns success as soon as it finds
> > > > > an integer value. That is,
>
> > > > > (parse-integer "1A")
>
> > > > > returns successfully, and instead of NIL,
>
> > > > > (parse-integer "A1")
>
> > > > > signals a SIMPLE-PARSE-ERROR.
>
> > > > > My attempt at figuring this out returned T no matter what was passed
> > > > > to it, even NIL. Here's where I got:
>
> > > > > (defun parseable-integer-p (string-num)
> > > > > (handler-case
> > > > > (progn
> > > > > (parse-integer string-num :junk-allowed nil)
> > > > > t)
> > > > > (system::simple-parse-error (c)
> > > > > (declare (ignore c))
> > > > > nil)))
>
> > > > > No matter what I pass into that, T is returned. I'm using CLISP
> > > > > version 2.43.
>
> > > > > Any ideas?
>
> > > > > Lee Crabtree
>
> > > > Works for me in CLISP 2.41 on an Intel Mac.
>
> > > > --http://lispm.dyndns.org/
>
> --http://lispm.dyndns.org/
In article
<····································@i29g2000prf.googlegroups.com>,
"lee.crabtree" <············@gmail.com> wrote:
> Looks like it's something to do with either Emacs or SLIME. Running
> CLISP straight from cmd.exe gave the expected results. What would
> keep that from working?
I don't know. You might want to ask on the SLIME mailing list.
>
> Lee Crabtree
>
> On Dec 13, 1:59 pm, Rainer Joswig <······@lisp.de> wrote:
> > In article <····························@news-europe.giganews.com>,
> > Rainer Joswig <······@lisp.de> wrote:
> >
> >
> >
> > > In article
> > > <····································@i12g2000prf.googlegroups.com>,
> > > "lee.crabtree" <············@gmail.com> wrote:
> >
> > > > Grrrrr.
> >
> > > > If I run it, I get T no matter what.
> >
> > > > (parseable-integer-p "1")
> >
> > > > returns T, which is right. However,
> >
> > > > (parseable-integer-p "A")
> >
> > > > returns T, which is wrong. Empty strings, strings with no numbers,
> > > > strings of ALL numbers, long strings, short strings, and NIL all give
> > > > back T.
> >
> > > > I can't imagine it would make a difference in this case, but I'm
> > > > running on Windows, and using SLIME.
> >
> > Can you run it without SLIME? What would be the result then?
> >
> >
> >
> >
> >
> > > > Lee Crabtree
> >
> > > RJMBP:~ joswig$ clisp
> > > i i i i i i i ooooo o ooooooo ooooo ooooo
> > > I I I I I I I 8 8 8 8 8 o 8 8
> > > I \ `+' / I 8 8 8 8 8 8
> > > \ `-+-' / 8 8 8 ooooo 8oooo
> > > `-__|__-' 8 8 8 8 8
> > > | 8 o 8 8 o 8 8
> > > ------+------ ooooo 8oooooo ooo8ooo ooooo 8
> >
> > > Welcome to GNU CLISP 2.41 (2006-10-13) <http://clisp.cons.org/>
> >
> > > Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> > > Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> > > Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> > > Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> > > Copyright (c) Sam Steingold, Bruno Haible 2001-2006
> >
> > > Type :h and hit Enter for context help.
> >
> > > [1]> (defun parseable-integer-p (string-num)
> > > (handler-case
> > > (progn
> > > (parse-integer string-num :junk-allowed nil)
> > > t)
> > > (system::simple-parse-error (c)
> > > (declare (ignore c))
> > > nil)))
> > > PARSEABLE-INTEGER-P
> > > [2]> (PARSEABLE-INTEGER-P "10")
> > > T
> > > [3]> (PARSEABLE-INTEGER-P "1A")
> > > NIL
> > > [4]> (parseable-integer-p "A")
> > > NIL
> > > [5]>
> >
> > > > On Dec 13, 1:01 pm, Rainer Joswig <······@lisp.de> wrote:
> > > > > In article
> > > > > <····································@b1g2000pra.googlegroups.com>,
> >
> > > > > "lee.crabtree" <············@gmail.com> wrote:
> > > > > > Is there a way to tell if a string as a whole can be parsed as a
> > > > > > number? In the specific case I'm working on, I only need to make sure
> > > > > > a string can be parsed as an integer, but I have no doubt that there's
> > > > > > a general purpose solution.
> >
> > > > > > I know about PARSE-INTEGER, but the main problem is that it just bombs
> > > > > > out if there's a problem, and it returns success as soon as it finds
> > > > > > an integer value. That is,
> >
> > > > > > (parse-integer "1A")
> >
> > > > > > returns successfully, and instead of NIL,
> >
> > > > > > (parse-integer "A1")
> >
> > > > > > signals a SIMPLE-PARSE-ERROR.
> >
> > > > > > My attempt at figuring this out returned T no matter what was passed
> > > > > > to it, even NIL. Here's where I got:
> >
> > > > > > (defun parseable-integer-p (string-num)
> > > > > > (handler-case
> > > > > > (progn
> > > > > > (parse-integer string-num :junk-allowed nil)
> > > > > > t)
> > > > > > (system::simple-parse-error (c)
> > > > > > (declare (ignore c))
> > > > > > nil)))
> >
> > > > > > No matter what I pass into that, T is returned. I'm using CLISP
> > > > > > version 2.43.
> >
> > > > > > Any ideas?
> >
> > > > > > Lee Crabtree
> >
> > > > > Works for me in CLISP 2.41 on an Intel Mac.
> >
> > > > > --http://lispm.dyndns.org/
> >
> > --http://lispm.dyndns.org/
--
http://lispm.dyndns.org/
Curiouser and curiouser...
If I enter the function directly into the SLIME REPL, it works like it
should. However, if it's in a file, use C-c C-k to compile and load
it, and then run it, it acts screwy again. It's only defined once in
the file. What the hell?
Lee Crabtree
On Dec 13, 2:56 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@i29g2000prf.googlegroups.com>,
>
> "lee.crabtree" <············@gmail.com> wrote:
> > Looks like it's something to do with either Emacs or SLIME. Running
> > CLISP straight from cmd.exe gave the expected results. What would
> > keep that from working?
>
> I don't know. You might want to ask on the SLIME mailing list.
>
>
>
>
>
> > Lee Crabtree
>
> > On Dec 13, 1:59 pm, Rainer Joswig <······@lisp.de> wrote:
> > > In article <····························@news-europe.giganews.com>,
> > > Rainer Joswig <······@lisp.de> wrote:
>
> > > > In article
> > > > <····································@i12g2000prf.googlegroups.com>,
> > > > "lee.crabtree" <············@gmail.com> wrote:
>
> > > > > Grrrrr.
>
> > > > > If I run it, I get T no matter what.
>
> > > > > (parseable-integer-p "1")
>
> > > > > returns T, which is right. However,
>
> > > > > (parseable-integer-p "A")
>
> > > > > returns T, which is wrong. Empty strings, strings with no numbers,
> > > > > strings of ALL numbers, long strings, short strings, and NIL all give
> > > > > back T.
>
> > > > > I can't imagine it would make a difference in this case, but I'm
> > > > > running on Windows, and using SLIME.
>
> > > Can you run it without SLIME? What would be the result then?
>
> > > > > Lee Crabtree
>
> > > > RJMBP:~ joswig$ clisp
> > > > i i i i i i i ooooo o ooooooo ooooo ooooo
> > > > I I I I I I I 8 8 8 8 8 o 8 8
> > > > I \ `+' / I 8 8 8 8 8 8
> > > > \ `-+-' / 8 8 8 ooooo 8oooo
> > > > `-__|__-' 8 8 8 8 8
> > > > | 8 o 8 8 o 8 8
> > > > ------+------ ooooo 8oooooo ooo8ooo ooooo 8
>
> > > > Welcome to GNU CLISP 2.41 (2006-10-13) <http://clisp.cons.org/>
>
> > > > Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> > > > Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> > > > Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> > > > Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> > > > Copyright (c) Sam Steingold, Bruno Haible 2001-2006
>
> > > > Type :h and hit Enter for context help.
>
> > > > [1]> (defun parseable-integer-p (string-num)
> > > > (handler-case
> > > > (progn
> > > > (parse-integer string-num :junk-allowed nil)
> > > > t)
> > > > (system::simple-parse-error (c)
> > > > (declare (ignore c))
> > > > nil)))
> > > > PARSEABLE-INTEGER-P
> > > > [2]> (PARSEABLE-INTEGER-P "10")
> > > > T
> > > > [3]> (PARSEABLE-INTEGER-P "1A")
> > > > NIL
> > > > [4]> (parseable-integer-p "A")
> > > > NIL
> > > > [5]>
>
> > > > > On Dec 13, 1:01 pm, Rainer Joswig <······@lisp.de> wrote:
> > > > > > In article
> > > > > > <····································@b1g2000pra.googlegroups.com>,
>
> > > > > > "lee.crabtree" <············@gmail.com> wrote:
> > > > > > > Is there a way to tell if a string as a whole can be parsed as a
> > > > > > > number? In the specific case I'm working on, I only need to make sure
> > > > > > > a string can be parsed as an integer, but I have no doubt that there's
> > > > > > > a general purpose solution.
>
> > > > > > > I know about PARSE-INTEGER, but the main problem is that it just bombs
> > > > > > > out if there's a problem, and it returns success as soon as it finds
> > > > > > > an integer value. That is,
>
> > > > > > > (parse-integer "1A")
>
> > > > > > > returns successfully, and instead of NIL,
>
> > > > > > > (parse-integer "A1")
>
> > > > > > > signals a SIMPLE-PARSE-ERROR.
>
> > > > > > > My attempt at figuring this out returned T no matter what was passed
> > > > > > > to it, even NIL. Here's where I got:
>
> > > > > > > (defun parseable-integer-p (string-num)
> > > > > > > (handler-case
> > > > > > > (progn
> > > > > > > (parse-integer string-num :junk-allowed nil)
> > > > > > > t)
> > > > > > > (system::simple-parse-error (c)
> > > > > > > (declare (ignore c))
> > > > > > > nil)))
>
> > > > > > > No matter what I pass into that, T is returned. I'm using CLISP
> > > > > > > version 2.43.
>
> > > > > > > Any ideas?
>
> > > > > > > Lee Crabtree
>
> > > > > > Works for me in CLISP 2.41 on an Intel Mac.
>
> > > > > > --http://lispm.dyndns.org/
>
> > > --http://lispm.dyndns.org/
>
> --http://lispm.dyndns.org/
thus spoke lee.crabtree <············@gmail.com>:
> I don't know enough about CLISP to know what kind of optimizations it
> can perform, but I realized that since PARSE-INTEGER doesn't have a
> side effect and isn't the returning expression, it could be considered
> safe to optimize away. As a quick test, I added this:
> (when (parse-integer string-num :junk-allowed nil)
> ...
> And it worked.
Looks like a grave bug in the optimizer.
--
mirrors are more fun than television
From: Richard M Kreuter
Subject: Re: numerical string predicates
Date:
Message-ID: <87aboew6do.fsf@progn.net>
"lee.crabtree" <············@gmail.com> writes:
> Is there a way to tell if a string as a whole can be parsed as a
> number? ... I know about PARSE-INTEGER, but the main problem is that
> it just bombs out if there's a problem, and it returns success as
> soon as it finds an integer value. That is,
>
> (parse-integer "1A")
>
> returns successfully, and instead of NIL,
PARSE-INTEGER returns two values: the integer parsed (or NIL), and the
index of the first invalid character seen.
(parse-integer "1A" :junk-allowed t)
=> 1
=> 1
So by comparing the second value to the length of the string, you can
tell whether the parse reached the end of the string (or an END
argument, if you use one):
(defun parse-integer-or-bust (string &key (radix 10) (start 0) end)
(multiple-value-bind (integer stop)
(parse-integer string :start start :end end
:junk-allowed t :radix radix)
(and (= stop (or end (length string))) integer)))
=> PARSE-INTEGER-OR-BUST
(parse-integer-or-bust "x12y")
=> NIL
(parse-integer-or-bust "x12y" :start 1)
=> NIL
(parse-integer-or-bust "x12y" :start 1 :end 2)
=> 1
(parse-integer-or-bust "x12y" :start 1 :end 3)
=> 12
lee.crabtree wrote:
> Is there a way to tell if a string as a whole can be parsed as a
> number? In the specific case I'm working on, I only need to make sure
> a string can be parsed as an integer, but I have no doubt that there's
> a general purpose solution.
A number of solutions have been proposed using parse-integer itself to
answer the question. But the stated question was not to parse the
string as an integer, but only whether the given string could be parsed
as an integer without error.
If you have a regular expression package available in your
implementation you could test with this predicate:
(regexp:match-re "^\\s*[+-]?[0-9]+\\s*$" string)
This works in Allegro, but but should work the same using cl-ppcre in
any other ANSI CL.