Robert Virding wrote:
> Steven H. Rogers, PhD. wrote:
>>> Excellent idea. I like array oriented languages like APL/J/K for
>> their overloading for arrays of arbitrary depth (actually lists of
>> lists for K). Not to seem greedy, but if Erlang were to be extened to
>> apply arithmetic operators to tuples, what about lists? Even better
>> would be to handle any conformal data structures composed of lists and
>> tuples.
>>>> Steve
>>> Yes, Basic!! This would be real progress.
>> Seriously though this would mean that "ABCD" + 32 -> "abcd". If we are
> going to do this we might as well go all the way and be consistent (I am
> big beliver in consistency*) and always coerce arguments into something
> which can be operated on. The results might be confusing.
>> Sorry for being a little sarcastic here but I think it is a very bad idea.
>> On a serious note though when Jonas Barklund and I were discussing BIFs,
> replacing imports with synonyms and determining which function gets
> called (Proposal 16) we came up with an idea that would solve this
> problem very elegantly (even Richard O'K would approve). +-*/ etc would
> be synonyms for number:'+'/2 etc (they are this today for erlang:'+'/2)
> and thye could instead be made synonyms for say matrix_arith:'+'/2 etc.
> This would allow using the operators, leave the originals alone and be
> clean and explicit about what they call.
>> Robert
>> *At my age I value consistency, I haven't enough time to look up in a
> manual every time I use something to see what arguments it can handle
> today.
>>Extending arithmetic to tuples shouldn't be too conceptually challenging
to the user, though there would obviously be implementation issues. It
can simplify some algorithms and facilitate manipulation of bulk data.
Isolating it to a module or package and using synonyms seems like a
reasonable approach for Erlang.
Steve
--
_ Steven H. Rogers, PhD.
<_` email: steve@REDACTED
|_> Weblog http://shrogers.com/portal/Members/steve/blog| \ "A language that doesn't affect the way you think about
programming is not worth knowing." - Alan Perlis