[M3devel] operator overloading?

[Daniel Alejandro Benavides D.]

Hi all:
perhaps in behalf of this issue, one remembers the rules for the type inference algorithms are of variable complexity depending on the semantics or what one calls meaning but also syntaic aids, not like syntatic sugared language constructs but syntax directed checking, and if you want to look an example please look at javascript type inference vs Obliq Modula-3 runtime type inference (which uses m3tk lib by the way), it tourns out that the semantics (object oriented dynamically typed based languages) are quite different in terms of type checking, i.e given Obliq algorithm may checks up to in O[n^5] order but could be less according to certain conditions but in terms of the javascript kernel considered in an research work is not that quick by now, but remains in general as an open issue, perhaps waiting for someone who gets a Turing Award for it ( see http://jiangxi.cs.uwm.edu/publication/js.pdf )
Please consider no just simplicity of our thoughts but of our algorithms, specially when someone has code that already dependends on parsing Modula-3 statements all the day long by many millions of instruction per second.
Thanks in advance 

--- El dom, 21/11/10, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] operator overloading?
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 21 de noviembre, 2010 15:56
> 
> 
> Jay K wrote:
> > Rodney, what if the signatures of overloaded operators
> is "fixed".
> > That is + can only take two T's and return one T.
> > < can only take two T's and return one boolean.
> > 
> 
> That is one of the ways that would greatly simplify the
> semantics.
> It would also make it more difficult for programmers to
> define
> operator meanings with no resemblance to traditional
> mathematical
> meanings of the operators, which I regard as really bad
> practice,
> but is encouraged by the overloading systems I know about.
> 
> > 
> > No implicit conversions.
> >   (I do think some conversions are ok,
> integers to wider integers, but nobody else agrees.)
> 
> We already have something far better than implied
> conversions.  We have
> assignability, which, simplified, says that in a lot of
> assignment-like
> contexts, what is needed is that the RHS _value_ must be a
> member of the
> LHS's _type_.  The types are not necessarily disjoint,
> so there are lots
> of cases where this accomplishes something.  Enforcing
> this requires a
> mix of static and runtime rules.  Obviously, if the
> RHS type is disjoint
> with the LHS type, that is statically know to be illegal.
> 
> When it's legally assignable, Modula-3 doesn't call it a
> type conversion.
> This is higher-level and more abstract.  There may
> well be an implied
> _representation_ conversion, for example, different sizes
> of integers.
> Most (all?) other languages require that every different
> machine-level
> representation be a different type, and this creates a need
> for
> programmer-awareness of lots more type conversions,
> implicit or explicit,
> than the Modula-3 approach
> 
> We didn't get assignability between INTEGER and LONGINT,
> but we have
> it between a base ordinal type and all its subranges and
> all their
> packed types (subject to value inclusion.) as well as
> several other
> cases.
> 
> > Isn't that much simpler than any other language does
> it?
> 
> I think it can be a lot simpler than any other
> language.  There is
> still a _lot_ of unanticipated detail.
> 
> > Are the rules still hard to understand?
> >   (And I believe this is still fairly
> valuable.)
> > 
> > 
> > Furthermore, something like, maybe, the operators may
> only be defined in the interface that declares T?
> > Or maybe, the operators are always available on all
> types, but you get a link error if they weren't defined?
> > 
> 
> I can think of another visibility rule, but it derives from
> other things
> I would have to describe first.
> 
> > 
> > And of course, you can't define them for builtin
> types. They are already defined.
> > 
> 
> Yes, I would strongly support that rule.  (Did you
> know Ada does not?)
> 
> > 
> > And, I realize, there is a question of errors.
> > + can fail.
> > The interface would have to that they raise
> exceptions.
> > You could have something like FPU.i3 custom per type
> to control it. The compiler
> > wouldn't know about this (except maybe for builtin
> LONGINT).
> > 
> 
> I think exception raising can be kept orthogonal to
> operator overloading by
> defining an operator expression (once resolved to a single
> function) as
> equivalent to an ordinary call.  In fact, everything
> except determining
> what function is to be called can be defined by an
> equivalence to an
> ordinary call of that function.
> 
> > 
> >  - Jay
> > 
> > 
> >  > Date: Sun, 21 Nov 2010 13:52:08 -0600
> >  > From: rodney_bates at lcwb.coop
> >  > To: m3devel at elegosoft.com
> >  > Subject: Re: [M3devel] operator
> overloading?
> >  >
> >  > I've been around that block too many times
> with Ada and C++. Programmer-
> >  > defined overloading (either operator and/or
> function name) is a semantic
> >  > disaster. It interacts with stuff all over
> the language, and the complexity
> >  > just explodes. I have spent several years
> of my life having to learn every
> >  > in and out and dark corner of overloading
> and all its fallout in Ada, both
> >  > to implement it and to try to help working
> programmers cope with it. I can
> >  > say with complete confidence that Ada would
> be half the size/complexity
> >  > it is, without it.
> >  >
> >  > Moreover, hard as it is for a compiler
> writer or language lawyer to understand
> >  > it, it is even worse for the everyday
> programmer. Again, I can testify that
> >  > almost nobody (the above types excepted)
> comes anywhere close to understanding
> >  > the rules. They don't even want to try.
> Their eyes glaze over, and they just
> >  > want you to tell them how to code
> such-and-such so it will compile and call
> >  > the function they want it to. For the
> future, all they want is restrictive
> >  > but simple programming guidelines on things
> to avoid unconditionally, so they
> >  > won't keep getting burned again and again.
> >  >
> >  > C++'s take on overloading is simpler in
> some respects, more complicated in
> >  > others, but overall, quite a bit worse and,
> I dare say, much poorer-understood
> >  > by working programmers.
> >  >
> >  > The upshot is that the (mis)feature of
> programmer-defined overloading is mostly
> >  > used only in degenerate and trivial ways.
> This, of course, raises the question
> >  > what good is it when: 1) it makes
> programming more difficult, 2) programmers
> >  > avoid most of it anyway, and 3) even so, it
> results in lots of code that
> >  > programmers just barely hope they
> understand the meaning of what they wrote.
> >  > The latter is a *very* big deal in quality
> of released code. And I didn't even
> >  > mention the added difficulty in
> implementing the language.
> >  >
> >  > I do realize that function call notation
> can be a lot harder to read (and write)
> >  > than operator notation in a few situations.
> I've also been around that block more
> >  > times than one, in fact quite recently.
> >  >
> >  > I have many times mused over whether it
> would be possible to add something that
> >  > would give the most important benefits and
> not be a complete semantic train wreck.
> >  > Sometimes I think it could be done a lot
> better than we have seen, but at best,
> >  > it would be a significant semantic
> complication, even if restricted to operators
> >  > only.
> >  >
> >  > In Modula-3, we have a language whose most
> distinctive characteristic is an
> >  > exceptionally high ratio of useful stuff to
> complexity. AFAIK, there is no other
> >  > language that comes close by this
> criterion. We need to preserve that.
> >  >
> >  > Rodney Bates
> >  >
> >  >
> >  > Jay K wrote:
> >  > > Is it really so difficult to add
> operator overloading to the language?
> >  > >
> >  > > From a user's point of view, I know it
> is very useful in certain
> >  > > situations.
> >  > >
> >  > >
> >  > > - Jay
> >  > >
> >  > >
> >  > >
> >  > >
>