Why is C syntax so uneasy on the eye?
In its day, was it _really_ designed by snobby programmers to scare away
potential "n00bs"? If so, and after 50+ years of programming research,
why are programming languages still being designed with C's syntax?
These questions drive me insane. Every waking minute...
Nov 14 '05
177  6825 
On Mon, 31 May 2004, Dr Chaos wrote:
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> wrote:
Not that I'm disagreeing, but *is* there any ambiguity avoided
by requiring parens around the condition in a 'do...while' loop?[1]
I don't know about C, but it may have been a holdover from Fortran,
where it does matter:
The Fortran 'DO' is somewhat different from the C 'do', if I
understand correctly. And neither of them is spelled 'if', as
in your examples below, which makes me suspect you didn't really
grasp the point.
! fortran
if (condition = something) then
because
if condition = something
can be also
ifcondition = something
an assignment.
s/can be also/actually means/, of course.
In C I don't see the issue, I admit.
Obviously, that
if foo (bar);
could be treated as either a conditional on foo with (bar); in the body,
or as a conditional on foo(bar) with a null statement in the body.
Requiring an extra set of parentheses around the condition disambiguates
the syntax.
-Arthur
[1] - leaving in the disclaimer for the benefit of jumpers-in... (Also, there's no ambiguity avoided by the requirement of a semicolon
following the label of a 'goto'. Just defusing potential "do you
know you're being utterly ridiculous" responses. ;)
-Arthur
On Mon, 31 May 2004, ozbear wrote:
re********@yahoo.com (red floyd) wrote: Da*****@cern.ch (Dan Pop) wrote: None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...
Not true. You're living in the present. In the past, when punch card
input was the norm, indentation had a meaning. In particular, FORTRAN
IV required input to begin in column 7 [...], with a '*' in
column [six] as continuation...
Cobol also (originally) used column-positional syntax, Area A,
Area B, and so on.
Columns 1 through 6 (or 7) was for sequence numbers, followed by
Area A for paragraph names, and Area B for code, but its been a long
time.
At any rate, Dan is incorrect.
No, as far as I can tell Dan is correct in this case (depending
on your definition of "mainstream"). Neither Fortran nor COBOL were
*free-form* languages, but they certainly weren't indentation-sensitive.
See the RPG language for another slightly more modern (but much less
"mainstream") example, IIRC.
Fortran was not indentation-sensitive; in fact, one of the most
widespread anecdotes about Fortran is the "DO20I = 1.10" incident,
which hinges on the fact that Fortran didn't recognize anything
special about whitespace *at* *all*! You could write[1]
C WITH INDENTATION
DO 50 I=1, 99
BOTTLS = 100-I
PRINT 10, BOTTLS
10 FORMAT(1X, I2, 31H BOTTLE(S) OF BEER ON THE WALL.)
50 CONTINUE
STOP
END
or equally
C WITHOUT ANY INDENTATION
DO 50 I=1, 99
BOTTLS = 100-I
PRINT 10, BOTTLS
10 FORMAT(1X, I2, 31H BOTTLE(S) OF BEER ON THE WALL.)
50 CONTINUE
STOP
END
The fact that punch cards in the Good Old Days Before I Was
Born(TM) had designated areas in which it was okay to punch holes
representing code, or line numbers, or comments, has nothing to
do with the concept of "indentation."
See thread
http://groups.google.com/gr*************************@online.de
in comp.lang.misc for some discussion tangentially related to
this topic. In fact, I'd suggest this whole discussion move
there, if you want to keep arguing about what's "indentation"
and what's not. Followups set.
-Arthur
[1] - Shamelessly nicked from the 99 Bottles of Beer project
and shortened with a blunt instrument. No warranties on
correctness.
Mark McIntyre <ma**********@spamcop.net> writes:
|> >|> Yet another bogus generalisation coming from Joona. Quoting
|> >|> from a post from a French mailing list:
|> >|> ton enfant ? quel age?
|> >Doubtlessly a typo. Or simply incorrect use.
|> The second is a typo. I work for a french bank, and the vast
|> majority of french expats use spaces before and after emphatic
|> punctuation. Only the anglicised french omit the space.
|> Remind me what this has to do with C....
The French also put spaces before the semicolons in C programs:-).
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Dr Chaos <mb****************@NOSPAMyahoo.com> wrote:
Besides, how many former Visual Basic programmers were really long-time
"regular" BASIC programmers? Not that large a fraction.
Why do you say that? I thought the whole raison d'etre of VB
was so that people who grew up with BASIC would still be in the
familiar. Why else would anybody use such a horrible language?
> The second is a typo. I work for a french bank, and the vast majority of french expats use spaces before and after emphatic punctuation. Only the
anglicised french omit the space.
Well, in fact, both are wrong and right at the same time.
Typographically speaking, the kind of spacing that should be used just
before a punctuation mark such as a question mark or an exclamation mark
is NOT the same as the spacing used between two words, for instance.
It should be a "quart de cadratin", which is much less wide.
Unfortunately, plain ASCII text doesn't have much notion of typographic
spacing. It only knows of a basic space, which is as wide as can be.
Thus, I consider putting extra spaces before punctuation marks
a typo when using plain ASCII text, and more esthetically pleasing
to the eye to omit them. French or not.
I especially hate those who put a space before a period. Like this:
"This is fucked up ."
It's just confusing, ugly, and makes no typographic sense.
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@unix49.a ndrew.cmu.edu... Obviously, that
if foo (bar);
could be treated as either a conditional on foo with (bar); in the body,
or as a conditional on foo(bar) with a null statement in the body.
Requiring an extra set of parentheses around the condition disambiguates
the syntax.
Consider the meanings of
if (foo)(bar);
and
if (foo) (bar);
That one little space changes things drastically.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
On Mon, 31 May 2004 13:56:01 -0700, Old Wolf wrote: Dr Chaos <mb****************@NOSPAMyahoo.com> wrote:
Besides, how many former Visual Basic programmers were really long-time
"regular" BASIC programmers? Not that large a fraction.
Why do you say that? I thought the whole raison d'etre of VB
was so that people who grew up with BASIC would still be in the
familiar. Why else would anybody use such a horrible language?
Because Microsoft sells it, and anything they sell for that much money
must be worth buying?
:: Wait for laughter ::
Some schools teach VB. I guess they think it will be an easy language to
learn. Of course, since Python doesn't have a shiny IDE, it isn't a real
language. Besides, that nice Mr. Gates says open source is The DEVIL!
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
Dr Chaos <mb****************@NOSPAMyahoo.com> wrote: On Wed, 26 May 2004 22:02:42 +0100, C# Learner <cs****@learner.here> wrote: Why is C syntax so uneasy on the eye?
In its day, was it _really_ designed by snobby programmers to scare away
potential "n00bs"?
No, but the programmers who designed it didn't care about "n00bs";
their target audience was people who worked at Bell Labs. They were
all very very smart.
Erm... If so, and after 50+ years of programming research,
why are programming languages still being designed with C's syntax?
Profound anti-intellectualism among practitioners, and cargo-cult
imitation.
....don't you think these two statements are contradictory?
Richard
"I. Appel" <ia****@rol.ru> wrote:
[ Please do not snip attribution lines of people whose text you leave in
your replies. I have no idea who wrote the following: ] Well, rephrasing Paul Graham, I should say "Don't wait until C will
become as clear as Python, use Python instead".
If you really think Python has clearer syntax than C, well, think twice.
Python programs are easier to read and understand, that's what I understand
as "clear".
Pardon me: _you_ consider Python programs to be easier to read and
understand. Other people, amongst whom the twice-quoted contributer
above and myself, disagree.
Richard
On Tue, 1 Jun 2004, Stephen Sprunk wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote... if foo (bar);
could be treated as either a conditional on foo with (bar); in the body,
or as a conditional on foo(bar) with a null statement in the body.
Requiring an extra set of parentheses around the condition disambiguates
the syntax.
Consider the meanings of
if (foo)(bar);
and
if (foo) (bar);
That one little space changes things drastically.
For the benefit of jumpers-in: That one little space changes things
drastically only in some hypothetical language that is NOT C. C not
only treats most whitespace the same as a single space; it also ignores
most of it. Spaces around parentheses, for example, don't mean squat.
And I wouldn't want to risk programming in a language that *did* assign
critical meaning to single spaces, especially unobtrusive ones like
that.
-Arthur,
signing off
In <40bafec8.172335531@news-server> oz****@bigpond.com (ozbear) writes: On 29 May 2004 19:35:09 -0700, re********@yahoo.com (red floyd) wrote:
Da*****@cern.ch (Dan Pop) wrote in message news:<c9**********@sunnews.cern.ch>... In <bu********************************@4ax.com> Alan Balmer <al******@att.net> writes:
None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...
Not true. You're living in the present. In the past, when punch card
input was the norm, indentation had a meaning. In particular, FORTRAN
IV required input to begin in column 7 (or was it 8?), with a '*' in
column 6(7) as continuation...
DISCLAIMER: It's been nigh onto 25 years since I've done FORTRAN IV.
My info on the specific columns may be incorrect.
Column 6 was for the continuation. Your code had to fit in columns
7 through 72. 73 through 80 was for a card sequence number, and
ignored by the compiler, IIRC.
Cobol also (originally) used column-positional syntax, Area A,
Area B, and so on.
Columns 1 through 6 (or 7) was for sequence numbers, followed by
Area A for paragraph names, and Area B for code, but its been a long
time.
At any rate, Dan is incorrect.
Why? None of these examples count as indentation being semantically
significant. You're merely confusing the fixed format of certain
languages and indentation.
FYI: I've used both fixed format Fortran and fixed format assemblers,
but fixed format has nothing to do with *indentation* being semantically
significant.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <79*************************@posting.google.com> ,
Paul Hsieh <qe*@pobox.com> wrote: "Justin Rogers" <Ju****@games4dotnet.com> wrote: Note that they point out you can leave out parens only when it won't lead to
ambiguity. C doesn't make that mistake. They make sure there is no
ambiguity, and if you leave out a parens it doesn't make the statement
ambiguous, it makes it a different or erroneous statement altogether.
C has plenty of ambiguity:
I see no ambiguity here. Things that may not match what you want, yes.
If you hate C so much, why do you still use it?
- Braces are optional if there is only one statement for if() or for() or
while(). (But not for do ... while(), switch, or structure/union
declarations.)
There is always precisely one statement controlled by if, for, while, or
do..while (and even switch, though it's rather useless there). That one
statement may be a simple expression statement or a compound statement;
compound statements (by definition) begin with a '{' and end with a '}'.
struct and union declarations don't involve any statements, so your
claim is meaningless when applied to that.
- If a statement has multiple side effects, the order in which those side
effects take place can be unknown.
If a statement has multiple side effects whose order is relevant,
it shouldn't've been written as a single statement in the first place.
If the only purpose of defining something is so that you can look at the
language definition to find out what bad code is really doing, it's not
worth defining.
- The right shift operator may or may not sign extend signed integers. Its
implementation defined.
Is there any reason why it should be defined in some particular way?
If you want sign extension of signed integers, use the division operator;
any self-respecting compiler will use a shift instruction for that where
it's appropriate. If you want to move the bits around without worrying
about sign bits, use unsigned integers and avoid the sign bit entirely.
- The size of an integer is platforms specific.
So? Do you care if the machine gives you 16 more bits than you need?
- The number of bits in a bytes is platform specific.
So? Do you care if the system gives you 2 more bits than you need?
- Try this one on for size:
char a = -1, b = -2;
unsigned short x = (1 > 0) ? a : b;
printf ("x = %d\n", x);
What do you think is printed out? Explain it.
A number that, if you think about it hard enough, will give you some clue
about whether char is signed and possibly about how signed integers are
represented internally.
You're lying to printf; what did you expect, a compiler error saying
"That's not what you meant"?
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Conclusion: You are not only a masochist, but a stubborn masochist.
--Eric Sosman in comp.lang.c Da*****@cern.ch (Dan Pop) wrote in message news:<c9**********@sunnews.cern.ch>...
None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...
TTCN. It's mainstream if you work in telecoms, but, as your comment
implies, it's unpleasant in the extreme.
> Pascal and C are of the same age almost. Pascal maybe 2-3 years older than C, not more
Well, technically, you're right. Pascal was officially unveiled at about
the same time as C appeared, but the whole history behind Pascal (and
Ada) is a lot older.
To me, Pascal remains the language of choice to teach a structured,
procedural language. C was originally made to be used by experienced
programmers, and (even if that will raise some eyebrows here and there)
I think this still applies nowadays.
Python programs are easier to read and understand, that's what I understand
as "clear". And I had never such problems as leaving behind tabs or spaces,
it's generally no problem with good text editor.
That's a matter of taste, I guess. Many of us seem to disagree, though.
As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal, Ada...)
I still think it's a visual improvement for readability - and shouldn't
be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness". rl*@hoekstra-uitgeverij.nl (Richard Bos) writes: Dr Chaos <mb****************@NOSPAMyahoo.com> wrote:
On Wed, 26 May 2004 22:02:42 +0100, C# Learner <cs****@learner.here> wrote: > Why is C syntax so uneasy on the eye?
>
> In its day, was it _really_ designed by snobby programmers to scare away
> potential "n00bs"?
No, but the programmers who designed it didn't care about "n00bs";
their target audience was people who worked at Bell Labs. They were
all very very smart.
Erm...
> If so, and after 50+ years of programming research,
> why are programming languages still being designed with C's syntax?
Profound anti-intellectualism among practitioners, and cargo-cult
imitation.
...don't you think these two statements are contradictory?
No. The practitioners and imitators are (mostly?) not the people
who worked at Bell Labs and designed C.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
On 29 May 2004 19:35:09 -0700, re********@yahoo.com (red floyd) wrote: Da*****@cern.ch (Dan Pop) wrote in message news:<c9**********@sunnews.cern.ch>... In <bu********************************@4ax.com> Alan Balmer <al******@att.net> writes:
None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...
Not true. You're living in the present. In the past, when punch card
input was the norm, indentation had a meaning. In particular, FORTRAN
IV required input to begin in column 7 (or was it 8?), with a '*' in
column 6(7) as continuation...
DISCLAIMER: It's been nigh onto 25 years since I've done FORTRAN IV.
My info on the specific columns may be incorrect.
Fortran IV had a fixed format for cards, but indentation was not
meaningful. The code area started in column 7, but you could use
whitespace any way you liked within that constraint. It did not assign
any semantics to indentation, as Python does.
BTW, your attributions are messed up - I didn't write anything you
quoted.
--
Al Balmer
Balmer Consulting re************************@att.net
Guillaume <gr*******@NO-SPAMmail.com> writes:
|> > The second is a typo. I work for a french bank, and the vast
|> > majority of french expats use spaces before and after emphatic
|> > punctuation. Only the anglicised french omit the space.
|> Well, in fact, both are wrong and right at the same time.
|> Typographically speaking, the kind of spacing that should be used
|> just before a punctuation mark such as a question mark or an
|> exclamation mark is NOT the same as the spacing used between two
|> words, for instance. It should be a "quart de cadratin", which is
|> much less wide.
Not much less. A "cadratin" is a quad in English -- originally, a
square piece of lead, whose width is the same as its height. The space
before "high" punctuation is an "espace fine", nominally a fourth of a
quad. The nominal width of a space between words is a third of a quad.
For twelve point type, we're talking about 3pt vs. 4pt. And the 4pt
interword space can be stretched OR SHRUNK somewhat to make the line
fit; on a tightly spaced line, it takes a good eye to see the difference
between an espace mot and an espace fine.
|> Unfortunately, plain ASCII text doesn't have much notion of
|> typographic spacing. It only knows of a basic space, which is as
|> wide as can be.
Agreed. It's even wider than a normal word space.
|> Thus, I consider putting extra spaces before punctuation marks a
|> typo when using plain ASCII text, and more esthetically pleasing to
|> the eye to omit them. French or not.
As someone used to reading French, I find it jarring if there isn't some
space. And the space I expect isn't that far from the normal word space
that it bothers me.
Of course, when I"m typing or reading English or German, I use different
rules.
|> I especially hate those who put a space before a period. Like this:
|> "This is fucked up ."
Quite. At least in the typographical conventions I'm familiar with:
French, German and English. Given the variety, I wouldn't really
surprise me if this were the norm for some language, however.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Guillaume <gr*******@NO-SPAMmail.com> writes: Pascal and C are of the same age almost. Pascal maybe 2-3 years older than
C, not more
Well, technically, you're right. Pascal was officially unveiled at about
the same time as C appeared, but the whole history behind Pascal (and
Ada) is a lot older.
C grew out of the same history as Pascal; they're both descendents of
Algol, though C is less of a direct descendent. C's declaration
syntax, at least in its simple forms, is more Algol-like than Pascal's
is:
Algol: integer i;
C: int i;
Pascal: i: integer;
As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal, Ada...)
I still think it's a visual improvement for readability - and shouldn't
be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness".
(As long as we have an '[OT]' tag on this thread ...)
I haven't played with Python enough to form a strong opinion about its
indentation-oriented syntax, but I think I like it. When I program in
a language that expressions nesting with delimiters (begin/end, {/},
case/esac), I maintain strictly consistent indentation anyway. I go
to the effort of indenting my code properly, and the compiler doesn't
even warn me if I get it wrong. Python lets me omit the delimiters;
the indentation is exactly what it would have been if Python required
delimiters as well.
C's use of delimiters to denote nesting allows some flexibility that
Python doesn't, but I see no virtue in that flexibility. C allows
incorrect, or even misleading, indentation:
if (cond1)
if (cond2)
some_statement;
else
some_other_statement;
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Well, I had to place more IMO's, but check this:
foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
Well, it's not very clear, but how many lines of code in C
would be required to reproduce it? Types of x and y can be
either lists of lists, lists of strings, lists of numbers
or strings. And it maybe used for all that stuff.
I don't understand, how several dozens lines of code can be
better than ONE line of code in non-esoteric language.
Read "Succinctness is Power" and "Revenge of the Nerds" by Paul
Graham, if you want more.
Ivan.
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:40****************@news.individual.net... "I. Appel" <ia****@rol.ru> wrote:
[ Please do not snip attribution lines of people whose text you leave in
your replies. I have no idea who wrote the following: ]
> Well, rephrasing Paul Graham, I should say "Don't wait until C will
> become as clear as Python, use Python instead".
If you really think Python has clearer syntax than C, well, think
twice.
Python programs are easier to read and understand, that's what I
understand as "clear".
Pardon me: _you_ consider Python programs to be easier to read and
understand. Other people, amongst whom the twice-quoted contributer
above and myself, disagree.
Richard
"Guillaume" <gr*******@NO-SPAMmail.com> wrote in message
news:40*********************@news.club-internet.fr... Pascal and C are of the same age almost. Pascal maybe 2-3 years older
than C, not more
Well, technically, you're right. Pascal was officially unveiled at about
the same time as C appeared, but the whole history behind Pascal (and
Ada) is a lot older.
The concepts behind them are almost the same. Maybe C is a bit more
influenced
by low-level programming and functional programming, but it's as structured
as Pascal.
To me, Pascal remains the language of choice to teach a structured,
procedural language. C was originally made to be used by experienced
programmers, and (even if that will raise some eyebrows here and there)
I think this still applies nowadays.
I can't disagree with you. When I studied programming at my university,
it was really hard for inexperienced people to code in C. I suppose, it
would be pretty simpler for them to learn Pascal first.
Some Python and Java zealots suppose their stuff to be the best learning
language instead of Pascal, but I'm not agree.
Python programs are easier to read and understand, that's what I
understand as "clear". And I had never such problems as leaving behind tabs or
spaces, it's generally no problem with good text editor.
That's a matter of taste, I guess. Many of us seem to disagree, though.
I've seen code in C and Java written by several Python-haters. Most of them
don't use indents at all, so their code is pretty hard to read. See below.
As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal, Ada...)
I still think it's a visual improvement for readability - and shouldn't
be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness".
Well, main idea behind Python's syntax is "we use indentation anyway (most
of
us at least), so what's the reason to make syntax redundant and to use
_both_
indents and delimiters?"
Are you agree?
On 1 Jun 2004 15:29:53 GMT, Da*****@cern.ch (Dan Pop) wrote: In <40bafec8.172335531@news-server> oz****@bigpond.com (ozbear) writes:
On 29 May 2004 19:35:09 -0700, re********@yahoo.com (red floyd) wrote:
Da*****@cern.ch (Dan Pop) wrote in message news:<c9**********@sunnews.cern.ch>...
In <bu********************************@4ax.com> Alan Balmer <al******@att.net> writes:
None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...
Not true. You're living in the present. In the past, when punch card
input was the norm, indentation had a meaning. In particular, FORTRAN
IV required input to begin in column 7 (or was it 8?), with a '*' in
column 6(7) as continuation...
DISCLAIMER: It's been nigh onto 25 years since I've done FORTRAN IV.
My info on the specific columns may be incorrect.
Column 6 was for the continuation. Your code had to fit in columns
7 through 72. 73 through 80 was for a card sequence number, and
ignored by the compiler, IIRC.
Cobol also (originally) used column-positional syntax, Area A,
Area B, and so on.
Columns 1 through 6 (or 7) was for sequence numbers, followed by
Area A for paragraph names, and Area B for code, but its been a long
time.
At any rate, Dan is incorrect.
Why? None of these examples count as indentation being semantically
significant. You're merely confusing the fixed format of certain
languages and indentation.
FYI: I've used both fixed format Fortran and fixed format assemblers,
but fixed format has nothing to do with *indentation* being semantically
significant.
Nope. "Fixed format" is just a ruse to cover up what is actually
fixed indentation. If those rules were violated you didn't even
get to what was semantically equivalent because you never got past
compilation.
If you put your Fortran continuation character in the wrong column
you could easily end up with errors.
The point is that those columns had meaning to the compiler hence one
had to indent, hence indentation had meaning.
Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
In article <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
.... C grew out of the same history as Pascal; they're both descendents of
Algol, though C is less of a direct descendent.
Lessee. C if offspring from Jovial and the kind, which is offspring from
Algol 58. Pascal became because in the depelopment of Algol 68 Wirth did
not agree with the direction the committee was going.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
On Tue, 1 Jun 2004 21:06:34 +0600, "I. Appel"
<ia****@rol.kill.the.spammers.ru> wrote: Well, I had to place more IMO's, but check this:
foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
Well, it's not very clear, but how many lines of code in C
would be required to reproduce it? Types of x and y can be
either lists of lists, lists of strings, lists of numbers
or strings. And it maybe used for all that stuff.
I don't understand, how several dozens lines of code can be
better than ONE line of code in non-esoteric language.
As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.
--
Al Balmer
Balmer Consulting re************************@att.net
On Wed, 2 Jun 2004 12:21:48 +0600, "I. Appel"
<ia****@rol.kill.the.spammers.ru> wrote:
I've seen code in C and Java written by several Python-haters. Most of them
don't use indents at all, so their code is pretty hard to read. See below.
You need to expand your circle of acquaintances :-) Most C and Java
programmers (in fact, all) that I know use indents, whether or not
they hate Python. As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal, Ada...)
I still think it's a visual improvement for readability - and shouldn't
be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness".
Well, main idea behind Python's syntax is "we use indentation anyway (most
of
us at least), so what's the reason to make syntax redundant and to use
_both_
indents and delimiters?"
Are you agree?
Nope.
--
Al Balmer
Balmer Consulting re************************@att.net
In <40bd955e.341957500@news-server> oz****@bigpond.com (ozbear) writes: On 1 Jun 2004 15:29:53 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <40bafec8.172335531@news-server> oz****@bigpond.com (ozbear) writes:
On 29 May 2004 19:35:09 -0700, re********@yahoo.com (red floyd) wrote:
Da*****@cern.ch (Dan Pop) wrote in message news:<c9**********@sunnews.cern.ch>...
> In <bu********************************@4ax.com> Alan Balmer <al******@att.net> writes:
> None of the programming languages assigning semantics to indentation
> has ever become mainstream. There must be a reason...
Not true. You're living in the present. In the past, when punch card
input was the norm, indentation had a meaning. In particular, FORTRAN
IV required input to begin in column 7 (or was it 8?), with a '*' in
column 6(7) as continuation...
DISCLAIMER: It's been nigh onto 25 years since I've done FORTRAN IV.
My info on the specific columns may be incorrect.
Column 6 was for the continuation. Your code had to fit in columns
7 through 72. 73 through 80 was for a card sequence number, and
ignored by the compiler, IIRC.
Cobol also (originally) used column-positional syntax, Area A,
Area B, and so on.
Columns 1 through 6 (or 7) was for sequence numbers, followed by
Area A for paragraph names, and Area B for code, but its been a long
time.
At any rate, Dan is incorrect.
Why? None of these examples count as indentation being semantically
significant. You're merely confusing the fixed format of certain
languages and indentation.
FYI: I've used both fixed format Fortran and fixed format assemblers,
but fixed format has nothing to do with *indentation* being semantically
significant.
Nope. "Fixed format" is just a ruse to cover up what is actually
fixed indentation. If those rules were violated you didn't even
get to what was semantically equivalent because you never got past
compilation.
If you put your Fortran continuation character in the wrong column
you could easily end up with errors.
The point is that those columns had meaning to the compiler hence one
had to indent, hence indentation had meaning.
You're confusing fixed format and indentation. No amount of indentation
past column 7 has any semantic meaning in any Fortran version I'm familiar
with. Fixed format Fortran *completely* ignores any space character that
is not part of a "string literal". Because of this, it is sheer idiocy to
claim that indentation plays any *semantic* role in fixed format Fortran.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Alan Balmer" <al******@att.net> wrote in message
news:f3********************************@4ax.com... Well, I had to place more IMO's, but check this:
foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
Well, it's not very clear, but how many lines of code in C
would be required to reproduce it? Types of x and y can be
either lists of lists, lists of strings, lists of numbers
or strings. And it maybe used for all that stuff.
I don't understand, how several dozens lines of code can be
better than ONE line of code in non-esoteric language.
As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.
What is the reason to have syntax that is clearer-per-line, if it
requires to write several times more lines of code?
Ivan.
"Alan Balmer" <al******@att.net> wrote in message
news:b9********************************@4ax.com... As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal,
Ada...) I still think it's a visual improvement for readability - and
shouldn't be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness".
Well, main idea behind Python's syntax is "we use indentation anyway
(mostof
us at least), so what's the reason to make syntax redundant and to use
_both_
indents and delimiters?"
Are you agree?
Nope.
Well, it's a matter of taste and habits (some of had to tell that :-))), so
let's stop discussion here. I like syntaxes of both C and Python, while I
consider,
that both have their disadvantages.
Ivan.
On Wed, 2 Jun 2004, I. Appel wrote:
"Alan Balmer" <al******@att.net> wrote...
[I. Appel, watch your attributions! ISTR *you* wrote:]
foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
Well, it's not very clear, but how many lines of code in C
would be required to reproduce it?
As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.
What is the reason to have syntax that is clearer-per-line, if it
requires to write several times more lines of code?
Let's suppose C is five times clearer per line than your brand
of (is that obfuscated Haskell?), and it takes five times as many
lines of C code to write the same thing as you can write in
(whatever language that is).
Five times clearer per line, multiplied by five times as many
lines, yields twenty-five times the clarity. Hence, C is better
than Haskell. Q.E.D.
[that was a joke, son]
And now can you take the language wars off to comp.lang.misc or
somewhere else that actually *needs* the traffic?
-Arthur,
nonce equitur
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
Why do you say that? I thought the whole raison d'etre of VB
was so that people who grew up with BASIC would still be in the
familiar. Why else would anybody use such a horrible language?
Microsoft was built on BASIC interpreters, so I imagine they keep the
langauge going for sentimental reasons.
"Dr Chaos" <mb****************@NOSPAMyahoo.com> wrote in message
news:sl*******************************@lyapunov.uc sd.edu... Malcolm <ma*****@55bank.freeserve.co.uk> wrote:
"Dr Chaos" <mb****************@NOSPAMyahoo.com> wrote in message Profound anti-intellectualism among practitioners, and cargo-cult
imitation. This spurious idea being that "gee, C was popular; so
why don't we make our language with Cish syntax so we might be
popular too."
Or maybe "C is popular so let's use a syntax that most programmers are
already familiar with".
Actually I think that's can be a worse idea---suggesting something
that 'almost works' the same, but in fact is subtly different is quite
dangerous.
Like, in the USA you might want to give your buddy who's had too much
to drink "a ride" home, but if you try offer that to your mates in
Sydney (as opposed to a "lift") you're likely to get socked. At least
in most straight bars.
Just don't "knock me up" in the morning!
When I began programming I used "Business BASIC" which compiled into an .exe
and (shockingly) didn't require line numbers unless you were going to "GOTO"
it. In those days a compile used to take 40 minutes or an hour or so. You
would "desk check" your code quite thoroughly, so after the compile it
actually worked. Programmers would time their builds - i.e. "You gonna
compile today?" "Yeah, I about an hour" "OK, meet you out back. See if Carl
is ready and we can play some craps..." "'K"
Then I learned Pascal and it was my language of choice for programming.
Remember Borland's "Turbo Pascal"? Compile times of 1 or 2 minutes, or less
for small stuff. It was amazing and I stopped losing so much money to Carl.
:-)
Anyhow, the point is that when I learned C, it was quite a lot like Pascal.
In fact it was TOO alike. I loved Turbo Pascal but the syntax was just about
the same as C, but it was hard to keep both in my brain. I finally had to
pick C and I've never looked back.
I see new developments like C# as a similar "problem". You can be a C++
"generic OS" programmer, or you can buy into the Microsoft World (tm) and go
with C#, but I believe it will be hard to keep the two in one's mind at the
same time. This is where the programmer will have to make a conscious
decision. (Best Darth Vader voice) "Feel the Power of the Dark Side."
--
Mabden
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote: "Old Wolf" <ol*****@inspire.net.nz> wrote in message
Why do you say that? I thought the whole raison d'etre of VB
was so that people who grew up with BASIC would still be in the
familiar. Why else would anybody use such a horrible language?
Microsoft was built on BASIC interpreters, so I imagine they keep the
langauge going for sentimental reasons.
Micro$oft and sentiment... ya, right. They keep VB going because they
can sell large numbers of copies of VB to large numbers of
semi-professional suckers.
Richard
In <c9**********@news6.svr.pol.co.uk> "Malcolm" <ma*****@55bank.freeserve.co.uk> writes: "Old Wolf" <ol*****@inspire.net.nz> wrote in message
Why do you say that? I thought the whole raison d'etre of VB
was so that people who grew up with BASIC would still be in the
familiar. Why else would anybody use such a horrible language?
Microsoft was built on BASIC interpreters, so I imagine they keep the
langauge going for sentimental reasons.
More likely, because BASIC is easier to learn than most other programming
languages. It's also well interfaced with other Microsoft products, like
Excel.
If someone is interested in becoming an amateur programmer on Windows,
I can't imagine anything more suitable for the purpose than VB.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: (As long as we have an '[OT]' tag on this thread ...)
I haven't played with Python enough to form a strong opinion about its
indentation-oriented syntax, but I think I like it. When I program in
a language that expressions nesting with delimiters (begin/end, {/},
case/esac), I maintain strictly consistent indentation anyway. I go
to the effort of indenting my code properly, and the compiler doesn't
even warn me if I get it wrong. Python lets me omit the delimiters;
the indentation is exactly what it would have been if Python required
delimiters as well.
C's use of delimiters to denote nesting allows some flexibility that
Python doesn't, but I see no virtue in that flexibility.
If the ASCII HT character (and its likes in other character sets,
represented as \t in C) hadn't been invented or had very solidly defined
semantics, I would have agreed with your analysis. Unfortunately, their
invention as loosely defined control characters opened Pandora's box...
The immediate reaction to this remark: "if you never use them, their
existence doesn't hurt you" is, unfortunately, too naive:
1. Even if you don't, someone else may. With different semantics than
your defaults. People dealing with other people's code are probably
well aware of the issue. But in C, the block delimiters provide all
the information needed for fixing the indentation broken by the HTs...
2. Even if you don't, some text processing utilities may do it behind your
back. A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to the ts
variable setting. Since I have found no portable way of disabling this
feature, I'm setting ts to 100 in my .exrc.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
> > >foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
Well, it's not very clear, but how many lines of code in C
would be required to reproduce it? Types of x and y can be
either lists of lists, lists of strings, lists of numbers
or strings. And it maybe used for all that stuff.
I don't understand, how several dozens lines of code can be
better than ONE line of code in non-esoteric language.
As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.
What is the reason to have syntax that is clearer-per-line, if it
requires to write several times more lines of code?
The functional versional would be compact and neat, but almost certainly
slower to exectue; the imperative version would be bigger, uglier, but most
probably faster. No one can claim that one is better than another, as it
completely depends on what you are trying to achieve.
Mike
On Thu, 3 Jun 2004, Dan Pop wrote:
[re: hard tabs] A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to the ts
variable setting. Since I have found no portable way of disabling
this feature, I'm setting ts to 100 in my .exrc.
I'm sure you've thought of this, but what happens if you set ts to 0?
I would expect either that it would disable the "feature" altogether,
or that you'd get an error from vi. If the former, then this would be
a better way than setting ts to an arbitrary large value like 100.
-Arthur
In <Pi**********************************@unix49.andre w.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes: On Thu, 3 Jun 2004, Dan Pop wrote:[re: hard tabs] A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to the ts
variable setting. Since I have found no portable way of disabling
this feature, I'm setting ts to 100 in my .exrc.
I'm sure you've thought of this, but what happens if you set ts to 0?
I would expect either that it would disable the "feature" altogether,
or that you'd get an error from vi.
The latter. vi's response to "set ts=0":
Argument must be positive: ts=0
If the former, then this would be
a better way than setting ts to an arbitrary large value like 100.
Not even then. Keep in mind that I have to use vi on texts/programs
written by other people, too (like, e.g. when replying to Usenet posts).
With a ts=0, I would *silently* lose indentation information present in
those texts. With ts=100 I see it as humongously indented text, in which
case I simply reset ts to 8 and get something close to what the author
intended.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
> Well, I had to place more IMO's, but check this:
foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
Well, it's not very clear, but how many lines of code in C
would be required to reproduce it? Types of x and y can be
either lists of lists, lists of strings, lists of numbers
or strings. And it maybe used for all that stuff.
I don't understand, how several dozens lines of code can be
better than ONE line of code in non-esoteric language.
Now one question arises: What exactly does this piece of code do?
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
"Dan Pop" <Da*****@cern.ch> wrote in message
More likely, because BASIC is easier to learn than most other
programming languages. It's also well interfaced with other
Microsoft products, like Excel.
If someone is interested in becoming an amateur programmer on
Windows,
I can't imagine anything more suitable for the purpose than VB.
I'm a BASIC implementer myself, so I wouldn't say anything against the
language. I'd say that the main strength of BASIC is that it is so easy to
write an interpreter - obviously that is now irrelevant to a company with
the resources of Microsoft. That's why it was included on all the 80s
vintage microcomputers, and why I learnt it as my first programming
language. Da*****@cern.ch (Dan Pop) writes:
[... 2. Even if you don't, some text processing utilities may do it behind your
back. A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to the ts
variable setting. Since I have found no portable way of disabling this
feature, I'm setting ts to 100 in my .exrc.
I'm not quite willing to do that, but I do have the following in my
$HOME/.exrc:
map ]^V^I :%!expand^M
where the carets denote the obvious cotro characters.
As I enter code, vi (I use nvi) insists on changing each 8 columns of
indentation to a tab, but before saving the file I can hit a
right-bracket followed by a tab and expand everything to spaces
(unless I'm writing a Makefile, of course).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dan Pop wrote: A typical example is vi, which "optimises" the storage of the saved
text by replacing multiple spaces by HTs according to the ts variable
setting. Since I have found no portable way of disabling this
feature, I'm setting ts to 100 in my .exrc.
Is there a reason why you can't use, say, VIM, which doesn't have this
problem and has an 'expandtab' option and :retab for your convenience?
--
++acr@,ka"
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message news:<c9**********@newsg4.svr.pol.co.uk>... "Dan Pop" <Da*****@cern.ch> wrote in message
More likely, because BASIC is easier to learn than most other
programming languages. It's also well interfaced with other
Microsoft products, like Excel.
If someone is interested in becoming an amateur programmer on
Windows,
I can't imagine anything more suitable for the purpose than VB.
I'm a BASIC implementer myself, so I wouldn't say anything against the
language. I'd say that the main strength of BASIC is that it is so easy to
write an interpreter - obviously that is now irrelevant to a company with
the resources of Microsoft. That's why it was included on all the 80s
vintage microcomputers, and why I learnt it as my first programming
language.
It's also possible to write an interpreter using very little memory.
Which can be difficult for other languages.
Dan Pop wrote: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes: On Thu, 3 Jun 2004, Dan Pop wrote:
[re: hard tabs] A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to
the ts variable setting. Since I have found no portable way
of disabling this feature, I'm setting ts to 100 in my .exrc.
I'm sure you've thought of this, but what happens if you set
ts to 0? I would expect either that it would disable the
"feature" altogether, or that you'd get an error from vi.
The latter. vi's response to "set ts=0":
Argument must be positive: ts=0
What an ugly mechanism. Does that also apply to VIM? I have
sometimes considered installing VIM just to have my editing habits
portable, but that is too big a penalty to pay.
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison
"Mike" <no***@hotmail.com> wrote in message
news:#y**************@tk2msftngp13.phx.gbl... >foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
>
>I don't understand, how several dozens lines of code can be
>better than ONE line of code in non-esoteric language.
As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.
What is the reason to have syntax that is clearer-per-line, if it
requires to write several times more lines of code?
The functional versional would be compact and neat, but almost certainly
slower to exectue; the imperative version would be bigger, uglier, but
most probably faster. No one can claim that one is better than another, as it
completely depends on what you are trying to achieve.
I agree with you, but the discussion is about _clear_ syntaxes.
Ivan.
On Fri, 4 Jun 2004, CBFalconer wrote:
C>Dan Pop wrote:
C>> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
C>>> On Thu, 3 Jun 2004, Dan Pop wrote:
C>>>>
C>>> [re: hard tabs]
C>>>> A typical example is vi, which "optimises" the storage of the
C>>>> saved text by replacing multiple spaces by HTs according to
C>>>> the ts variable setting. Since I have found no portable way
C>>>> of disabling this feature, I'm setting ts to 100 in my .exrc.
C>>>
C>>> I'm sure you've thought of this, but what happens if you set
C>>> ts to 0? I would expect either that it would disable the
C>>> "feature" altogether, or that you'd get an error from vi.
C>>
C>> The latter. vi's response to "set ts=0":
C>>
C>> Argument must be positive: ts=0
C>
C>What an ugly mechanism. Does that also apply to VIM? I have
C>sometimes considered installing VIM just to have my editing habits
C>portable, but that is too big a penalty to pay.
I use nvi for ages and have never seen such 'optimisation' there. And I
used it even on Win3.11.
harti
In article <c9**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: On Thu, 3 Jun 2004, Dan Pop wrote:
[re: hard tabs] A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to the ts
variable setting. Since I have found no portable way of disabling
this feature, I'm setting ts to 100 in my .exrc.
.... The latter. vi's response to "set ts=0":
Argument must be positive: ts=0
Which 'vi' is that? None of the two apply to 'vi' on Solaris, so I
expect it is something that some poor soul thought useful and implented
on some particular system.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In <sl****************@ID-227112.user.uni-berlin.de> Sam Dennis <sa*@malfunction.screaming.net> writes: Dan Pop wrote: A typical example is vi, which "optimises" the storage of the saved
text by replacing multiple spaces by HTs according to the ts variable
setting. Since I have found no portable way of disabling this
^^^^^^^^ feature, I'm setting ts to 100 in my .exrc.
Is there a reason why you can't use, say, VIM, which doesn't have this
problem and has an 'expandtab' option and :retab for your convenience?
Which part of "portable" was too difficult for you to understand?
I like to have a solution that works with whatever I get under the name
of "vi", rather than being tied to a certain vi implementation.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <Hy*******@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes: In article <c9**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:On Thu, 3 Jun 2004, Dan Pop wrote:
[re: hard tabs]
> A typical example is vi, which "optimises" the storage of the
> saved text by replacing multiple spaces by HTs according to the ts
> variable setting. Since I have found no portable way of disabling
> this feature, I'm setting ts to 100 in my .exrc.
... The latter. vi's response to "set ts=0":
Argument must be positive: ts=0
Which 'vi' is that? None of the two apply to 'vi' on Solaris, so I
expect it is something that some poor soul thought useful and implented
on some particular system.
It's not on some particular system but on some very popular vi
implementation: vim, the default vi on most (if not all) Linux
distributions. And, as I've said, I was interested in something that
works *everywhere* there is a vi implementations.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <c9*********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <Hy*******@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:In article <c9**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: >On Thu, 3 Jun 2004, Dan Pop wrote:
>[re: hard tabs]
>> A typical example is vi, which "optimises" the storage of the
>> saved text by replacing multiple spaces by HTs according to the ts
>> variable setting. Since I have found no portable way of disabling
>> this feature, I'm setting ts to 100 in my .exrc.
... The latter. vi's response to "set ts=0":
Argument must be positive: ts=0
Which 'vi' is that? None of the two apply to 'vi' on Solaris, so I
expect it is something that some poor soul thought useful and implented
on some particular system.
It's not on some particular system but on some very popular vi
implementation: vim, the default vi on most (if not all) Linux
distributions. And, as I've said, I was interested in something that
works *everywhere* there is a vi implementations.
Well, the implementation that came with the version of Linux (Fedora) I am
using does indeed disallow ts=0. But it does *not* optimise storage by
replacing multiple spaces by HTs. Just checked vim on Suse, also did not
do that. Also vim on my home machine (a Mac running MacOS) does not perform
that optimisation. Assuming that all vim's are created equal is wrong.
(But I suspect that you are using some obscure option that forces this
feature.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
> 2. Even if you don't, some text processing utilities may do it behind your
back. A typical example is vi, which "optimises" the storage of the
saved text by replacing multiple spaces by HTs according to the ts
variable setting. Since I have found no portable way of disabling this
feature, I'm setting ts to 100 in my .exrc.
I've never seen any way of preventing vi from doing this,
for vim however use expandtab in .vimrc
"second best solution" have ts=sw=x in .exrc,
have expandtab and source .exrc in .vimrc.
Thus tab free files with indentation as selected by you is
obtainable for files under your control -
still this might leave indentation a mess in files received from
elsewhere :-)
In <Hy********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes: In article <c9*********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <Hy*******@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:In article <c9**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:
> >On Thu, 3 Jun 2004, Dan Pop wrote:
> >[re: hard tabs]
> >> A typical example is vi, which "optimises" the storage of the
> >> saved text by replacing multiple spaces by HTs according to the ts
> >> variable setting. Since I have found no portable way of disabling
> >> this feature, I'm setting ts to 100 in my .exrc.
...
> The latter. vi's response to "set ts=0":
>
> Argument must be positive: ts=0
Which 'vi' is that? None of the two apply to 'vi' on Solaris, so I
expect it is something that some poor soul thought useful and implented
on some particular system.
It's not on some particular system but on some very popular vi
implementation: vim, the default vi on most (if not all) Linux
distributions. And, as I've said, I was interested in something that
works *everywhere* there is a vi implementations.
Well, the implementation that came with the version of Linux (Fedora) I am
using does indeed disallow ts=0. But it does *not* optimise storage by
replacing multiple spaces by HTs. Just checked vim on Suse, also did not
do that. Also vim on my home machine (a Mac running MacOS) does not perform
that optimisation. Assuming that all vim's are created equal is wrong.
(But I suspect that you are using some obscure option that forces this
feature.)
You're still not getting it. If no vi ever replaced my spaces by tabs
I wouldn't have searched a solution to the problem in the first place.
I don't remember which vi flavour did that, but I do remember that setting
ts to 0 didn't work and, as I've already explained, even if it worked,
it wouldn't have been a satisfactory solution.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: mike420 |
last post by:
I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro...
|
by: Tuang |
last post by:
I'm checking out Python as a candidate for replacing Perl as my "Swiss
Army knife" tool. The longer I can remember the syntax for performing
a task, the more likely I am to use it on the spot if...
|
by: Sandy Norton |
last post by:
If we are going to be stuck with @decorators for 2.4, then how about
using blocks and indentation to elminate repetition and increase
readability:
Example 1
---------
class Klass:
def...
|
by: George Sakkis |
last post by:
I'm sure there must have been a past thread about this topic but I don't know how to find it: How
about extending the "for <X> in" syntax so that X can include default arguments ? This would be very...
|
by: Carter Smith |
last post by:
http://www.icarusindie.com/Literature/ebooks/
Rather than advocating wasting money on expensive books for beginners,
here's my collection
of ebooks that have been made freely available on-line...
|
by: Nicolas Fleury |
last post by:
Hi everyone, I would to know what do you think of this PEP. Any comment
welcomed (even about English mistakes).
PEP: XXX
Title: Specialization Syntax
Version: $Revision: 1.10 $...
|
by: Jeremy Yallop |
last post by:
Looking over some code I came across a line like this
if isalnum((unsigned char)c) {
which was accepted by the compiler without complaint. Should the
compiler have issued a diagnostic in this...
|
by: Bob hotmail.com> |
last post by:
Everyone
I have been spending weeks looking on the web for a good tutorial on how to use regular expressions and other methods to satisfy my craving for learning how to do FAST c-style syntax...
|
by: Manuel |
last post by:
I'm trying to compile glut 3.7.6 (dowbloaded from official site)using
devc++.
So I've imported the glut32.dsp into devc++, included manually some
headers, and start to compile.
It return a very...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
