www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Backend nearly entirely converted to D

reply Walter Bright <newshound2 digitalmars.com> writes:
With the recent merging of the last of the big files machobj.d:

https://github.com/dlang/dmd/pull/8911

I'm happy to say we're over the hump in converting the backend to D!

Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c, 
sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C anyway - 
os.c and strtold.c. sizecheck.c will just go away upon completion.

Thanks to everyone who helped out with this!

Of course, the code remains as ugly as it was in C. It'll take time to bit by 
bit refactor it into idiomatic D.

The more immediate benefit is to get rid of all the parallel .h files, which 
were a constant source of bugs when they didn't match the .d versions.
Nov 06 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Nov 06, 2018 at 02:12:02PM -0800, Walter Bright via
Digitalmars-d-announce wrote:

 With the recent merging of the last of the big files machobj.d:
 
 https://github.com/dlang/dmd/pull/8911
 
 I'm happy to say we're over the hump in converting the backend to D!
 
 Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c,
 sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C
 anyway - os.c and strtold.c. sizecheck.c will just go away upon
 completion.
 
 Thanks to everyone who helped out with this!


Awesome news!



 Of course, the code remains as ugly as it was in C. It'll take time to
 bit by bit refactor it into idiomatic D.


What sort of refactoring are we looking at?  Any low-hanging fruit here
that we non-compiler-experts can chip away at?



 The more immediate benefit is to get rid of all the parallel .h files,
 which were a constant source of bugs when they didn't match the .d
 versions.


Finally!


T

-- 
Do not reason with the unreasonable; you lose by definition.
Nov 06 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2018 3:00 PM, H. S. Teoh wrote:

 What sort of refactoring are we looking at?  Any low-hanging fruit here
 that we non-compiler-experts can chip away at?


Simply going with foreach loops is a nice improvement.
Nov 06 2018
parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 7 November 2018 at 00:01:13 UTC, Walter Bright 
wrote:

 On 11/6/2018 3:00 PM, H. S. Teoh wrote:

 What sort of refactoring are we looking at?  Any low-hanging 
 fruit here
 that we non-compiler-experts can chip away at?


 Simply going with foreach loops is a nice improvement.


Thas sounds like a job that I can do. At this moment I am reading 
DMD source code starting from main() because when I tried to 
understand part of something I wanted to change it felt that to 
understand something you basically need to understand a third of 
compiler.

One of biggest and needless hurdle I face in reading DMD code is 
single letter variable name. If I change one letter variable 
names to more descriptive ones would that patch be welcomed or 
considered needless change?
Nov 07 2018
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2018 1:49 PM, welkam wrote:

 One of biggest and needless hurdle I face in reading DMD code is single letter 
 variable name. If I change one letter variable names to more descriptive ones 
 would that patch be welcomed or considered needless change?


Sorry, it would not be welcome. Single letter names are appropriate for locally 
defined symbols. There's also an informal naming convention for them, changing 
the names would disrupt that.

Shuffling code around without a very strong reason is also not looked upon 
favorably. Basically anything that vacuously creates large diffs.
Nov 07 2018
parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 7 November 2018 at 22:03:20 UTC, Walter Bright 
wrote:

 Single letter names are appropriate for locally defined 
 symbols. There's also an informal naming convention for them, 
 changing the names would disrupt that.


And where can i read about naming convention? My guess its not 
documented anywhere and would not be in foreseeable future or 
ever. Also are you sure you are not talking about two letter 
variables like
sc for scope
fd for function declaration
td for template declaration

because I am not proposing to change them. They are 26 times 
better than one letter names and changing them would not bring 
significant benefit. What I want to do is change variables like 
m. Try guessing what it is used for. Hint it is used for 
different things.

What I dont understand is that you are against changing variable 
names that would improve code understandability but you are not 
against changing for loops to foreach that add almost nothing to 
code readability and only look better.

What you dont know about me is that I worked as code 
reviewer/tester/merger at PHP shop and know full well why you 
want pull requests the way you want. I also know how much less 
easier it is to review simple changes like foreach loop changes 
and simple variable renaming
Nov 08 2018
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-11-08 18:23, welkam wrote:



 but you are not against 
 changing for loops to foreach that add almost nothing to code 
 readability and only look better.


Changing to a foreach loop definitely adds to readability and to be able 
to better understand the code. If you read the "foreach" keyword you 
know that to a 99% possibility the code that follows is a loop that will 
iterate a collection from start to end. If you read the keyword "for" 
you basically know nothing. It can mean iterating a collection, copy 
some random memory or whatever.

-- 
/Jacob Carlborg
Nov 08 2018
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2018 9:23 AM, welkam wrote:

 And where can i read about naming convention? My guess its not documented 
 anywhere and would not be in foreseeable future or ever. Also are you sure you 
 are not talking about two letter variables like
 sc for scope
 fd for function declaration
 td for template declaration


That is a naming convention. No, it's not documented. There's also `e` for 
Expression. `i` for loop index. Etc.



 What I want 
 to do is change variables like m. Try guessing what it is used for.


I don't need to guess. I look at its declaration a few lines up.



 What I dont understand is that you are against changing variable names that 
 would improve code understandability


This is where we diverge:

     Expression expression = new IntegerExp(loc, 1);
     expression = expression.expressionSemantic(sc);
     expression = resolveProperties(sc, expression);

is just exhausting compared with:

     Expression e = new IntegerExp(loc, 1);
     e = e.expressionSemantic(sc);
     e = resolveProperties(sc, e);



 but you are not against changing for loops 
 to foreach that add almost nothing to code readability and only look better.


Looking better is improving readability.

     foreach (m; modules)
     {
          ...
     }

is much more readable than:

     for (size_t i = 0; i < modules.dim; ++i)
     {
          Module m = modules[i];
          ...
     }

and much less prone to typo bugs. The for loop also is dependent on abstraction 
leak of modules[] being an array, whereas foreach only requires that the 
abstraction be traverse-able.



 What you dont know about me is that I worked as code reviewer/tester/merger at 
 PHP shop and know full well why you want pull requests the way you want. I
also 
 know how much less easier it is to review simple changes like foreach loop 
 changes and simple variable renaming


It's great that you have valuable experience with this. Renaming variables, 
however, is not what I'm looking for. What I am looking for is using D to fix 
leaky abstractions, using const and pure, minimizing use of global mutable 
state, reducing the amount of code one must learn to make useful changes, 
reducing code duplication, minimizing the lifetime of variables, improving 
performance, etc.

For some more thoughts on this, check out my recent presentation on it:

http://nwcpp.org/october-2018.html
Nov 08 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 07, 2018 at 09:49:41PM +0000, welkam via Digitalmars-d-announce
wrote:
[...]

 One of biggest and needless hurdle I face in reading DMD code is
 single letter variable name. If I change one letter variable names to
 more descriptive ones would that patch be welcomed or considered
 needless change?


I don't speak for the compiler devs, but IMO, one-letter variables are
OK if they are local, and cover a relatively small scope.  Java-style
verbosity IMO makes code *harder* to read because the verbosity gets in
your face, crowding out the more interesting (and important) larger
picture of code structure.

As Walter said in his recent talk, the length of variable names (or
identifiers in general, really) should roughly correspond to their
scope: local variable names ought to be concise, but global variables
ought to be verbose (both to avoid identifier collision when a larger
amount of code is concerned, and also to serve as a convenient visual
indication that yes it's a global).


T

-- 
An imaginary friend squared is a real enemy.
Nov 07 2018
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Slides and video link:

  http://nwcpp.org/october-2018.html

On 11/7/2018 2:08 PM, H. S. Teoh wrote:

 I don't speak for the compiler devs, but IMO, one-letter variables are
 OK if they are local, and cover a relatively small scope.  Java-style
 verbosity IMO makes code *harder* to read because the verbosity gets in
 your face, crowding out the more interesting (and important) larger
 picture of code structure.
 
 As Walter said in his recent talk, the length of variable names (or
 identifiers in general, really) should roughly correspond to their
 scope: local variable names ought to be concise, but global variables
 ought to be verbose (both to avoid identifier collision when a larger
 amount of code is concerned, and also to serve as a convenient visual
 indication that yes it's a global).


Yes, exactly.
Nov 07 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-11-07 23:58, Walter Bright wrote:

 Slides and video link:
 
   http://nwcpp.org/october-2018.html
 
 On 11/7/2018 2:08 PM, H. S. Teoh wrote:

 I don't speak for the compiler devs, but IMO, one-letter variables are
 OK if they are local, and cover a relatively small scope.  Java-style
 verbosity IMO makes code *harder* to read because the verbosity gets in
 your face, crowding out the more interesting (and important) larger
 picture of code structure.

 As Walter said in his recent talk, the length of variable names (or
 identifiers in general, really) should roughly correspond to their
 scope: local variable names ought to be concise, but global variables
 ought to be verbose (both to avoid identifier collision when a larger
 amount of code is concerned, and also to serve as a convenient visual
 indication that yes it's a global).


 
 Yes, exactly.
 


I guess we have very different ideas on what "small scope" is. For me it 
means around 10 lines. Here's an example in the DMD code base, the 
method for doing the semantic analyze on a call expression [1]. It's 902 
lines long and has a parameter called "exp". Another example, the 
semantic analyze for an is expression [2], 310 lines long. It has a 
parameter called "e".

Someone familiar with the code base might know that the convention is 
that a variable of a type inheriting from the Expression class is 
usually called "e". Someone new to the code base will most likely not. I 
cannot see how starting to call the variable "expression" or 
"callExpression" would be disrupt. Currently when someone familiar with 
the code base reads the code and sees a variable named "e" the developer 
will think "hey, I know by convention that is usual an expression". If 
the variable was renamed to "expression" then both the one familiar and 
unfamiliar with the code base can immediately read that this variable 
holds an expression.

[1] 
https://github.com/dlang/dmd/blob/c3dcc76327cdd1cebd9767d9ce738bcbc4db2beb/src/dmd/expressionsem.d#L3812-L4713

[2] 
https://github.com/dlang/dmd/blob/c3dcc76327cdd1cebd9767d9ce738bcbc4db2beb/src/dmd/expressionsem.d#L4924-L5233

-- 
/Jacob Carlborg
Nov 08 2018
next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Thu, 08 Nov 2018 18:13:55 +0100, Jacob Carlborg wrote:

 I guess we have very different ideas on what "small scope" is. For me it
 means around 10 lines. Here's an example in the DMD code base, the
 method for doing the semantic analyze on a call expression [1]. It's 902
 lines long and has a parameter called "exp". Another example, the
 semantic analyze for an is expression [2], 310 lines long. It has a
 parameter called "e".


I recall opening up the source code some years ago, encountering a long 
function, and seeing variables `e` and `e2` that were reused for 
*probably* different purposes but I honestly couldn't tell.

Having them named `expression` and `expression2` would have saved me about 
five seconds total, which wouldn't have been particularly worthwhile. 
Giving them names that reflected how they were being used would have been 
quite helpful -- at the very least, it would have given a weak indication 
that they were not being reused for different purposes.
Nov 08 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 08, 2018 at 06:13:55PM +0100, Jacob Carlborg via
Digitalmars-d-announce wrote:
[...]

 I guess we have very different ideas on what "small scope" is. For me
 it means around 10 lines. Here's an example in the DMD code base, the
 method for doing the semantic analyze on a call expression [1]. It's
 902 lines long and has a parameter called "exp". Another example, the
 semantic analyze for an is expression [2], 310 lines long. It has a
 parameter called "e".
 
 Someone familiar with the code base might know that the convention is
 that a variable of a type inheriting from the Expression class is
 usually called "e". Someone new to the code base will most likely not.
 I cannot see how starting to call the variable "expression" or
 "callExpression" would be disrupt. Currently when someone familiar
 with the code base reads the code and sees a variable named "e" the
 developer will think "hey, I know by convention that is usual an
 expression". If the variable was renamed to "expression" then both the
 one familiar and unfamiliar with the code base can immediately read
 that this variable holds an expression.


[...]

A function parameter named 'expression' is far too long. I wouldn't go
as far as calling it 'e', but maybe 'expr' is about as long as I would
go.  You're dealing with the code of a compiler, 'expr' should be
blatantly obvious already that it means "expression".  Spelling it out
completely just clutters the code and makes it harder to read.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Nov 08 2018
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 7 November 2018 at 22:08:36 UTC, H. S. Teoh wrote:

 I don't speak for the compiler devs, but IMO, one-letter 
 variables are OK if they are local, and cover a relatively 
 small scope.



By saying more descriptive I should have clarified that I meant 
to change them to 3-7 letter names. Small variable names are ok 
for small functions like the one in attrib.d called void 
importAll(Scope* sc). It has variable named sc and its clear 
where it is used.

Now for all of you who think that one letter variables are ok 
here is exercise. Go and open src/dmd/func.d with your favorite 
code editor. Find function FuncDeclaration resolveFuncCall(). Its 
around 170 LOC long. Now find all uses of variable Dsymbol s. Did 
you found them all? Are you sure? Ok now do the same for variable 
loc. See the difference?


 Java-style verbosity IMO makes code *harder* to read because 
 the verbosity gets > in your face, crowding out the more 
 interesting (and important) larger picture of code structure.


What editor do you use?
Here is the worst example to prove my point but its still 
sufficient. All editors worth your time highlights the same text 
when selected and here is example of one letter variable.
https://imgur.com/a/jjxCdmh
and tree letter variable
https://imgur.com/a/xOqbkmn

where is all that crowding and loss of large picture you speak 
of? Its the opposite. Code structure is more clear with longer 
variable names than one letter.


 As Walter said in his recent talk, the length of variable names 
 (or identifiers in general, really) should roughly correspond 
 to their scope


At best this is argument form authority. You said how thing 
should be not why. For argument sake imagine situation where you 
need to expand function. By your proposed rules you should rename 
local variables to longer names. Thats ridiculous. Yes I watched 
that presentation and fully disagree with Walter and know for 
sure he doesnt have sound argument to support his position.
Nov 08 2018
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Thursday, 8 November 2018 at 17:50:20 UTC, welkam wrote:

 On Wednesday, 7 November 2018 at 22:08:36 UTC, H. S. Teoh wrote:



 Now for all of you who think that one letter variables are ok 
 here is exercise. Go and open src/dmd/func.d with your favorite 
 code editor. Find function FuncDeclaration resolveFuncCall(). 
 Its around 170 LOC long. Now find all uses of variable Dsymbol 
 s. Did you found them all? Are you sure? Ok now do the same for 
 variable loc. See the difference?


If we were to look for an s of a specific type, it's not just the 
editor we would need, now would we?


 Java-style verbosity IMO makes code *harder* to read because 
 the verbosity gets > in your face, crowding out the more 
 interesting (and important) larger picture of code structure.


 What editor do you use?
 Here is the worst example to prove my point but its still 
 sufficient. All editors worth your time highlights the same 
 text when selected and here is example of one letter variable.
 https://imgur.com/a/jjxCdmh
 and tree letter variable
 https://imgur.com/a/xOqbkmn


One keystroke (well ok, two keys because it's *) ;)
https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png


 where is all that crowding and loss of large picture you speak 
 of? Its the opposite. Code structure is more clear with longer 
 variable names than one letter.


I don't think H.S. meant one letter vs. three. Java tends to be 
obtusely verbose. Wear down your fingers/eyes kind of verbose.


 As Walter said in his recent talk, the length of variable 
 names (or identifiers in general, really) should roughly 
 correspond to their scope


 At best this is argument form authority. You said how thing 
 should be not why. For argument sake imagine situation where 
 you need to expand function. By your proposed rules you should 
 rename local variables to longer names. Thats ridiculous. Yes I 
 watched that presentation and fully disagree with Walter and 
 know for sure he doesnt have sound argument to support his 
 position.


IMHO, one/two letters are fine so long as the variable's scope 
spans at most two pages. If scope is larger, name should be 
longer.
Nov 08 2018
parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov 
wrote:

 One keystroke (well ok, two keys because it's *) ;)
 https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png


What sorcery is this? I need to know. I guess its vim but how 
does it highlight symbols?
Nov 08 2018
next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Thu, 08 Nov 2018 18:38:55 +0000, welkam wrote:

 On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote:

 One keystroke (well ok, two keys because it's *) ;)
 https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png


 What sorcery is this? I need to know. I guess its vim but how does it
 highlight symbols?


By default, when you search for something in vim, it highlights all matches 
(as well as moving the cursor to the next match). The '*' command is 
'search for the word under the cursor'.

The rest is just basic syntax highlighting.
Nov 08 2018
parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Thursday, 8 November 2018 at 18:48:05 UTC, Neia Neutuladh 
wrote:

 On Thu, 08 Nov 2018 18:38:55 +0000, welkam wrote:

 On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov 
 wrote:

 One keystroke (well ok, two keys because it's *) ;)
 https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png


 What sorcery is this? I need to know. I guess its vim but how 
 does it highlight symbols?


 By default, when you search for something in vim, it highlights 
 all matches (as well as moving the cursor to the next match). 
 The '*' command is 'search for the word under the cursor'.


"Near", not "under". But yup, key is "word", i.e. with a very 
concise keystroke you get a highlighted search for a (in that 
case) "\<m\>". If I were to search for just "m", I'd get the same 
soup as in welkam's first screenshot.
Nov 08 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 08, 2018 at 06:38:55PM +0000, welkam via Digitalmars-d-announce
wrote:

 On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote:

 
 One keystroke (well ok, two keys because it's *) ;)
 https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png
 


 
 What sorcery is this? I need to know. I guess its vim but how does it
 highlight symbols?


As I've said, it highlights symbols based on *word* match, not substring
match, which apparently your editor does.  The latter is flawed, and
probably is what led you to your conclusions.  I suggest looking for an
editor with a better syntax highlighter / search function.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system
vulnerabilities cannot touch Linux---is priceless. -- Frustrated system
administrator.
Nov 08 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 08, 2018 at 05:50:20PM +0000, welkam via Digitalmars-d-announce
wrote:

 On Wednesday, 7 November 2018 at 22:08:36 UTC, H. S. Teoh wrote:

 I don't speak for the compiler devs, but IMO, one-letter variables
 are OK if they are local, and cover a relatively small scope.


 
 By saying more descriptive I should have clarified that I meant to
 change them to 3-7 letter names. Small variable names are ok for small
 functions like the one in attrib.d called void importAll(Scope* sc).
 It has variable named sc and its clear where it is used.
 
 Now for all of you who think that one letter variables are ok here is
 exercise. Go and open src/dmd/func.d with your favorite code editor.
 Find function FuncDeclaration resolveFuncCall(). Its around 170 LOC
 long. Now find all uses of variable Dsymbol s. Did you found them all?
 Are you sure?


Yes. My editor knows to search for 's' delimited by word boundaries, so
it would not match 's' in the middle of the word, but only 's'
surrounded by non-alphabetic characters.



 Ok now do the same for variable loc. See the difference?


I see no difference.

Moral: use a better editor. :-P



 Java-style verbosity IMO makes code *harder* to read because the
 verbosity gets > in your face, crowding out the more interesting
 (and important) larger picture of code structure.


 
 What editor do you use?


Vim.

And I don't even use syntax highlighting (because I find it visually
distracting).



 Here is the worst example to prove my point but its still sufficient. All
 editors worth your time highlights the same text when selected and here is
 example of one letter variable.
 https://imgur.com/a/jjxCdmh
 and tree letter variable
 https://imgur.com/a/xOqbkmn


Your syntax highlighter is broken.  It should not match substrings, but
only the entire word.  Vim's search function does this (including the
highlights, if I turned it on, but by default I leave it off).



 where is all that crowding and loss of large picture you speak of? Its
 the opposite. Code structure is more clear with longer variable names
 than one letter.


Your opinion is biased by using a flawed syntax highlighter / symbol
search function.



 As Walter said in his recent talk, the length of variable names (or
 identifiers in general, really) should roughly correspond to their
 scope


 
 At best this is argument form authority. You said how thing should be
 not why. For argument sake imagine situation where you need to expand
 function.  By your proposed rules you should rename local variables to
 longer names.  Thats ridiculous. Yes I watched that presentation and
 fully disagree with Walter and know for sure he doesnt have sound
 argument to support his position.


[...]

It's very simple.  The human brain is very good at context-sensitive
pattern matching, something which computers are rather poor at (well, at
least, traditional algorithms that aren't neural-network based).
Natural language, for example, is full of ambiguities, but in everyday
speech we have no problems figuring out what is meant, because the
context supplies the necessary information to disambiguate.  Therefore,
frequently-used words tend to be short (and tend to shorten over time),
because it's not necessary to enunciate the full word or phrase to
convey the meaning.  Rarely-used words tend to be longer (and resist
simplification over time) because context provides less information, and
so the full word becomes necessary in order to minimize information
loss.

Function parameters and local variables are, by definition, restricted
in scope, and therefore the context of the function provides enough
information to disambiguate short names.  And since local variables and
parameters would tend to be used frequently, the brain prefers to
simplify and shorten their identifiers.  As a result, after
acclimatizing, one begins to expect that short names correspond with
local variables, and long names correspond with non-local variables.
Going against this natural expectation (e.g., long names for locals,
short names for globals) causes extra mental load to resolve the
referents.

Your counterargument of expanding a function and needing to rename local
variables is a strawman.  A function is a function, and local variables
don't need to be renamed just because you added more code into it.

(However, there *is* a point that when the function starts getting too
long, it ought to be split into separate functions, otherwise it becomes
harder to understand. On that point, I do agree with you that dmd's code
could stand improvement, since 900-line functions are definitely far too
long to keep the entire context in short-term memory, and so using short
local identifiers begins to lose its benefits and increase its
disadvantages.)


T

-- 
Many open minds should be closed for repairs. -- K5 user
Nov 08 2018
parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 8 November 2018 at 18:52:02 UTC, H. S. Teoh wrote:

 length is getting ridiculous


Having better editor support is nice but by "use better editor" 
you meant use vim dont you? And even if I switch to vim it wont 
solve my initial objection to one letter variable names. Its 
needless hurdles. Not to mention the next person new to this will 
likely have same problems like me. And the person after that etc. 
Which comes to my recurring thought when dealing with dmd. How 
the f #k should I knew that? Documentation and instructions 
around D project is almost non existant. Does idea pit of success 
not apply to compiler?


Human brain is good at finding patterns. Its also good at finding 
patters it wants to find where they dont exist. Your statement 
that humans have no problems in disambiguating language is 
completely false. Most people just ignore logical conflicts or 
lack of information needed to correctly understand what is being 
said. Most people dont put lots of effort in understanding what 
exactly is being said and humans are bad at conveying their 
thoughts trough words to begin with. Extreme case of this is all 
forms of religious believes. Here is a clip where people give 
definitions of God and none of them are the same
https://youtu.be/HhRo9ABvef4
and here is one where J.P. at least tries to disambiguate words.
https://youtu.be/q0O8Jw6grro

When people talk about God first they cant tell precisely what 
they believe. Second they dont know precisely what others 
believe. And third it doesnt even matter as long as you make 
vaguely sounding sentences. Same extends to the rest of human 
interactions and humans would happily go without noticing that 
until they have to interact with computers where you have to 
define everything precisely.

Your second idea that shorter words have less information is... 
just... What? English is not floating point where length dictates 
precision. In German maybe with one word created from combining 
multiple but not in English.

Then you combined your both flawed ideas to produce paragraph 
where good and bad ideas are mixed together.

No I did not strawman. I took Walters advice from NWCPP talk 
precisely to show a flow in it. If variable name lenght should be 
related to scope then changing scope should change variable name 
lenght. You on the other hand changed advice to binary advice. 
Either local and short or global and verbose
NWCPP talk
https://youtu.be/lbp6vwdnE0k?t=444

Code is read more often than written and should be optimized for 
that. One letter variable names are not descriptive enough. In 
short functions you can get away from paying mental price but in 
long ones you do not.
Nov 08 2018
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 8 November 2018 at 22:21:40 UTC, welkam wrote:

 On Thursday, 8 November 2018 at 18:52:02 UTC, H. S. Teoh wrote:

 length is getting ridiculous


 Having better editor support is nice but by "use better editor" 
 you meant use vim dont you?


Please keep chatter on the announce forum to a minimum. Vim is 
not the only editor capable of limiting searches to whole words. 
Sublime Text and Visual Studio Code can do this too, as can 
probably many others.
Nov 09 2018
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 6 November 2018 at 22:12:02 UTC, Walter Bright wrote:

 With the recent merging of the last of the big files machobj.d:

 https://github.com/dlang/dmd/pull/8911

 I'm happy to say we're over the hump in converting the backend 
 to D!


Great! Although I wish it didn't have to be you mostly doing this 
grunt work.


 Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, 
 outbuf.c, sizecheck.c, strtold.c and mem.c. I'll probably leave 
 a couple in C anyway - os.c and strtold.c. sizecheck.c will 
 just go away upon completion.

 Thanks to everyone who helped out with this!

 Of course, the code remains as ugly as it was in C. It'll take 
 time to bit by bit refactor it into idiomatic D.


I just benchmarked building the last couple versions of DMD, when 
most of the backend was converted to D, by building them with the 
latest DMD 2.083.0 official release and clang 6.0 in a 
single-core linux/x64 VPS. Here are the times I got, best of 3 
runs for each:

2.081.2 - 11.5s
2.082.1 - 10.5s
2.083.0 - 9.9s
master  - 10.8s

Not quite the gains hoped for, particularly with those last large 
files you just converted to D seemingly slowing compilation down, 
but maybe it will get better with refactoring and when the entire 
backend is compiled at once, rather than the DMD separate 
compilation used now.


 The more immediate benefit is to get rid of all the parallel .h 
 files, which were a constant source of bugs when they didn't 
 match the .d versions.


I was going to ask why you wouldn't need those headers for your 
C/C++ compiler, DMC, but it looks like you've translated that to 
mostly D already:

https://github.com/DigitalMars/Compiler/tree/master/dm/src/dmc
Nov 07 2018
parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 7 November 2018 at 08:31:21 UTC, Joakim wrote:

 I just benchmarked building the last couple versions of DMD, 
 when most of the backend was converted to D, by building them 
 with the latest DMD 2.083.0 official release and clang 6.0 in a 
 single-core linux/x64 VPS. Here are the times I got, best of 3 
 runs for each:

 2.081.2 - 11.5s
 2.082.1 - 10.5s
 2.083.0 - 9.9s
 master  - 10.8s

 Not quite the gains hoped for, particularly with those last 
 large files you just converted to D seemingly slowing 
 compilation down


Could this be because you used a LLVM compiler for the C code but 
a Mars compiler for D code? If one either uses DMC for C or LDC 
for D, perhaps the results will be better.
Nov 07 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 7 November 2018 at 11:22:13 UTC, Dukc wrote:

 On Wednesday, 7 November 2018 at 08:31:21 UTC, Joakim wrote:

 I just benchmarked building the last couple versions of DMD, 
 when most of the backend was converted to D, by building them 
 with the latest DMD 2.083.0 official release and clang 6.0 in 
 a single-core linux/x64 VPS. Here are the times I got, best of 
 3 runs for each:

 2.081.2 - 11.5s
 2.082.1 - 10.5s
 2.083.0 - 9.9s
 master  - 10.8s

 Not quite the gains hoped for, particularly with those last 
 large files you just converted to D seemingly slowing 
 compilation down


 Could this be because you used a LLVM compiler for the C code 
 but a Mars compiler for D code? If one either uses DMC for C or 
 LDC for D, perhaps the results will be better.


I don't know why you think that would matter: I'm using the same 
compilers to build each DMD version and comparing the build times 
as the backend was translated to D. Maybe I'd get different 
results by using different compilers, but these are two fairly 
fast and commonly used compilers so they're worth checking with.
Nov 07 2018
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:

 I don't know why you think that would matter: I'm using the 
 same compilers to build each DMD version and comparing the 
 build times as the backend was translated to D.


Because generally, LLVM compilers provide faster code, but 
compile slower than Digital Mars compilers AFAIK. So if you 
compile the D code with DMD but C code with LDC, the program will 
likely compile faster but execute slower as increasing portions 
are written in D, compared to using the same backend for both 
languages.

I'm not sure if you benchmarked the time used to build DMD, or 
the time used by generated DMD to compile some other program. If 
it was the former, the "real" result is probably worse than your 
results. But if it was the latter, it is likely better.
Nov 07 2018
parent Joakim <dlang joakim.fea.st> writes:
On Wednesday, 7 November 2018 at 15:12:13 UTC, Dukc wrote:

 On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:

 I don't know why you think that would matter: I'm using the 
 same compilers to build each DMD version and comparing the 
 build times as the backend was translated to D.


 Because generally, LLVM compilers provide faster code, but 
 compile slower than Digital Mars compilers AFAIK. So if you 
 compile the D code with DMD but C code with LDC, the program 
 will likely compile faster but execute slower as increasing 
 portions are written in D, compared to using the same backend 
 for both languages.

 I'm not sure if you benchmarked the time used to build DMD, or 
 the time used by generated DMD to compile some other program. 
 If it was the former, the "real" result is probably worse than 
 your results. But if it was the latter, it is likely better.


The former, if it wasn't clear. It's also possible something 
slowed down building the frontend in successive DMD versions, so 
ideally I'd only time building the backend for each DMD version, 
but I haven't looked into that.
Nov 07 2018
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:

 I don't know why you think that would matter: I'm using the 
 same compilers to build each DMD version and comparing the 
 build times as the backend was translated to D


What did you compared is whether clang or DMD compiles code 
faster not whether D code compiles faster than C++. To check that 
you should compile both C++ and D with the same backend.
Nov 07 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 7 November 2018 at 21:40:58 UTC, welkam wrote:

 On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:

 I don't know why you think that would matter: I'm using the 
 same compilers to build each DMD version and comparing the 
 build times as the backend was translated to D


 What did you compared is whether clang or DMD compiles code 
 faster not whether D code compiles faster than C++. To check 
 that you should compile both C++ and D with the same backend.


I'm not making any general statements about whether C++ or D 
compiles faster, only pointing out that in a common setup of 
building dmd with clang and dmd on linux/x64, I didn't see much 
of a speed gain. However, I did mention that the frontend should 
be removed to really measure the backend conversion, so that's 
what I just did.

I built the backends for DMD 2.080.1 through master in the same 
single-core VPS by slightly modifying src/posix.mak, only 
replacing the line "all: $G/dmd" with "all: $G/backend.a". Here 
are the results I got and how many D files were built in each 
backend:

2.080.1 - 1D  8.0s
2.081.2 - 4D  7.2s
2.082.1 - 27D 6.9s
2.083.0 - 45D 5.6s
master d398d8c - 50D 4.3s

So the frontend might have been obscuring things, as we see a 
clear win from moving the backend to D, with only about 10 C/C++ 
files left in the backend now and compilation time cut almost in 
half. I think we'll see even more of a gain if the D files in the 
backend are built all at once.
Nov 08 2018
parent Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 8 November 2018 at 08:40:37 UTC, Joakim wrote:
[...]

 2.080.1 - 1D  8.0s
 2.081.2 - 4D  7.2s
 2.082.1 - 27D 6.9s
 2.083.0 - 45D 5.6s
 master d398d8c - 50D 4.3s


[...]

 I think we'll see even more of a gain if the D files in the 
 backend are built all at once.


Interesting!
Nov 09 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-11-06 23:12, Walter Bright wrote:


 The more immediate benefit is to get rid of all the parallel .h files, 
 which were a constant source of bugs when they didn't match the .d 
 versions.


Still need some of those for GDC and LDC. Until we have a tool that can 
automatically generate them.

-- 
/Jacob Carlborg
Nov 07 2018