[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [scheme-reports-wg1] Unintended consequences of #319
- To: leppie <xacc.ide@x>
- Subject: Re: [Scheme-reports] [scheme-reports-wg1] Unintended consequences of #319
- From: Alex Shinn <alexshinn@x>
- Date: Wed, 11 Apr 2012 17:16:06 +0900
- Cc: scheme-reports-wg1@x, scheme-reports@x
- In-reply-to: <CAOLEvS3z0v+zo=iX56THJn64pfgT0A7++=D+LstdHqNxiy+o9w@mail.gmail.com>
- References: <20120410175957.GH2591@mercury.ccil.org> <CAMMPzYMejmEzX34f8WxgqfL8ADKFrjTN3401hj2+Za=bJYq9+w@mail.gmail.com> <CAOLEvS3z0v+zo=iX56THJn64pfgT0A7++=D+LstdHqNxiy+o9w@mail.gmail.com>
On Wed, Apr 11, 2012 at 1:24 PM, leppie <xacc.ide@x> wrote:
>> R5RS doesn't have such permission - it has permission
>> to return #f when the string has _any_ radix prefix, and
>> in a number of other cases related to incomplete numeric
>> towers. What we explicitly voted on is that these must
>> be unified with `read` behavior. I don't think this is an
>> unintended consequence.
>
> What will (string->number "#x10" 8) return?
>
> I think the issue is with ambiguity.
That would be an argument for returning #false
on mis-matched radixes as John suggested, not
on just returning #false for any radix prefix as
R5RS specifies.
Personally I don't think the ambiguity is a big
issue - the radix prefix in the string is later and
I don't think people would be surprised that it
acts as an override for the radix argument. I.e.
your example should naturally return 16.
--
Alex