[M3devel] cm3 llvm backend?

[Darko Volaric]

On Tue, Jun 28, 2016 at 11:34 PM, Jay K <jay.krell at cornell.edu> wrote:

>  I find myself on the other side of this.
>  There are many people on both sides.
>
>  There are countless examples.
>
>
>   Here are two.
>
>
>  People don't like operator loading.
>
>  They don't want me to write
>
>  string operator+(string, string);
>
>
>  but nobody seems to mind:
>
>
>  float f = 1.0 + 2.0;
>   int i = 1 + 2;
>
>   why is + ok on floats and ints, overloaded, but not user defined types
> such as string?
>
>
>


The notion that limited fixed operator overloading justifies unlimited user
operator overloading is an asinine argument. The former you can easily keep
in your head, since the rules are simple and clear. You know given a + b +
c + 1.0 that a, b and c are floating point values, or if you didn't have
the literal you'd know by knowing the type of one value.

But given user overloading, what is the type of a + b + c + 1.0 or some
other expression? You have to know what the type of each value is, you need
to know the definitions of the overloads for each type pair, you have to
work out what the precedence and associativity rules are so you're
evaluating the expression correctly and you have to know the type that each
overloaded operator returns and work out what the new type pairs are at
each stage of evaluation of the expression.





>  People don' t like type inferencing.
>
>    auto a = 1.0 + 2.0;
>    auto b = 1 + 2;
>
>  Modula-3 has this more than C and C++98 already, so maybe people here
> don't mind.
>
>   VAR a := 1.0 + 2.0;
>   VAR b := 1 + 2;
>
>  In either case, nobody seems to mind temporaries without explicit types
> in function calls or more generally subexpressions.
>
>  F(1 + 2);
>  F2(1.0 + 2.0);
>
>

Again, this is "type inference" in the most simplistic case and hardly
justifies unbounded type inferencing. The static type pf every expression
(and subexpression) is known in M3, merely using it introduces no
complexity. The static type is easily determined because the rules for
determining the type of any expression are small, fixed, simple and strict.


If you really want to understand type inferencing and overloading, have a
look at the Swift programming language. You'll find yourself writing an
innocuous expression and the compiler will tell you that the expression is
"ambiguous" or "too complex" even though there doesn't seem any other way
to interpret the expression or it involves only one operator/type combo
used more than once. What the compiler is really telling you is that it
can't infer the type of some subexpression or choose the right method and
you must now start applying casts to make it obvious (this doesn't always
work and sometimes you have to rewrite it wholesale). Why does this happen?
Because Swift allows you to overload functions and operators based on
parameter type and return type.



You say "people are on both sides of this" but good design isn't a
democracy or a popularity contest. If you walk around downtown San
Francisco you can find many people who will agree with you. You will also
find as many people who claim that the government is beaming thoughts into
their heads via satellite. How people feel about language features and the
fact that they are untroubled by C++ and its misfeatures is not a logical,
convincing argument.

The stated design goals for M3 is simplicity and safety, not feature
richness or novelty. That should be what guides any discussion of M3
language design.




>
>  - Jay
>
>
> > Date: Tue, 28 Jun 2016 22:15:25 +0200
> > From: wagner at elegosoft.com
> > To: rodney.m.bates at acm.org
> > CC: rodney_bates at lcwb.coop; jay.krell at cornell.edu; m3devel at elegosoft.com
> > Subject: Re: [M3devel] cm3 llvm backend?
> >
> > On Tue, 28 Jun 2016 11:40:06 -0500
> > "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:
> >
> > > On 06/27/2016 08:03 PM, Jay K wrote:
> > > > > A teacher of mine called this behavior "version junkie".
> > > >
> > > >
> > > > There are at least two big reasons for this.
> > > >
> > > > - The language really is improving. Programs
> > > > written in the newer language are easier to read
> > > > and often easier to optimize and sometimes easier
> > > > to implement a compiler for.
> > >
> > > Sometimes so, sometimes not. Sadly, many language "features" reflect
> > > an implicit but very misguided belief that fewer keystrokes/characters
> > > means increased readability. Or at least that writability is more
> > > important than readability. So often, this means actual code is less
> > > explicit. But this makes maintenance far worse.
> > >
> > > E.g., Ada decided use parentheses for both actual parameter lists to
> > > function calls and subscript lists to arrays. Along with optional
> > > implicit operations like dereferencing, there are somewhere in the
> > > teens of possible meanings for the innocent looking "f(x)". I have
> forgotten
> > > the exact number, but once had to do the semantic analysis. That was
> > > Ada 83. Maybe more have been added since. For the poor schmuck who
> > > gets called at 3:00 AM to fix a bug in half a million lines of code
> > > she didn't write, this is a readability disaster. The savings of
> > > keystrokes in not making the operations explicit is penny-wise and
> > > million-pound foolish.
> >
> > I couldn't agree more with this. My focus seems to have moved away from
> > programming to reading and analyzing code, too. Often it is almost next
> > to impossible for me to find the exact meaning or definition of an
> > expression or call without knowing all the other code which is not
> > obviously related to the location in question.
> >
> > I would favour longer explicit syntax and clear meaning above
> > shorter expressions any time.
> >
> > Olaf
> > --
> > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
> > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86
> 95
> > Geschäftsführer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> DE163214194
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160629/799364ea/attachment-0003.html>