<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div> > The savings of keystrokes in not making the operations explicit is penny-wise and million-pound foolish.</div><div><br></div><div>I hear this a lot.</div><div><br></div><div>There is a flip side.</div><div><br></div><div>There is such a thing as too verbose, or explicitly saying everything all the time is inefficient.<br> In fact, if we had to say everything, all the time, we'd instantly run out of space.</div><div><br></div><div>Requiring too much verbosity can be tedious and hide the important details in the noise of obvious repeated stuff.</div><div><br></div><div>Some balance must be found.</div><div><br></div><div><br>Consider:</div><div><br></div><div>C:<br> a = b</div><div><br></div><div>vs.<br> asssembly hypothetical:<br> mov ra, rb</div><div><br></div><div><br> "=" has become "mov r r" -- a large multiplication of noise that the human reader<br> has to sift through to see the meaning </div><div><br></div><div><br> or worse <br> mov r1, rsp[b] <br> mov rsp[a], r1 <br> </div><div><br></div><div> Is the assembly clearer because it is more explicit? </div><div><br></div><div> operator= can be overloaded <br> It means assignment, however the author of the types of a and b deemed appropriate </div><div><br></div><div> it might be on the order of 1-3 instructions, <br> or it might be a function call. </div><div><br></div><div>Ignoring performance, it doesn't matter. It is the right notation for "assignment".</div><div><br></div><div><br>We must pick local vocabularies or "context" and communicate within it.<br>It must be easy for a newcomer to step back and learn the vocabulary -- that<br>is probably the unsolved part.</div><div><br></div><div> And then I often read code, that reads like: <br> <br> // foo the bar</div><div><br></div><div> foo(bar) </div><div><br></div><div><br> I don't know what a "bar" is, I don't know what it means <br> to "foo" it, or why/when you would want to.</div><div><br></div><div><br> The pattern works in Modula-3, C, C++, etc. <br> even assembly</div><div><br></div><div> ; foo the bar<br> mov rcx, rsp[bar]<br> call foo</div><div><br></div><div> all equally gibberish to the newcomer. </div><div><br></div><div> Though to the initiated, assuming foo is at least a few lines of code, this is probably the right level to code at.</div><div><br> - Jay<br><br><br><br><br><br></div><div>> Date: Tue, 28 Jun 2016 11:40:06 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: jay.krell@cornell.edu; m3devel@elegosoft.com<br>> Subject: Re: [M3devel] cm3 llvm backend?<br>> <br>> <br>> <br>> On 06/27/2016 08:03 PM, Jay K wrote:<br>> > So..rambling a bit..but I have discussed some with people<br>> > and considered it.<br>> ><br>> > "the interface to the compiler backend"<br>> ><br>> ><br>> > and my half serious answer:<br>> ><br>> ><br>> > All of the compilers have a well documented very stable<br>> > interface to their backends, and it is in fact the same,<br>> > roughly, interface to all the backends: source code.<br>> ><br>> ><br>> > It is true it isn't the most efficient representation.<br>> > Maybe the least efficient.<br>> ><br>> ><br>> > It might not expose all the internals at least portable (e.g. tail call).<br>> > But it works, is heavily used, is well known, documented,<br>> > has high compatibility requirements, somewhat readable with<br>> > standard tools, etc.<br>> ><br>> ><br>> > I would advocate that C and C++ be evolved a little bit<br>> > for these purposes. In particular, C needs exception handling.<br>> > C and C++ need a tail call notion.<br>> > _alloca should maybe be standardized.<br>> > I should be able to generate image-relative pointers/offsets.<br>> > (trivial in Microsoft assembly with "imagerel"), to help<br>> > me layout position indepenent data structures.<br>> ><br>> ><br>> > C-- is kind of this, and there was some C-resembling assembly,'<br>> > but I think really C should be the starting point, as it is pretty close.<br>> ><br>> ><br>> > Probably need some extensions like non-int bitfields, and<br>> > rotate, and shift right with both sign copying and zero fill.<br>> ><br>> ><br>> > > A teacher of mine called this behavior "version junkie".<br>> ><br>> ><br>> > There are at least two big reasons for this.<br>> ><br>> > - The language really is improving. Programs<br>> > written in the newer language are easier to read<br>> > and often easier to optimize and sometimes easier<br>> > to implement a compiler for.<br>> <br>> Sometimes so, sometimes not. Sadly, many language "features" reflect<br>> an implicit but very misguided belief that fewer keystrokes/characters<br>> means increased readability. Or at least that writability is more<br>> important than readability. So often, this means actual code is less<br>> explicit. But this makes maintenance far worse.<br>> <br>> E.g., Ada decided use parentheses for both actual parameter lists to<br>> function calls and subscript lists to arrays. Along with optional<br>> implicit operations like dereferencing, there are somewhere in the<br>> teens of possible meanings for the innocent looking "f(x)". I have forgotten<br>> the exact number, but once had to do the semantic analysis. That was<br>> Ada 83. Maybe more have been added since. For the poor schmuck who<br>> gets called at 3:00 AM to fix a bug in half a million lines of code<br>> she didn't write, this is a readability disaster. The savings of<br>> keystrokes in not making the operations explicit is penny-wise and<br>> million-pound foolish.<br>> <br>> ><br>> > - Dogfooding -- using the language helps inform the<br>> > language implementer where they have done things right,<br>> > or wrong, and what to improve.<br>> ><br>> ><br>> > I believe in fact that under-dogfooding of C++ led<br>> > to some early omissions. The need for auto for example.<br>> > Granted, Stroustrup put it in in the 1980s and had to remove it.<br>> > But with more dogfooding by more implementers, it would<br>> > have been added earlier. Similarly "template typedefs".<br>> > Are obviously needed once you use templates for about a day.<br>> ><br>> ><br>> > Modula-3 has similar failings imho.<br>> > For example, the fact that with/var imply<br>> > a nesting that "needs" indentation and needs "end".<br>> > This is something that C++ and much later even C fixed.<br>> ><br>> ><br>> > Perhaps though, perhaps the Modula-3 designers were<br>> > balancing the specification and implementation against<br>> > user convenience, as the current design is obviously<br>> > simpler to specify and implement. But tedious to use.<br>> ><br>> > So the binary form of LLVM bit code is more stable than the text form?<br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br>> ><br>> > > Date: Mon, 27 Jun 2016 19:31:53 -0500<br>> > > From: rodney_bates@lcwb.coop<br>> > > To: m3devel@elegosoft.com<br>> > > Subject: Re: [M3devel] cm3 llvm backend?<br>> > ><br>> > ><br>> > ><br>> > > On 06/27/2016 03:29 PM, Henning Thielemann wrote:<br>> > > ><br>> > > > On Mon, 27 Jun 2016, Rodney M. Bates wrote:<br>> > > ><br>> > > >> And no, the names and operator spellings are not close to adequate<br>> > > >> to clue you in. They have gone to every length possible to use<br>> > > >> every clever new C++ "feature" that comes out in the latest<br>> > > >> C++-<n> standard, which always just increases the complexity<br>> > > >> of the search to a declaration. So I don't fancy doing any of<br>> > > >> this. (BTW, <n>=17 in recent discussions.)<br>> > > ><br>> > > > A teacher of mine called this behavior "version junkie".<br>> > > ><br>> > ><br>> > > Yes, yes.<br>> > ><br>> > > ><br>> > > >> Actually, keeping their bitcode stable across llvm releases is<br>> > > >> one place they do talk about compatibility. But m3llvm uses calls<br>> > > >> to llvm APIs to construct llvm IR as in-memory data, then another<br>> > > >> call to get llvm to convert it to bitcode. So bitcode's stability<br>> > > >> is irrelevant to us. I once thought about producing llvm bitcode<br>> > > >> directly, but that seems like a pretty big job. It would, however,<br>> > > >> obviate creating most of those wretched bindings.<br>> > > ><br>> > > > An alternative would be to create .ll text files. But its format changes, too.<br>> > ><br>> > > Yes. But, according to the list talk, they don't have the intention to<br>> > > make it as stable as the bitcode format.<br>> > ><br>> > ><br>> > > > _______________________________________________<br>> > > > M3devel mailing list<br>> > > > M3devel@elegosoft.com<br>> > > > https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br>> > > ><br>> > ><br>> > > --<br>> > > Rodney Bates<br>> > > rodney.m.bates@acm.org<br>> > > _______________________________________________<br>> > > M3devel mailing list<br>> > > M3devel@elegosoft.com<br>> > > https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br></div> </div></body>
</html>