C Syntax

[Dan Pop]

[In VIM]
Set sw=4 and leave ts to its default value of 8. Open a new file,
enter insert mode and type " alpha". Save the file and check that
the hand input spaces are there:

Of course.

Reopen the file, with the same vi settings and use the shift right
command, then save the file and check that the hand input spaces are
gone.

The behaviour is consistent between vim on Linux and vi on Solaris, BTW.

Not here; I have 'expandtab' set by default. While there may not be a
universal solution for all vi clones, that's no reason to ignore those
presented by the individual editors you use.

It certainly is, when you expect *consistent* behaviour from vi on all
platforms. The *last* thing I want to do when using vi is remembering on
which platform I am and what is the right solution for my problem.

It is already bad enough that Solaris comes with an ancient, BSD-style
vi that doesn't recognise the cursor keys in input mode...

Dan

 

[Keith Thompson]

It certainly is, when you expect *consistent* behaviour from vi on all
platforms. The *last* thing I want to do when using vi is remembering on
which platform I am and what is the right solution for my problem.

It is already bad enough that Solaris comes with an ancient, BSD-style
vi that doesn't recognise the cursor keys in input mode...

You might consider downloading one of the free vi clones (vim, nvi,
whatever) and building it on Solaris -- though that might not be
practical if you jump around to various machines.

(Way OT: strictly speaking, nvi isn't a vi clone; it's the direct
descendant of the original vi.)

 

[Dik T. Winter]

>
> Reopen the file, with the same vi settings and use the shift right
> command, then save the file and check that the hand input spaces are
> gone:
>
> fangorn:~/tmp 162> od -b foo
> 0000000 011 141 154 160 150 141 012
> 0000007
>
> Where are the spaces I have input with my hand?

Nowhere. With your command you asked vi to recalculate the indentation.
How is vi to know how you want the reindentation to be done? Should it
have added four spaces in front of each line? if so, what about lines
with initial tabs, the tabs should be expanded to spaces?

 

[Dik T. Winter]

>
> It certainly is, when you expect *consistent* behaviour from vi on all
> platforms. The *last* thing I want to do when using vi is remembering on
> which platform I am and what is the right solution for my problem.

Wrong. You expect consistent behaviour from vi and vim, two completely
different programs. That vim is called vi on some platforms is irrelevant.

> It is already bad enough that Solaris comes with an ancient, BSD-style
> vi that doesn't recognise the cursor keys in input mode...

Why, exactly, is this bad? And to be sure, I know of only one vi, the old
BSD-style one. Others are clones under different names. This is similar
to complaining that cc under Solaris does not do exactly the same as cc
under Linux.

 

[Villy Kruse]

fangorn:~/tmp 162> od -b foo
0000000 011 141 154 160 150 141 012
0000007

Where are the spaces I have input with my hand?

The behaviour is consistent between vim on Linux and vi on Solaris, BTW.

And anyone who don't like this behaviour could start using vim and set
the :expandtab option. For example by adding the folloing at the beginning
or the end of your C source file:

/* vim :set cindent shiftwidth=4 expandtab: */

If you don't like cindent just ommit it.

Villy

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:
[...]

It certainly is, when you expect *consistent* behaviour from vi on all
platforms. The *last* thing I want to do when using vi is remembering on
which platform I am and what is the right solution for my problem.

It is already bad enough that Solaris comes with an ancient, BSD-style
vi that doesn't recognise the cursor keys in input mode...

You might consider downloading one of the free vi clones (vim, nvi,
whatever) and building it on Solaris -- though that might not be
practical if you jump around to various machines.

I jump around hundreds of machines, as I'm working in a computer center,
hence my strong preference for building a consistent environment out of
the "standard" components available. I'm perfectly capable of using vi
without cursor keys at all (except for hjkl in command mode) and this is
what I do when having to do significant work on Solaris (regardless of
what system I happen to be at the moment).

At some point, I had to deal with 8 different Unix flavours and the
worst incompatibility for interactive sessions was the ps command
(ps aux vs ps -ef), so I've put it behind a wrapper script. A lot
of fun making software work everywhere, since this was in the days
before the great Unix unification (SUS1) and the original POSIX was
a big failure (it ignored far too many things, especially BSDisms).

Dan

 

[Dan Pop]

Nowhere. With your command you asked vi to recalculate the indentation.

I have merely asked everything to be moved 4 positions to the right.

How is vi to know how you want the reindentation to be done?

According to the sw setting.

Should it have added four spaces in front of each line?

For best results, in front of each non-white space character on each of
the lines affected by the shift command. No recalculation needed at all!
ONLY left shifts need recalculation, in the presence of tabs. And this
recalculation should never replace spaces by tabs.

if so, what about lines
with initial tabs, the tabs should be expanded to spaces?

According to the above, tabs become an issue only for left shifts.

Depending on the exact nature of the shift, one tab may have to be
converted to spaces and some of the spaces removed. Unless you know a
better way of implementing left shifts on lines starting with tabs.

Dan

 

[Dan Pop]

Wrong. You expect consistent behaviour from vi and vim, two completely
different programs. That vim is called vi on some platforms is irrelevant.

I don't expect it, I'm doing my best to configure vi in such a way that it
becomes consistent across platforms. I couldn't care less about the real
name of the program I get when I invoke vi (at some time in the past,
elvis and later nvi were the "vi" of the Linux distributions I was using).

Why, exactly, is this bad? And to be sure, I know of only one vi, the old
BSD-style one.

That's due to your ignorance. There are also SystemV vi, POSIX vi, SUSx
vi.

From the Solaris man page:

The standard Solaris version of vi will be replaced by the
POSIX.2-conforming version (see standards(5)) in the future.

Others are clones under different names.

OK, what are the "real" names of "the standard Solaris version of vi",
SystemV vi, POSIX vi and SUSx vi?

This is similar
to complaining that cc under Solaris does not do exactly the same as cc
under Linux.

It is similar to complaining that a system supposend to follow a standard
doesn't follow it completely. See the above quote from the vi man page
on Solaris.

Dan

 

[Keith Thompson]

Um, guys, there is a comp.editors newsgroup. I suspect everyone here
either knows how vi handles tabs, or doesn't care.

 

[Dan Pop]

Um, guys, there is a comp.editors newsgroup. I suspect everyone here
either knows how vi handles tabs, or doesn't care.

In which case, they killfiled this thread, already tagged as off topic,
long ago.

Dan

 

[Dik T. Winter]

>
> I don't expect it, I'm doing my best to configure vi in such a way that it
> becomes consistent across platforms. I couldn't care less about the real
> name of the program I get when I invoke vi (at some time in the past,
> elvis and later nvi were the "vi" of the Linux distributions I was using).

In that case you should coplain that something that is not 'vi' is called
'vi' on some platform. Not complain that the real 'vi' does not conform
to the behaviour of what is called 'vi' on some platform.

I once used a program called 'ed' that in the case of an error did not
just print a question mark, but printed a long line explaining the error.
But I did *not* complain that there was no portable way to avoid that
behaviour... (The worst thing was that it was coming through a 1200 baud
link to Argonne in Chicago.)

>
> That's due to your ignorance. There are also SystemV vi, POSIX vi, SUSx
> vi.

Probably. The first System V box I met in, say, 1985. By that time I had
already used BSD for some 6 years. The BSD subset I was comfortable with,
so when I first saw a System V vi, I did not feel the urge to find what it
could do more than BSD vi.

> From the Solaris man page:
>
> The standard Solaris version of vi will be replaced by the
> POSIX.2-conforming version (see standards(5)) in the future.

Yup, and if you had looked further you would have known that
/usr/xpg4/bin/vi is that POSIX.2-conforming version (I think).
This portion of the man page only says that /usr/bin/vi will be
replaced by /usr/xpg4/bin/vi.

>
> OK, what are the "real" names of "the standard Solaris version of vi",
> SystemV vi, POSIX vi and SUSx vi?

Those are not clones. But 'vim' very definitely *is* a clone, and
originally not very conforming to 'vi' behaviour either.

>
> It is similar to complaining that a system supposend to follow a standard
> doesn't follow it completely. See the above quote from the vi man page
> on Solaris.

I do not know. Is "set expandtabs" in Posix.2 vi? What has Posix.2 to
say about shifting lines? So I do not know in what way 'vi' does not
follow standards. The 'vi' in /usr/xpg4/bin on Solaris (which is
ostensibly Posix.2 complliant) acts the same way.

That Bill Joy decided that a shift would mean recalculation of the total
indent is perhaps unfortunate, but understandable for that time (1978).
Moreover, at that time adding four spaces at the end of white space
already containing four spaces and not replacing things by a HT would
indeed mean a waste of resources. (Note that it adds nothing to an
empty line either...) On the other hand, which way you do it in a
number of cases you have to replace white-space characters in the
original by other white-space characters anyway.

 

[Richard Tobin]

That Bill Joy decided that a shift would mean recalculation of the total
indent is perhaps unfortunate, but understandable for that time (1978).

26 years, and we're still waiting for vii.

-- Richard

 

[Dr Chaos]

...don't you think these two statements are contradictory?

No.

The question is why are OTHER languages still designed and promoted
with C's syntax?

If it had been a Bell Labs research project to make ergonomic language
syntax suitable for broad use they would have done actual empirical research
with subjects who were not only other Bell Labs researchers.

In some small ways actual empirical testing have been done a few
times, but the results are generally ignored by commercial firms.
That's what I mean by "profound anti-intellectualism", and the
"cargo-cult" imitation is the Microsoft (and Sun) manager arguing that
"it has to look like C to be successful", because C was successful.

In particular, the Fortran 90/Ada syntax for 'if then else' was preferred
over C or Pascal.

if something then
x1
x2
else
y1
y2
endif

 

[Dan Pop]

The question is why are OTHER languages still designed and promoted
with C's syntax?

And the answer is obvious: because C syntax proved to be far more popular
than the syntax of any other HLL.

If it had been a Bell Labs research project to make ergonomic language
syntax suitable for broad use they would have done actual empirical research
with subjects who were not only other Bell Labs researchers.

The point is that C was designed with a concrete application in mind,
by the same programmers who used it to implement that application.
And its design was influenced by another language, designed for the same
purpose, by the same people, but for a different class of computers.

So, the language designers were not at their first attempt and had
excellent user feedback ;-) I doubt that an "ergonomical" language
designed by a committee, based on world-wide empirical research, would
have been more popular among programmers.

Dan

 

[Dr Chaos]

And the answer is obvious: because C syntax proved to be far more popular
than the syntax of any other HLL.

but why?

is ther eanything good about the syntax other than that it was popular?

The point is that C was designed with a concrete application in mind,
by the same programmers who used it to implement that application.
And its design was influenced by another language, designed for the same
purpose, by the same people, but for a different class of computers.

So, the language designers were not at their first attempt and had
excellent user feedback ;-) I doubt that an "ergonomical" language
designed by a committee, based on world-wide empirical research, would
have been more popular among programmers.

I think the popularity is because of the things which come attached
to the language, namely access to operating system features.

If the language syntax had been better cognitively, people would be
making fewer mistakes with the popular language.

 

[Mabden]

If the language syntax had been better cognitively, people would be
making fewer mistakes with the popular language.

;-) good one!

 

[Dan Pop]

but why?

is ther eanything good about the syntax other than that it was popular?

If it was bad, why did it become popular in the first place?

I think the popularity is because of the things which come attached
to the language, namely access to operating system features.

Plenty of other languages predating C provided access to operating
system primitives. The need to access them without resorting to
assembly programming became clear far before Ken Thompson decided to
design and implement an OS for that unused PDP-7 sitting in a corner.

Even the idea of writing an OS in a HLL predates both Unix and C.

If the language syntax had been better cognitively, people would be
making fewer mistakes with the popular language.

The syntax-related mistakes are relatively few, once people learn the
language, and the compiler must diagnose all of them. The real problem
is caused by the semantic mistakes and they have nothing to do with the
language syntax.

Dan

 

[Old Wolf]

If the language syntax had been better cognitively, people would be
making fewer mistakes with the popular language.

I find the language syntax good cognitively (with a few rare exceptions,
such as pointer to array of functions returning pointer to array of
function pointers, etc.)

If you don't, then maybe you are influenced by other languages with
similar syntax and have trouble keeping them separate in your head?
The only significant language I learned before C was line-number BASIC.
C's syntax is far superior for anything but the most basic (no pun
intended) expressions.