On 5/7/07, Robert Dodier <robert.dodier at gmail.com> wrote:
>
> On 5/7/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
>
> > Yes. Exactly the same objections as last time: that it would be a bad
> idea
> > to change the interpretation of strings like a (a symbol), 1b2 (a
> bfloat),
> > and 2e3 (a float) when ibase changes.
>
> Yes. So what? If I don't want to reinterpret some symbols as numbers,
> I won't change ibase.
Presumably the user who changes ibase wants to be able to use the rest of
the system as much as possible as it was before.
There are lots of global variables which can cause some code to fail.
> simp:false would cause lots of things to break. Yet the continued
> existence of the simp flag doesn't seem to cause trouble, and it's
> actually useful sometimes.
Yes. Setting simp:false causes many things to break, but in some sense you
expect them to break. I would like to be able to continue working normally
even if I've set the input base to something > 10 (ibase < 10 is not a
problem, of course).
> In regular, parsed, input, tokens starting with initial 0 are parsed as
> > numbers, so in ibase=2^4:...
> I'm not entirely opposed to this.
Well, OK, what do others think? Remember, the initial 0 in this proposal
does NOT change the meaning of the digits (in some languages it forces
interpretation as octal, for instance) -- it simply says to Maxima that any
following valid digit-characters will be interpreted as part of the number.
> That there be a separate "read" function (read_integer, say), which reads
> > one integer in the current input base:
> Another there's-someone-at-the-console function. Uh oh.
>
Yeah, sometimes that is necessary. But I agree that read-from-file and
read-from-string functions are more fundamental. If you have a file full of
hex numbers you want to read, you don't want to have to edit the file to add
leading zeroes everywhere.
-s