Case sensitivity (was Conjugate is weird)

--- Stavros Macrakis <stavros.macrakis@verizon.net> wrote:
> James> -- In my opinion, we should
> James>    a) Make Maxima totally case sensitive.
> James>    b) Make the Maxima built-in functions lower case.
> 
> The problem with case sensitivity is that Maxima is between two
> worlds: the mathematical world and the programming world.

That raises an interesting point - should we be thinking in terms of
programmers or mathematical users?  I personally think we should think
mathematical interactive use first, but maybe that should be the job of
the front end, and have the back end (which realistically is all we've
got right now) think more in programmer terms.  However, I won't argue
that the command line will likely see more programming use.  See below
for a possible way out.

> In math, many typographical attributes are used to distinguish names.
> Besides (R-r), math uses boldface for vector quantities, outline-face
> for sets, Greek letters for angles, etc.  Maxima is terribly
> impoverished this way, and doesn't even have any conventions for
> representing such things (e.g. that bold_v displays a boldface v in
> formatted output).

I think eventually we will have to do something about that, but my
guess is we will be at GUI stage before we really need to handle it. 
Right now most of our front ends don't handle very much formatting.

> In the programming world, we mostly use multi-letter names.  Many
> languages nowadays are case-sensitive, so in theory you could have
> distinct identifiers Foo, foo, FOO, and even for that matter fOo,
> foO, and FoO.  But everyone would agree (right?) that this would be 
> poor practice.  

Poor programming practice, yes.  But not necessarily in things like
scientific descriptions for classrooms - if the book is using FOO to
represent a vector and foo to represent a scalar, you want to make your
worksheets/whatever work like that.

> Instead, case is typically used to mark word boundaries,
> e.g. PacketSend has something to do with sending a packet, and not 
> with the end of packets (that would be PacketsEnd).  In the Maxima 
> context, you would expect DefiniteIntegral (or Definite_Integral) 
> using this convention, not definiteintegral or the current defint.
> 
> Anecdotally, case sensitivity in programs is known to be error-prone
> for both beginners and experienced users.  Bob Frankston, a Multics
> alumnus and the co-inventor of VisiCalc, once said it was the biggest

> mistake that Multics had inflicted on the world.  There is also 
> usability research backing him up: "We don't need any more 
> case-sensitive computers" (Jakob Nielsen at useit.com).  Guido von 
> Rossum (Python inventor), based on experience teaching newcomers, has

> come to think the same -- that case sensitivity is fine for geeks,
but 
> not for a broader audience.

If I understand correctly, defint will still be defint and integrate
will still be integrate - if someone types Integrate we can prompt them
to type integrate.  What problems to you forsee?

> I am not sure what the right answer is.  Just because we geeks are
> used to the Multics/Unix/C/Java way of doing things doesn't mean it's

> the right way to do them.  In fact, I'm pretty sure 
> Multics/Unix/C/Java got that one wrong and Visual Basic (!) got it 
> right.  Then again, maybe our target audience really *is* geeky.

I'm thinking yes.

> I suspect that the right thing to do is to find a simple, consistent
> convention that will work for a wide variety of typographic variants,
> e.g. bold_a.  But that would probably make (R-r) unacceptably clumsy
> (capital_r - r).

There might be another way to handle it - we might make the low level
processing system in maxima behave the way the programmers would like
it to, and have the front end handle the user visible formatting like
that.  It could be the front end's job to translate the formatted stuff
to code the low level maxima can understand, like R -> capital_r.

Or, if people really want case insensitive, we could add a toggle where
Maxima automatically makes all input lower case for evaluation.  I
think case sensitivity has uses, but perhaps we can allow a "case
insensitive" mode?  As I understand it, the main reason we want case
sensitivity is to allow users to use it for things like constants and
variables, not to use for programming Maxima itself.  We plan to
convert the source to all lower case, and I don't see why we should
need case for internal programming.  We want it only at a user level,
correct?  So why not be default case sensitive but allow those who are
annoyed by it to turn it off?

> What if we make only the *first* letter's case be significant?  We
> would consider r and R distinct, and also radius and Radius, but not
> radiusr and radiusR?  (Though we would always *preserve* case.)  That

> seems pretty ugly, too.

My thought is this would just confuse the user.  I vote we allow only
two modes - either fully case sensitive or fully case insensitive, and
allow the user to decide at session level.  Maxima code itself would be
written in lower case in every possible instance.

> So though I do agree that the present situation is a mess, I am
> firmly... undecided as to which way to go next.  I would like to hear
> more discussion on the topic.

When there's a case like this where there's not a lot of consensus, I
think we should look for a way to accomidate both positions.  I don't
think it is essential we force everyone to write their input one way or
the other.  Even in a case sensitive system people could in theory do
everything in lower case.  The problem is they would have to be careful
not to make mistakes.  Why not just have a routine that, when turned
on, makes everything lower case when sent to Maxima, so users working
in that style don't have to worry?  Is there a reason that wouldn't
work?

CY

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com