[M3devel] cm3 llvm backend?

[Jay K]

Integers and floats are not the universal types that all programmers should know about, and no others.


Each code base has types it deals with and functions over those types.


The type of

 a + b 


is just as clear or unclear as the type of:


 Add(a, b) 


 or, close: 


 Foo.Add(a, b) 


 The last is arguably most clear, the type is *probably* Foo.T. 


 but none of the cases are particularly clear, and far from all code 
 is written in this Foo_Add or Foo.Add fashion. 


 Plus the problem of mixing types. 


 VAR a,b,c:Foo.T; 
 b := Foo.Add(a, b); 
 c := Foo.AddI(a, 1); 

 (See there, I expanded to name overloading, this should be: 

 c := Foo.Add(a, 1); 
 or simply 
 c := a + 1;
 )
 
Keep in mind, that not only are integers and floating point numbers not the
sole and central types, but I can implement other "numbers".

What if I have a multiprecision arithmetic library?

Using "+" is very natural there.


Giving it a longer name like Add hurts, doesn't help.


Context is critical, and there is no one small context that suffices.

What if I could say:

a.+(b)

? Is that also bad?


Now, I'm actually very open minded and somewhat torn on the matter.


I am faced with a very large code base, and plain text search with
very little language awareness.


In that situation, C is actually advantageous.


Indeed I don't search for "+" or "add", but specifically Foo_Add.


Some argue that an IDE lets me just hover over some identifier and it shows
me the type. But this does not scale. IDEs do not scale.
 (Not to mention that I don't use one...)
Plain text search does scale.
I believe language aware search can scale, but not everybody is using
that yet. Modula-3 was ahead here, with the .M3WEB/Reactor stuff.
It should have been pitched, imho, for its browsing/reading, not for its
editing/development, at least as far as it got -- apparently browser-based
development is viable these days.


And also preprocessor token pasting is a bit of an enemy of plain text search.


Also, I would have found Modula-3 and/or Quake much clear if they had used "+"
for string concatenation, instead of ampersand.


Context is kind of a sliding scale.
Sometimes I have a lot, sometimes very little.
Code presentation should perhaps adapt based on its viewer, but that is a fantasy,
as code presentation is stuck in plain text, as directly typed by a human.
Nobody is yet editing or viewing an abstract representation.


Anyway, I'm well aware that there are a fair number of people on both sides
of these positions. 


 - Jay


________________________________
> From: lists at darko.org 
> Date: Wed, 29 Jun 2016 00:39:17 +0200 
> To: jay.krell at cornell.edu 
> Subject: Re: [M3devel] cm3 llvm backend? 
> CC: m3devel at elegosoft.com; rodney.m.bates at acm.org 
> 
> 
> 
> On Tue, Jun 28, 2016 at 11:34 PM, Jay K 
> <jay.krell at cornell.edu<mailto: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<mailto:wagner at elegosoft.com> 
>> To: rodney.m.bates at acm.org<mailto:rodney.m.bates at acm.org> 
>> CC: rodney_bates at lcwb.coop<mailto:rodney_bates at lcwb.coop>; 
> jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>; 
> m3devel at elegosoft.com<mailto: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<mailto: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<mailto: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