jscheme-user

[Jscheme-user] string->number problem

[Ken A. <kan...@bb...>]

Now we can't parse a number with a leading "0" even if we say base 10.
> (string->number "08")
#f
> (string->number "08" 10)
#f
> (string->number "8" 10)
8

Can we make this base 8 stuff optional?  Usually when i see a leading 0 in data it is expecting to be interpreted as base 10.  For example May is month "05".

k

[Jscheme-user] string->number problem

[Jonathan A R. <ja...@mu...>]

This discussion wasn't clear to me but I assume you're going to have
  (string->number "011" 8) => 9
  (string->number "011" 10) => 11
So the question is what to do about
  (string->number "011")
My vote as usual is when in doubt follow a Scheme report, because
someone might consult a report when using jscheme.  If you want to
have something to parse Java literal syntax, give it a different name;
then you could sensibly extend it to other kinds of literals, e.g.
 (parse-java-literal "true") => #t
 (parse-java-literal "'t'") => #\t
 (parse-java-literal "\"true\"") => "true"
But if the Java literal parser has to have the name string->number
either for backward compatibility or to suit your taste, that's not
terrible; I always give it an explicit radix anyhow.

Jonathan

Re: [Jscheme-user] string->number problem

[Ken A. <kan...@bb...>]

What you say about string->number is the way i expected it to be have too.
parse-java-literal would be a good extension.  I think the code is now built in to InputPort.  This might be a good place to put it all together and fix other problems.

k

At 10:27 AM 5/30/2004 -0400, Jonathan A Rees wrote:
>This discussion wasn't clear to me but I assume you're going to have
>  (string->number "011" 8) => 9
>  (string->number "011" 10) => 11
>So the question is what to do about
>  (string->number "011")
>My vote as usual is when in doubt follow a Scheme report, because
>someone might consult a report when using jscheme.  If you want to
>have something to parse Java literal syntax, give it a different name;
>then you could sensibly extend it to other kinds of literals, e.g.
> (parse-java-literal "true") => #t
> (parse-java-literal "'t'") => #\t
> (parse-java-literal "\"true\"") => "true"
>But if the Java literal parser has to have the name string->number
>either for backward compatibility or to suit your taste, that's not
>terrible; I always give it an explicit radix anyhow.
>
>Jonathan
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] string->number problem

[Timothy J. H. <ti...@cs...>]

On May 28, 2004, at 10:44 AM, Ken Anderson wrote:

> Now we can't parse a number with a leading "0" even if we say base 10.
>> (string->number "08")
> #f
>> (string->number "08" 10)
This is clearly not good. I'll fix it!

> #f
>> (string->number "8" 10)
> 8



>
> Can we make this base 8 stuff optional?
We can back out these changes for now if it is causing backward 
compatibility problems....

>  Usually when i see a leading 0 in data it is expecting to be 
> interpreted as base 10.  For example May is month "05".
We could go back to the original interpretation and have 08 be 
converted to 8.0....

The problem here is that a program can contain
     0100
and we wouldn't know whether they meant that in base 8 or base 10.
The only time a leading zero number would be base 10 is if it happens 
to contain an 8 or 9,
this seems like it could generate hard to catch bugs!

One nice thing we've done with Jscheme is have the literal syntax be 
almost exactly the same
as Java literal syntax. This makes it easy for Java programmers (and 
easy for us as we don't have
to write a special manual about the syntax of literals).

We also have a Scheme literal mode
   (set! jsint.U.useJavaMode #f)
which turns off the Java literal mode ....

For now, we could have a backward compatibility switch that reverts to 
the old style,
but I think for the future it will be easier for us if we stick to pure 
Java literal syntax..

>
> k
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] string->number problem

[Ken A. <kan...@bb...>]

OK, we can keep with Java litterals, but (string->number) should convert according to radix.  Can you fix that?  It's getting in the way of a release.

k

At 11:04 AM 5/28/2004 -0400, Timothy John Hickey wrote:

>On May 28, 2004, at 10:44 AM, Ken Anderson wrote:
>
>>Now we can't parse a number with a leading "0" even if we say base 10.
>>>(string->number "08")
>>#f
>>>(string->number "08" 10)
>This is clearly not good. I'll fix it!
>
>>#f
>>>(string->number "8" 10)
>>8
>
>
>
>>
>>Can we make this base 8 stuff optional?
>We can back out these changes for now if it is causing backward compatibility problems....
>
>> Usually when i see a leading 0 in data it is expecting to be interpreted as base 10.  For example May is month "05".
>We could go back to the original interpretation and have 08 be converted to 8.0....
>
>The problem here is that a program can contain
>    0100
>and we wouldn't know whether they meant that in base 8 or base 10.
>The only time a leading zero number would be base 10 is if it happens to contain an 8 or 9,
>this seems like it could generate hard to catch bugs!
>
>One nice thing we've done with Jscheme is have the literal syntax be almost exactly the same
>as Java literal syntax. This makes it easy for Java programmers (and easy for us as we don't have
>to write a special manual about the syntax of literals).
>
>We also have a Scheme literal mode
>  (set! jsint.U.useJavaMode #f)
>which turns off the Java literal mode ....
>
>For now, we could have a backward compatibility switch that reverts to the old style,
>but I think for the future it will be easier for us if we stick to pure Java literal syntax..
>
>>
>>k
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>_______________________________________________
>>Jscheme-user mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-user