On Mon, Feb 07, 2005 at 06:38:34AM -0800, Shawn Garbett wrote: > That was my point, to make the default + operator > dislikeable, but useable. Then a programmer is hit > with a compile error, he goes and looks up the > documentation, discovers he should most likely chose > between two other operators. Using the + operator is > something that most people who are new to the > environment will take for granted, when in fact there > are really two primary choices. It's a social > engineering approach to keeping a new programmer on > track and not allowing them to fall into old habits.
But people *like* their habits. One thing that I like with Java is the explicit specification in function definitions of all exception types that the function is permitted to throw. It seems to me that such a definition is quite in line with the bitc philosophy. It forces one to think hard about error conditions. So make operations throw a specific type of exceptions, and force the programmer to acknowledge and handle that. One could relax the requirement when the compiler can prove that the variable can never overflow. This way the new programmer gets hit with "oh yeah, I forgot to take that case into account, the language won't let me ignore it, now what do I do if it overflows?" instead of grumbling about "the language that doesn't even have simple addition". > The shorthand thing is a good idea, which brings the > whole discussion back around to +%, -%, *%, etc. for > the wrap around or ring version. This was in the > original proposal. Speaking for myself, I intuitively understood what the operator was when I saw it the first time. a /% b = a modulo b a +% b = (a+b) modulo maximum of datatype a -% b = (a-b) modulo maximum of datatype a *% b = (a*b) modulo maximum of datatype seems nice in a reference manual. > One would need something for the exception version I'm for keeping the normal one. I feel that places where overflow is an error rather than expected are much more common, everywhere except real hardware-aware programming (and when I did that I was always grumblig about the C hoops I had to jump through at every simple math operation). -- #include <std_disclaim.h> Lorens Kockum _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
