[M3devel] cm3 llvm backend?

[Daniel Alejandro Benavides D.]

Hi all:it depends, Cardelli has stated in an interview the type system was the top part thing of language designers at its time. I recall SPwM3 states also that they video recorded all design sessions, though provably these would not be very attracting to the new modula-3 programmer or computer scientists (instead of it, discouraging). 
Probably the safety and simplicity were user/programmer priorities
Thanks in advance
 

    El Martes 28 de junio de 2016 17:39, Darko Volaric <lists at darko.org> escribió:
 

 



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




_______________________________________________
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/20160628/cfe637af/attachment-0003.html>