The main reason I don't like indentation is that it tends to have strange
rules for "tab". Some people (incorrectly, of course) think that tabs are
not at fixed 8-byte things, so deciding the indentation of a tab often
ends up either disallowing tabs altogether (bad) or having other strange
rules (disallowing spaces).
So I'm not religiously opposed to it, but I find it to be less than
optimal.
Actually, most indentation-sensitive languages have a simpler solution:
they don't try to convert whitespace strings to a number like "horizontal
position"; they just compare strings.
Each line must either have the same indentation string as some active
scope, or its indentation must have the current innermost scope as a
prefix, in which case it introduces a new scope.
This allows anything except for
foo # No prefix
bar # 4 spaces prefix
baz # tab prefix: illegal!
The "baz" line would have to begin with 4 spaces to be legal.
They could be followed by 4 more spaces, or a tab, or any other
whitespace pattern.
It's also possible to combine the two, as Haskell does. Haskell inserts
open braces automatically if there is no such punctuation between two
lines with differing indentation, but if you supply a brace explicitly,
you can do whatever indentation you like. (And the close brace must be
explicit if the open brace is, of course.)
Actually, most indentation-sensitive languages have a simpler solution:
they don't try to convert whitespace strings to a number like "horizontal
position"; they just compare strings.
Yes, but that doesn't really change the problem: you can't _visually_ see
what is wrong in most editors (some editors end up showing tabs as
something that isn't quite whitespace, but that's also really irritating).
This is like Makefiles: if you have spaces in the wrong place, it may all
_look_ fine, but the Makefile just doesn't work. Really irritating.
And obviously using the file will show the problem (the parser will
complain with a nice line number and readable error, hopefully), but I
personally find that to just be too damn late. By then, you're already
irritated.
So I like the notion of depending on indentation, but I just feel it falls
down in practice.
Of course, since I believe that tabs are always exactly 8 characters, I'd
also be perfectly happy to just declare that anybody who disagrees with me
is a moron and deserves to die (*).
Linus
(*) That's obviously true of _anything_ that people disagree with me on,
but at the same time, I have this nagging suspicion that it's just better
to not depend on indentation.
This is like Makefiles: if you have spaces in the wrong place, it may all
_look_ fine, but the Makefile just doesn't work. Really irritating.
Makefiles are more annoying because spaces instead of tabs can cause
them to work *differently*. It's hard to write syntax that will
actually do that, but the parser ahs to go past the problem a bit to
really figure it out, so it can't print a nice error message.
With the strict prefix convention, the parser can produce excellent
error messages.
And obviously using the file will show the problem (the parser will
complain with a nice line number and readable error, hopefully), but I
personally find that to just be too damn late. By then, you're already
irritated.
So I like the notion of depending on indentation, but I just feel it falls
down in practice.
So you're a crotchety old fart already, unable to learn new things?
It irritates you the first few times until you learn to do it right in
first place, just like it irritates most beginning C programmers that the
compiler keeps complaining about missing semicolons.
Computers will be annoying about syntax until they learn to do what
I want them to do rather than what I tell them to do, at which point
they'll be smart enough to start being annoying by doing what they want
to to instead of what I want them to do.
Of course, since I believe that tabs are always exactly 8 characters, I'd
also be perfectly happy to just declare that anybody who disagrees with me
is a moron and deserves to die (*).
I agree on the One True Tab Spacing, but I fear I heretically
disagree with you about the whole NO_IRQ thing, so I guess I'll just
have to take your advice and start stalking you with eugenic intent.
[Briefly: what hardware conventions are, and particularly how many
of those hardware devices exist in the world, is irrelevant. We have
existence proofs of hardware that uses 0 for "no IRQ" and hardware that
accepts 0 as a valid IRQ. dev->irq is a freaking *software convention*.
What matters is the development and maintenance burden of translating
that convention into all the different hardware out there. And frankly
converting between "0 is valid" and "0 is invalid" affects a lot more
code paths than converting between "0 is invalid" and "-1 is invalid"
for a couple of specific hardware devices. Particularly if you
want various kernel messages and /proc/interrupts to look right.
Hell, I could argue that having the most common hardware exercise the
longest code paths is a good thing, because that puts the code that
needs the most testing where it'll get it.]
Seriously, you could always have it print warning messages but try to
keep going by assuming 8 space tabs so that at least you can postpone
fixing the problem until your current train of thought has pulled into
the station.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
linux@horizon.com wrote:
Actually, most indentation-sensitive languages have a simpler solution:
they don't try to convert whitespace strings to a number like "horizontal
position"; they just compare strings.
Each line must either have the same indentation string as some active
scope, or its indentation must have the current innermost scope as a
prefix, in which case it introduces a new scope.
This allows anything except for
foo # No prefix
bar # 4 spaces prefix
baz # tab prefix: illegal!
The "baz" line would have to begin with 4 spaces to be legal.
They could be followed by 4 more spaces, or a tab, or any other
whitespace pattern.
So, would this be considered legal or would it barf on baz?
foo # No prefix
bar # tab prefix
baz # 8 spaces prefix
Most people have tabsize at 8. Some don't. Some editors insert spaces
instead of tabs while others don't. If we just match strings we'll
end up with users sending bug-reports by cut'n pasting their perfectly
valid-looking config which mixes tabs and spaces just because it's
been edited by people using different editors.
Real fun would be if the mta sends tabs as spaces. Then there'd
be no way at all of telling if the config *is* valid or not.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
linux@horizon.com wrote:
quoted
This is like Makefiles: if you have spaces in the wrong place, it may all
_look_ fine, but the Makefile just doesn't work. Really irritating.
Makefiles are more annoying because spaces instead of tabs can cause
them to work *differently*. It's hard to write syntax that will
actually do that, but the parser ahs to go past the problem a bit to
really figure it out, so it can't print a nice error message.
With the strict prefix convention, the parser can produce excellent
error messages.
Excellent error messages aren't good enough. It's ok for Python, since
that's a programming language. We can expect infinitely more from
programmers than we can from users.
It irritates you the first few times until you learn to do it right in
first place, just like it irritates most beginning C programmers that the
compiler keeps complaining about missing semicolons.
If I'm trying out some new stuff that annoys me three times without me
seeing an obvious error on my part (in the editor of my choice) I
usually write it down as broken and move on.
Computers will be annoying about syntax until they learn to do what
I want them to do rather than what I tell them to do, at which point
they'll be smart enough to start being annoying by doing what they want
to to instead of what I want them to do.
That's not the point. If everything looks good it should work good,
regardless of which editor or tab-setting one's using.
quoted
Of course, since I believe that tabs are always exactly 8 characters, I'd
also be perfectly happy to just declare that anybody who disagrees with me
is a moron and deserves to die (*).
Seriously, you could always have it print warning messages but try to
keep going by assuming 8 space tabs so that at least you can postpone
fixing the problem until your current train of thought has pulled into
the station.
There used to be $TABSIZE (or some such). Check it if you implement
this. Or just skip it entirely. I would prefer the latter.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
So, would this be considered legal or would it barf on baz?
foo # No prefix
bar # tab prefix
baz # 8 spaces prefix
It would barf on baz. "\t" is not a prefix of " ".
Most people have tabsize at 8. Some don't. Some editors insert spaces
instead of tabs while others don't. If we just match strings we'll
end up with users sending bug-reports by cut'n pasting their perfectly
valid-looking config which mixes tabs and spaces just because it's
been edited by people using different editors.
Real fun would be if the mta sends tabs as spaces. Then there'd
be no way at all of telling if the config *is* valid or not.
We have this problem already with whitespace damage in the "before"
parts of patches. Are you suggesting that the user will be confused
because some third party edited their config using an editor that
messed up the leading whitespace and then just left it broken?
There's a certain level of "evil gremlins came in during the night and
added bugs to my code" that I bloody well expect to be confusing!
You might have problems inserting a line that suffers mailer damage,
mailer sends you, but if you had sent it as a context diff, the patch
process would have choked on the whitespace anyway.
I'm not particularly agitating for an indent-based syntax, but it
is moderately popular and successful, and anyone criticising it should
at least know how it works.
The standard interpretation of leading whitespace accepts basically
that subset of "looks right" that is insensitive to tab setting.
Excellent error messages aren't good enough. It's ok for Python, since
that's a programming language. We can expect infinitely more from
programmers than we can from users.
We're talking about git users here, right?
More specifically, we're talking about git users who are pulling from
multiple remote trees, no?
Perhaps you could clarify how this set of people is not a strict
subset of the set of programmers...
quoted
It irritates you the first few times until you learn to do it right in
first place, just like it irritates most beginning C programmers that the
compiler keeps complaining about missing semicolons.
If I'm trying out some new stuff that annoys me three times without me
seeing an obvious error on my part (in the editor of my choice) I
usually write it down as broken and move on.
What part of something like:
Can't figure out nesting level on line 232. Its leading
whitespace (" ", all spaces), is not a prefix or
extension of the whitespace on the preceding line 230
("\t", all tabs).
makes the error non-obvious?
If you refuse to read the error message at all, you can get confused,
but you'll also be confused by perfectly valid code producing diagnostics
like "error: dereferencing pointer to incomplete type" if you forget to
#include the right header 200 lines before the location of your error.
quoted
Computers will be annoying about syntax until they learn to do what
I want them to do rather than what I tell them to do, at which point
they'll be smart enough to start being annoying by doing what they want
to to instead of what I want them to do.
That's not the point. If everything looks good it should work good,
regardless of which editor or tab-setting one's using.
Unfortunately, that's provably impossible, because it will look
different to different people.
Proof by example:
header1
header2 # 4 spaces
body3 # 8 spaces
body4 # one tab
That looks good to me, with 8-space tabs:
header1 {
header2 {
body3
body4
}
}
But it also looks great to someone with 4-space tabs:
header1 {
header2 {
body3
}
body4
}
Too bad it doesn't work the same.
The standard whitespace-parsing algorithm rejects "body4" on the grounds
that it's ambiguous. Simple, robust, and no making guesses that lead
to an error message 20 lines beyond the actual problem. It just says
"Hey! Fix line 4!"
quoted
Seriously, you could always have it print warning messages but try to
keep going by assuming 8 space tabs so that at least you can postpone
fixing the problem until your current train of thought has pulled into
the station.
There used to be $TABSIZE (or some such). Check it if you implement
this. Or just skip it entirely. I would prefer the latter.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
linux@horizon.com wrote:
quoted
So, would this be considered legal or would it barf on baz?
foo # No prefix
bar # tab prefix
baz # 8 spaces prefix
It would barf on baz. "\t" is not a prefix of " ".
But to the human eye they are the same. This is just a backwards way of
making the computer think it's smart by recognizing a difference that,
for all human purposes, aren't there. Like Linus said some posts ago;
software should conform to humans. Not the other way around.
quoted
Real fun would be if the mta sends tabs as spaces. Then there'd
be no way at all of telling if the config *is* valid or not.
We have this problem already with whitespace damage in the "before"
parts of patches. Are you suggesting that the user will be confused
because some third party edited their config using an editor that
messed up the leading whitespace and then just left it broken?
This is supposed to be edited by git config-set (or at least editable).
When that breaks or when someone finds it inconvenient people will start
using their editors. The logical way for a user to align new text to
text 8 spaces away is to use the tab key. Depending on the editor (and
the settings of that editor), the user will seem to have made perfectly
correct changes that git will barf on, which brings us back to "software
should conform to humans".
In short; This proposed format is just one step above a binary-format
config file from the user-friendliness perspective.
There's a certain level of "evil gremlins came in during the night and
added bugs to my code" that I bloody well expect to be confusing!
Can't help you there. I only do the cuddly mogwais.
You might have problems inserting a line that suffers mailer damage,
mailer sends you, but if you had sent it as a context diff, the patch
process would have choked on the whitespace anyway.
git only does unified diffs (but doesn't allow any fuzz, so it would
break those too).
I'm not particularly agitating for an indent-based syntax, but it
is moderately popular and successful, and anyone criticising it should
at least know how it works.
The standard interpretation of leading whitespace accepts basically
that subset of "looks right" that is insensitive to tab setting.
quoted
Excellent error messages aren't good enough. It's ok for Python, since
that's a programming language. We can expect infinitely more from
programmers than we can from users.
We're talking about git users here, right?
More specifically, we're talking about git users who are pulling from
multiple remote trees, no?
Perhaps you could clarify how this set of people is not a strict
subset of the set of programmers...
Package maintainers, tech-doc writers. Not really suits, but with a hint
of tie nonetheless.
quoted
That's not the point. If everything looks good it should work good,
regardless of which editor or tab-setting one's using.
Unfortunately, that's provably impossible, because it will look
different to different people.
Proof by example:
header1
header2 # 4 spaces
body3 # 8 spaces
body4 # one tab
That looks good to me, with 8-space tabs:
header1 {
header2 {
body3
body4
}
}
But it also looks great to someone with 4-space tabs:
header1 {
header2 {
body3
}
body4
}
Too bad it doesn't work the same.
The standard whitespace-parsing algorithm rejects "body4" on the grounds
that it's ambiguous.
What I conclude from these examples are that;
1. Any brace-parsing algorithm does the right thing for every case.
2. Indentation-level parsing doesn't, so it's less robust.
Indentation-level parsing is nice-ish in a programming language because
it enforces strong typing so others that read your program can easily do
so. I personally disagree with that, but I can see the point.
How important is it that others can easily read your configuration file?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Nikolai Weibull <hidden> Date: 2016-06-15 22:42:13
Andreas Ericsson wrote:
Excellent error messages aren't good enough. It's ok for Python, since
that's a programming language. We can expect infinitely more from
programmers than we can from users.
A semi-related question: who is the target audience of git? I get the
feeling that most users will be programmers, so that's kind of a
non-argument (even though I agree with your standpoint).
Furthermore, does it really matter what format .git/config has now that
we have git-config-set? Shouldn't all access go through that command,
so that we can change to some other format (YAML, XML, STUPIDABBR) if we
so desire without breaking anything?
Finally, a plain-text easy-to-edit format is great, and that's a good
enough argument not to use indentation (as has already been pointed out,
indentation is not always what it seems).
nikolai
--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
On 11/22/05, Nikolai Weibull [off-list ref] wrote:
who is the target audience of git? I get the
feeling that most users will be programmers, so that's kind of a
non-argument (even though I agree with your standpoint).
If Git is successful, then there will also be a lot of bleeding-edge
users, people who want to be able to:
* Get the latest and greatest (and build it and run it)
* Browse the repository (with gitk or gitweb)
* Maybe (very occasionnally) create a simple patch
This is already the case with CVS, plenty of people know (or are
instructed to do) cvs checkout, cvs update, and nothing more. That's
not much, but they're CVS users, nevertheless.