January 30, 2012
On 1/29/2012 2:44 PM, bearophile wrote:
> Walter:
>> What? How could the compiler possibly know what font was used in your editor?
> Sorry Walter, this time I wasn't serious :-)

All I can say is, I'm glad. That was a heluva WTF!
January 30, 2012
On Sun, Jan 29, 2012 at 07:13:14PM -0600, Sean Cavanaugh wrote: [...]
> There are huge swaths of unused unicode values, including a rather large chunk reserved for custom user-implementation.
> 
> Clearly we need to redesign the language to use custom symbols that make sense, instead of the archaic typesetting symbols we use now and have a unique set of programmer symbols.
[...]

Why bother with custom symbols? Unicode already gives us entire ranges
of mathematical and technical symbols that we could use to our hearts'
content. For example, I would love to have new matching pairs of
delimiters, such as «» that we could use for, say, template parameters,
instead of uglinessess like !. And I'd love to have my integer set class
be able to use ∪ and ∩ instead of verbose operations like x.union(y) and
x.intersection(y).

For that matter, most function names can be reduced to single symbols like ⌹.  And we can rename D2 to APL2. ;-)


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin
January 30, 2012
On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote:
> More practical than requiring all source files to be saved without formatting:
> 
> - Upon opening a file, the editor looks for a style sheet in the same directory. If there is no such style sheet, it automatically deduces the style from the code, falling back to the local preferences.
> 
> - Then it acts as you propose.
> 
> - And when saving, it automatically formats the source code in the deduced format.

The problem with autoformatting on save is that it interacts badly with revision control systems. You could end up with lots of noisy diffs mostly involving changes in whitespace. By enforcing a fixed formatting, whether it's everything-on-a-line or delete all unnecessary whitespace but leave newlines intact, you ensure that diffs generated by the revision control system will not include whitespace noise.


T

-- 
Debian GNU/Linux: Cray on your desktop.
January 30, 2012
On 30 January 2012 03:27, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote:
>> More practical than requiring all source files to be saved without formatting:
>>
>> - Upon opening a file, the editor looks for a style sheet in the same directory. If there is no such style sheet, it automatically deduces the style from the code, falling back to the local preferences.
>>
>> - Then it acts as you propose.
>>
>> - And when saving, it automatically formats the source code in the deduced format.
>
> The problem with autoformatting on save is that it interacts badly with revision control systems. You could end up with lots of noisy diffs mostly involving changes in whitespace. By enforcing a fixed formatting, whether it's everything-on-a-line or delete all unnecessary whitespace but leave newlines intact, you ensure that diffs generated by the revision control system will not include whitespace noise.
>

The flip side is that if you put everything on one line, no one will be able to understand the commits you make. :)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
January 30, 2012
On Mon, Jan 30, 2012 at 03:35:03AM +0000, Iain Buclaw wrote:
> On 30 January 2012 03:27, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> > On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote:
[...]
> >> - And when saving, it automatically formats the source code in the deduced format.
> >
> > The problem with autoformatting on save is that it interacts badly with revision control systems. You could end up with lots of noisy diffs mostly involving changes in whitespace. By enforcing a fixed formatting, whether it's everything-on-a-line or delete all unnecessary whitespace but leave newlines intact, you ensure that diffs generated by the revision control system will not include whitespace noise.
> >
> 
> The flip side is that if you put everything on one line, no one will be able to understand the commits you make. :)
[...]

Well, that's no fault of mine; it's a relic of holding on to visually-formatted plaintext format. ;-)

If all code was auto-formatted, you won't have this kind of problem, since the diff utility would compare syntax trees instead of lines, and would show you what *actually* changed syntactically. As opposed to diffs where inserting a new function with a similar body to the following adjacent function causes the diff to be a messy interlacing of lines from both functions, 'cos it's "shorter" than a diff which simply inserts the new function. (Which happens a lot with code that has lots of boilerplate. But boilerplates are another issue. :-))


T

-- 
My program has no bugs! Only unintentional features...
January 30, 2012
On Monday, 30 January 2012 at 01:45:40 UTC, Walter Bright wrote:
> On 1/29/2012 2:41 PM, Kagamin wrote:
>> On Sunday, 29 January 2012 at 20:53:51 UTC, Walter Bright wrote:
>>> tolf
>>
>> AFAIK, only windows notepad can't handle lf nowadays. That's it?
>
> So far, I've seen no issues with standardizing on LF line endings.

Ermm... I mean, if you use tolf, then your editor uses something else? I guessed what is this editor.
January 30, 2012
On 01/29/2012 02:27 PM, H. S. Teoh wrote:

>> Why do so many programmers hanker for the 1960s and the necessity of
>> monospace fonts, it seems irrational.
>
> I am irrational.
>
> ;-)

Proudly, me too! I want to look at monospaced code with to tabs anywhere in it; and since I like what came out of the 1960s, 80 columns for me! :)

Ali

January 30, 2012
30.01.2012 0:49, Walter Bright пишет:
> On 1/29/2012 6:04 AM, Denis Shelomovskij wrote:
>> Why does Phobos use 4-space indentation?
>
> Because it works, changing it would be a vast waste of time for a
> non-existent benefit, and it would become a nuisance to do diffs of
> source code that cross the re-whitespace boundary.
>
> The style for Phobos is 4 space indentation, no tab characters anywhere,
> and LF line endings (to make github happy).

OK, the major advantage of spaces is because my approach (tabs for indention, spaces for alignment) isn't testable by a tool that doesn't know D semantics. More than that, my approach isn't a full solution too. It's outdated like spaces because of elastic tabstops. By the way, elastic tabstops looks easy auto-testable too so once we will just migrate to it (I hope).

But the current situation is still unpleasant because:
* There are no suggestions of using some tools for developers to automate conversion, so there is already a wasting of our time (developers and commit reviewers/mergers).
* Look's like nobody ever tested Phobos files for tabs.

P.S.
I started this thread because of wasting my time for conversion/checking and inconsistent situation: druntime/Phobos have both spaces/tabs now (yes, there are significantly more spaces, but it doesn't reduce the problem), e.g. you just broke formatting in std/stream.d:
https://github.com/D-Programming-Language/phobos/commit/f3aa58592faed9a418e347090cd614670947fef4
January 30, 2012
On 1/30/2012 2:16 AM, Denis Shelomovskij wrote:
> P.S.
> I started this thread because of wasting my time for conversion/checking and
> inconsistent situation: druntime/Phobos have both spaces/tabs now (yes, there
> are significantly more spaces, but it doesn't reduce the problem), e.g. you just
> broke formatting in std/stream.d:
> https://github.com/D-Programming-Language/phobos/commit/f3aa58592faed9a418e347090cd614670947fef4

Problems crop up when people check in stuff with tabs in it. I run everything I check in through detab.

January 30, 2012
On Monday, 30 January 2012 at 10:16:36 UTC, Denis Shelomovskij wrote:
> I started this thread

Poor topicstarter. His topic is hijacked and buried if flame, and he himself is sent to oblivion.