C Syntax

[Rob Thorpe]

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.

 

[I. Appel]

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.

 

[CBFalconer]

[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.

 

[Harti Brandt]

On Fri, 4 Jun 2004, CBFalconer wrote:

C>Dan Pop wrote:
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

 

[Dik T. Winter]

> >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.

 

[Dan Pop]

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]

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

 

[Preben Traerup]

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

 

[Dik T. Winter]

> > > >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.)

 

[Dan Pop]

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

 

[Keith Thompson]

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.

Solaris vi (":version" prints "Version SVR4.0, Solaris 2.5.0") allows
"set ts=0", but it silently sets tabstop to 8.

vi (at least in the versions I've used) doesn't convert space
characters to tabs, but it does use tabs whenever possible for
indentation. With the default setting of "ts=8", spaces inserted by
hitting the space bar in insert mode remain as space characters, but
any leading whitespace created by control-T or adjusted by the '[' and
']' commands is converted to tabs. A 12-space indentation, for
example, becomes a tab followed by 4 spaces.

Once upon a time I actually liked this behavior. I found that I could
convert leading indentation to tabs by shifting the entire buffer to
the right and then back to the left. Now that I prefer to use just
spaces, I filter the buffer through the Unix "expand" command. (vim
might handle this better but I like nvi.)

 

[Dik T. Winter]

>
> 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.

You still do not get it. First you said that 'vi' does it (without
qualification), next you say that it is actually 'vim' (again without
qualification), now it appears that it is some obscure version of 'vim',
modified from the original by someone to get the effect you described.
But you expect a general solution:while the problem only exists in some obscure version. If somebody
gives you a piece of software that he has broken in some way, you should
not expect a 'portable' solution to unbreak it. You will not find a
portable solution because the bug is in general not present.

 

[Dik T. Winter]

> > 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.

....
> vi (at least in the versions I've used) doesn't convert space
> characters to tabs, but it does use tabs whenever possible for
> indentation. With the default setting of "ts=8", spaces inserted by
> hitting the space bar in insert mode remain as space characters, but
> any leading whitespace created by control-T or adjusted by the '[' and
> ']' commands is converted to tabs. A 12-space indentation, for
> example, becomes a tab followed by 4 spaces.

Yup, it is done when using auto-indent (which I never use), both with vi
and vim. In that case setting ts to some huge value will disable it and
use spaces only (but actual tabs in the file will look, eh, ugly). And,
indeed, there is no option when using auto-indent to disallow spaces
while ts has a sensible value.

 

[Dan Pop]

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.

...
vi (at least in the versions I've used) doesn't convert space
characters to tabs, but it does use tabs whenever possible for
indentation. With the default setting of "ts=8", spaces inserted by
hitting the space bar in insert mode remain as space characters, but
any leading whitespace created by control-T or adjusted by the '[' and
']' commands is converted to tabs. A 12-space indentation, for
example, becomes a tab followed by 4 spaces.

Yup, it is done when using auto-indent (which I never use), both with vi
and vim. In that case setting ts to some huge value will disable it and
use spaces only (but actual tabs in the file will look, eh, ugly). And,
indeed, there is no option when using auto-indent to disallow spaces
while ts has a sensible value.

So, who was the one who wasn't getting it?

Dan

 

[Dik T. Winter]

> > > > 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. > >...
> > > vi (at least in the versions I've used) doesn't convert space
> > > characters to tabs, but it does use tabs whenever possible for
> > > indentation. With the default setting of "ts=8", spaces inserted by
> > > hitting the space bar in insert mode remain as space characters, but
> > > any leading whitespace created by control-T or adjusted by the '[' and
> > > ']' commands is converted to tabs. A 12-space indentation, for
> > > example, becomes a tab followed by 4 spaces.

> >
> >Yup, it is done when using auto-indent (which I never use), both with vi
> >and vim. In that case setting ts to some huge value will disable it and
> >use spaces only (but actual tabs in the file will look, eh, ugly). And,
> >indeed, there is no option when using auto-indent to disallow spaces
> >while ts has a sensible value.

>
> So, who was the one who wasn't getting it?

In that case there is a completely standard way to avoid it. Set
auto-indent off. But note that in this case vi is *not* converting
spaces to tabs. When due to an auto-indent it goes to a specific
places it does this with a mixture of tabs and spaces. So there is
no conversion at all. Got it? Note that even if auto-indent is on,
when you enter 12 spaces no conversion takes place... Your complaint
was:None of this happens, even when auto-indent is on.

 

[Dan Pop]

...
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.
...
vi (at least in the versions I've used) doesn't convert space
characters to tabs, but it does use tabs whenever possible for
indentation. With the default setting of "ts=8", spaces inserted by
hitting the space bar in insert mode remain as space characters, but
any leading whitespace created by control-T or adjusted by the '[' and
']' commands is converted to tabs. A 12-space indentation, for
example, becomes a tab followed by 4 spaces.

Yup, it is done when using auto-indent (which I never use), both with vi
and vim. In that case setting ts to some huge value will disable it and
use spaces only (but actual tabs in the file will look, eh, ugly). And,
indeed, there is no option when using auto-indent to disallow spaces
while ts has a sensible value.

So, who was the one who wasn't getting it?

In that case there is a completely standard way to avoid it. Set
auto-indent off. But note that in this case vi is *not* converting
spaces to tabs. When due to an auto-indent it goes to a specific
places it does this with a mixture of tabs and spaces. So there is
no conversion at all. Got it? Note that even if auto-indent is on,
when you enter 12 spaces no conversion takes place...

Still badly missing the point. I seldom use auto-indent, but I use
very often other indentation commands, like CTRL-T and shifts, whose
operation is controlled by the setting of sw and, therefore, has nothing
to do with ts. Yet, vi is using the ts setting to convert the spaces
generated by these commands into HTs. Hence my solution to set ts to a
ludicrously large value in my .exrc. There is nothing preventing me
from resetting it to 8 (which I can achieve with a single key press)
when I detect HTs in other people's texts (they're glaringly obvious
when ts is set to 100 ;-)

Dan

 

[Dik T. Winter]

>
> Still badly missing the point. I seldom use auto-indent, but I use
> very often other indentation commands, like CTRL-T and shifts, whose
> operation is controlled by the setting of sw and, therefore, has nothing
> to do with ts. Yet, vi is using the ts setting to convert the spaces
> generated by these commands into HTs.

You are still missing the point. These commands do not generate spaces,
so there is no conversion.

 

[J. J. Farrell]

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.

VIM has various extensions in this area that make it very
flexible and remove these issues. It can be easily set up
so that the tab key works as it would in traditional VI,
but spaces are used instead of tabs to do the indentation.
It can also easily convert tab characters in a file to an
appropriate number of spaces based on a configurable hard
tab width.

If you want a VI-like editor, I recommend VIM highly.

 

[Dan Pop]

You are still missing the point. These commands do not generate spaces,
so there is no conversion.

Bullshit. 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:

fangorn:~/tmp 158> od -b foo
0000000 040 040 040 040 141 154 160 150 141 012
0000012

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?

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

Dan

 

[Sam Dennis]

[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.