Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63468 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2015-06-17 16:27 -0700 |
| Last post | 2015-06-18 18:27 +0100 |
| Articles | 20 on this page of 98 — 27 participants |
Back to article view | Back to comp.lang.c
Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 16:27 -0700
Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 00:35 +0100
Re: Merging .h and .c source files Reinhardt Behm <rbehm@hushmail.com> - 2015-06-18 12:51 +0800
Re: Merging .h and .c source files Michael Sorn <invalid@example.com> - 2015-06-18 13:27 +0000
Re: Merging .h and .c source files David Brown <david.brown@hesbynett.no> - 2015-06-18 15:38 +0200
Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-18 13:42 +0000
Re: Merging .h and .c source files Reinhardt Behm <rbehm@hushmail.com> - 2015-06-18 22:47 +0800
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 06:21 -0700
Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 16:07 +0200
Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 15:29 +0100
Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 16:48 +0200
Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-06-18 21:52 +0000
Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 03:57 +0200
Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-06-19 10:02 +0000
Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 11:24 +0100
Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 12:10 +0100
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 13:24 +0100
Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 14:09 +0100
Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 15:30 +0200
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 17:34 +0100
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 17:06 +0100
Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 09:40 -0700
Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 18:12 +0100
Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-19 11:25 -0700
Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-20 07:31 -0700
Re: Merging .h and .c source files glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-20 17:07 +0000
Re: Merging .h and .c source files "Charles Richmond" <numerist@aquaporin4.com> - 2015-06-23 17:44 -0500
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 01:48 +0100
Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-20 12:37 -0700
Re: Merging .h and .c source files Robert Wessel <robertwessel2@yahoo.com> - 2015-06-19 22:04 -0500
Re: Merging .h and .c source files Les Cargill <lcargill99@comcast.com> - 2015-06-19 22:36 -0500
Re: Merging .h and .c source files Robert Wessel <robertwessel2@yahoo.com> - 2015-06-20 01:23 -0500
Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 17:54 +0100
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 19:45 +0100
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 07:19 -0700
Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-06-20 08:52 +1200
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:44 -0700
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 08:26 -0700
Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 16:41 +0100
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 17:13 +0100
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 09:26 -0700
Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 18:03 +0100
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:33 -0700
Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-18 10:28 -0700
Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-18 17:28 +0000
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 21:07 +0100
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 15:04 -0700
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 00:38 +0100
Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 01:00 +0100
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-19 00:10 -0700
Re: Merging .h and .c source files mark.bluemel@gmail.com - 2015-06-19 00:56 -0700
Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 09:18 +0100
Re: Merging .h and .c source files John Bode <jfbode1029@gmail.com> - 2015-06-24 08:43 -0700
Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-24 11:15 -0700
Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 19:23 +0100
Re: Merging .h and .c source files James Kuyper <jameskuyper@verizon.net> - 2015-06-24 14:40 -0400
Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 19:45 +0100
Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-18 10:19 -0700
Re: Merging .h and .c source files gwowen <gwowen@gmail.com> - 2015-06-19 05:29 -0700
Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-19 08:26 -0700
Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 04:08 +0200
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:53 -0700
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 18:40 -0700
Re: Merging .h and .c source files Udyant Wig <udyantw@gmail.com> - 2015-07-11 10:19 +0530
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:59 -0700
Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-13 18:50 +0000
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:37 -0700
Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:30 +0000
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:46 -0700
Re: Merging .h and .c source files Richard Damon <Richard@Damon-Family.org> - 2015-07-11 20:08 -0400
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 18:26 -0700
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:38 -0700
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:57 -0700
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:30 -0700
Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-12 15:51 +1200
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 06:03 -0700
Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 21:36 +0100
Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-12 21:27 +0000
Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-13 10:00 +1200
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-13 04:16 -0700
Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-07-13 12:47 +0100
Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-14 08:32 +1200
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 11:33 -0700
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 11:24 -0700
Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 12:29 -0700
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:50 -0700
Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-13 18:52 +0000
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:52 -0700
Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:33 -0700
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:53 -0700
Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:47 -0700
Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:18 -0700
Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:34 -0700
Re: Merging .h and .c source files Morris Dovey <mrdovey@iedu.com> - 2015-06-18 15:59 -0500
Re: Merging .h and .c source files Philipp Klaus Krause <pkk@spth.de> - 2015-06-19 12:46 +0200
Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-18 19:23 +0100
Re: Merging .h and .c source files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-18 07:48 -0600
Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-18 18:27 +0100
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-19 17:06 +0100 |
| Message-ID | <87wpyzof7i.fsf@bsb.me.uk> |
| In reply to | #63596 |
Bartc <bc@freeuk.com> writes: > On 19/06/2015 13:24, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: >> <snip> >>> Most other editors I've tried fail the Bart Test: in the middle of a >>> line, press and hold Backspace. Instead of stopping at the beginning >>> of the current line, invariably they will carry and and delete much of >>> the previous one or two lines as well before you've noticed! >> >> Rather than duplicate so much effort by writing your own, you could use >> a programmable editor: >> >> (global-set-key [backspace] >> (lambda () >> (interactive) >> (unless (looking-at "^") (backward-delete-char 1)))) >> >> The result is you can build up the configuration for a single tool that >> fits all your peculiarities like a glove. > > Which is not that much different from 'writing your own'! Except you > now have to learn a new language and a new set of APIs. Well, that comment tells me you are not being serious! <snip> > Anyway, my point is it can be easier to write your own editor to do > exactly what you want, rather than try and customise someone else's. Yes, that it *can* be is trivially true (it depends on what you want and how hard the chosen editor is to program), but I'd say it's not true in general. You get vastly more from building on the work of others. I often find use-contributed configurations that do what I want (or close enough that it's easy to alter). It's clear you take a different approach. You write your own editors to develop your own compilers for your own languages to write... I don't know... your own editors and compilers? At any rate, your ideal seems to be to live in a hermetic world of your own software. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-19 09:40 -0700 |
| Message-ID | <83aa6187-775d-4e41-a6b2-4c30ffef7054@googlegroups.com> |
| In reply to | #63615 |
On Friday, June 19, 2015 at 9:06:33 AM UTC-7, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
> > On 19/06/2015 13:24, Ben Bacarisse wrote:
> >> Bartc <bc@freeuk.com> writes:
> >> <snip>
> >>> Most other editors I've tried fail the Bart Test: in the middle of a
> >>> line, press and hold Backspace. Instead of stopping at the beginning
> >>> of the current line, invariably they will carry and and delete much of
> >>> the previous one or two lines as well before you've noticed!
> >>
> >> Rather than duplicate so much effort by writing your own, you could use
> >> a programmable editor:
> >>
> >> (global-set-key [backspace]
> >> (lambda ()
> >> (interactive)
> >> (unless (looking-at "^") (backward-delete-char 1))))
> >>
> >> The result is you can build up the configuration for a single tool that
> >> fits all your peculiarities like a glove.
> >
> > Which is not that much different from 'writing your own'! Except you
> > now have to learn a new language and a new set of APIs.
>
> Well, that comment tells me you are not being serious!
>
> <snip>
> > Anyway, my point is it can be easier to write your own editor to do
> > exactly what you want, rather than try and customise someone else's.
>
> Yes, that it *can* be is trivially true (it depends on what you want and
> how hard the chosen editor is to program), but I'd say it's not true in
> general. You get vastly more from building on the work of others. I
> often find use-contributed configurations that do what I want (or close
> enough that it's easy to alter).
>
> It's clear you take a different approach. You write your own editors to
> develop your own compilers for your own languages to write... I don't
> know... your own editors and compilers? At any rate, your ideal seems
> to be to live in a hermetic world of your own software.
Depends on where you are going. In spite of all the loose talk about
portability relatively little (measured by lines of code) software is
actually ever re-used anywhere. The existence of some famous examples
proves nothing. I have no idea where Bart is going but it does seem to
satisfy him.
Myself I code with the distant future in mind. I am aiming at a day when
reading and understanding code is more important than writing it. I am
not writing production code. The code I write is feasibility proofs -
not something that is intented for serious use.
Other people will have other goals in mind. Being monomaniacial about
what is good and what is bad gets us nowhere.
PS: I do not think color coding helps and I always turn it off.
PPS: Bart is right about one thing people have sort of forgotten. C is
originally line-oriented. This still shows in the pre-processor. Perhaps
giving up line-orientation was a good idea back in the days when a screen
had scarce character space. But now that is not necessary.
I have gone back to a version of line-orientation (although I have not
written any tools recognizing that). That is why I prefer Python-type
brackets
while (x < 42) {
a[x] = b[x];}
One statement per line and vice versa. Bare braces are not statements.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-19 18:12 +0100 |
| Message-ID | <mm1iei$v1p$1@dont-email.me> |
| In reply to | #63622 |
On 19/06/2015 17:40, David Kleinecke wrote: > On Friday, June 19, 2015 at 9:06:33 AM UTC-7, Ben Bacarisse wrote: > PPS: Bart is right about one thing people have sort of forgotten. C is > originally line-oriented. This still shows in the pre-processor. Perhaps > giving up line-orientation was a good idea back in the days when a screen > had scarce character space. But now that is not necessary. I don't know if C was line-oriented or not, but it doesn't matter. What matters is that most language source code is formatted line by line, whether the language syntax insists on it or not. So that if you are editing a line, that will usually be a specific statement. You don't usually want editing ops within that line to interfere with nearby lines, not with character-at-a-time operations such as Cursor-Left or Delete-Char-Right anyway. They should be constrained within the line. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-19 11:25 -0700 |
| Message-ID | <ln4mm3imic.fsf@nuthaus.mib.org> |
| In reply to | #63622 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> PPS: Bart is right about one thing people have sort of forgotten. C is
> originally line-oriented. This still shows in the pre-processor. Perhaps
> giving up line-orientation was a good idea back in the days when a screen
> had scarce character space. But now that is not necessary.
>
> I have gone back to a version of line-orientation (although I have not
> written any tools recognizing that). That is why I prefer Python-type
> brackets
> while (x < 42) {
> a[x] = b[x];}
> One statement per line and vice versa. Bare braces are not statements.
I don't believe that's true. As far as I know, C has always permitted
tokens to be arranged across lines in any manner the author chooses.
The preprocessor adds a line-oriented layer on top of C's token-oriented
grammar. There have always been conventions for how to format code for
readability, but I'm not aware that any C compiler has ever cared which
conventions, if any, you follow.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-20 07:31 -0700 |
| Message-ID | <b6661a71-0d41-48ea-8916-e09cdd851dcc@googlegroups.com> |
| In reply to | #63634 |
On Friday, June 19, 2015 at 11:25:22 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > PPS: Bart is right about one thing people have sort of forgotten. C is
> > originally line-oriented. This still shows in the pre-processor. Perhaps
> > giving up line-orientation was a good idea back in the days when a screen
> > had scarce character space. But now that is not necessary.
> >
> > I have gone back to a version of line-orientation (although I have not
> > written any tools recognizing that). That is why I prefer Python-type
> > brackets
> > while (x < 42) {
> > a[x] = b[x];}
> > One statement per line and vice versa. Bare braces are not statements.
>
> I don't believe that's true. As far as I know, C has always permitted
> tokens to be arranged across lines in any manner the author chooses.
> The preprocessor adds a line-oriented layer on top of C's token-oriented
> grammar. There have always been conventions for how to format code for
> readability, but I'm not aware that any C compiler has ever cared which
> conventions, if any, you follow.
Ritchie used to have his earliest surviving C compiler on his website
and I studied it. It was obviously not the first C compiler - only the
oldest one that survives. Ritchie himself seemed to be reluctant to
discuss how C came about. I have seen nothing about the pre-history of
the pre-processor but I think we all agree that it shows definite signs
of line-orientation. The question hinges on what long-lost software
looked like. My guess is more like the pre-processor.
This question cannot be settled - but it is no matter except in the
context of the pre-processor. C, as it stands today, is receptive to a
line-oriented presentation and that is what matters.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-20 17:07 +0000 |
| Message-ID | <mm46lc$28s$1@speranza.aioe.org> |
| In reply to | #63684 |
David Kleinecke <dkleinecke@gmail.com> wrote: > On Friday, June 19, 2015 at 11:25:22 AM UTC-7, Keith Thompson wrote: (snip) >> I don't believe that's true. As far as I know, C has always permitted >> tokens to be arranged across lines in any manner the author chooses. >> The preprocessor adds a line-oriented layer on top of C's token-oriented >> grammar. There have always been conventions for how to format code for >> readability, but I'm not aware that any C compiler has ever cared which >> conventions, if any, you follow. Seems like at least some parts of C have roots in PL/I, the comment convention for one. Unlike some other languages of the time, PL/I is not line oriented, and neither is its preprocessor. It is interesting that the C preprocessor is line oriented. The PL/I preprocessor language is very similar to PL/I itself, including %DO loops and %PROCEDURE calls. > Ritchie used to have his earliest surviving C compiler on his website > and I studied it. It was obviously not the first C compiler - only the > oldest one that survives. Ritchie himself seemed to be reluctant to > discuss how C came about. I have seen nothing about the pre-history of > the pre-processor but I think we all agree that it shows definite signs > of line-orientation. The question hinges on what long-lost software > looked like. My guess is more like the pre-processor. Which computer was it meant to run on? > This question cannot be settled - but it is no matter except in the > context of the pre-processor. C, as it stands today, is receptive to a > line-oriented presentation and that is what matters. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-06-23 17:44 -0500 |
| Message-ID | <mmcndm$da9$1@dont-email.me> |
| In reply to | #63696 |
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:mm46lc$28s$1@speranza.aioe.org... > David Kleinecke <dkleinecke@gmail.com> wrote: >> On Friday, June 19, 2015 at 11:25:22 AM UTC-7, Keith Thompson wrote: > > (snip) >>> I don't believe that's true. As far as I know, C has always permitted >>> tokens to be arranged across lines in any manner the author chooses. >>> The preprocessor adds a line-oriented layer on top of C's token-oriented >>> grammar. There have always been conventions for how to format code for >>> readability, but I'm not aware that any C compiler has ever cared which >>> conventions, if any, you follow. > > Seems like at least some parts of C have roots in PL/I, the comment > convention for one. Unlike some other languages of the time, > PL/I is not line oriented, and neither is its preprocessor. > C also seems to get a few things from ALGOL 60, like the "for" statement and the "switch" statement. -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-24 01:48 +0100 |
| Message-ID | <87616ej5id.fsf@bsb.me.uk> |
| In reply to | #64007 |
"Charles Richmond" <numerist@aquaporin4.com> writes: <snip> > C also seems to get a few things from ALGOL 60, like the "for" > statement and the "switch" statement. C's "for" is very different from that in Algol 60, and Algol 60 didn't have a switch statement. It had "switch declarations" -- a peculiar notion, a bit like a computed go to, about which the less said the better! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-20 12:37 -0700 |
| Message-ID | <lnr3p6f9x6.fsf@nuthaus.mib.org> |
| In reply to | #63684 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, June 19, 2015 at 11:25:22 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > PPS: Bart is right about one thing people have sort of forgotten. C is
>> > originally line-oriented. This still shows in the pre-processor. Perhaps
>> > giving up line-orientation was a good idea back in the days when a screen
>> > had scarce character space. But now that is not necessary.
>> >
>> > I have gone back to a version of line-orientation (although I have not
>> > written any tools recognizing that). That is why I prefer Python-type
>> > brackets
>> > while (x < 42) {
>> > a[x] = b[x];}
>> > One statement per line and vice versa. Bare braces are not statements.
>>
>> I don't believe that's true. As far as I know, C has always permitted
>> tokens to be arranged across lines in any manner the author chooses.
>> The preprocessor adds a line-oriented layer on top of C's token-oriented
>> grammar. There have always been conventions for how to format code for
>> readability, but I'm not aware that any C compiler has ever cared which
>> conventions, if any, you follow.
>
> Ritchie used to have his earliest surviving C compiler on his website
> and I studied it. It was obviously not the first C compiler - only the
> oldest one that survives. Ritchie himself seemed to be reluctant to
> discuss how C came about. I have seen nothing about the pre-history of
> the pre-processor but I think we all agree that it shows definite signs
> of line-orientation. The question hinges on what long-lost software
> looked like. My guess is more like the pre-processor.
Your guess is mistaken.
You've studied an early C compiler. Is there anything in it, outside
the preprocessor, that suggests a line-oriented language?
Of course the preprocessor is line-oriented. Each preprocessor
directive is on a single line. The core language, outside the
preprocessor, is not, and it never has been.
> This question cannot be settled - but it is no matter except in the
> context of the pre-processor. C, as it stands today, is receptive to a
> line-oriented presentation and that is what matters.
The question can be settled. Documents describing early versions of C
and its ancestor languages (B, BCPL, and even CPL) still exist. Quoting
the B manual (C's immediate predecessor), dated 1972-01-07:
In general, B requires tokens to be separated by blanks, comments or
newlines, however the compiler infers separators surrounding any of
the characters (){}[],;?: or surrounding any maximal sequence of the
characters +-*/<>&|!.
Note that there's no distinction between blanks and newlines.
Quoting the C Reference Manual, dated 1974-01-15:
In general blanks, tabs, newlines, and comments are described below
are ignored except as they serve to separate tokens. At least one
of these characters is required to separate otherwise adjacent
identifiers, constants, and certain operator-pairs.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-19 22:04 -0500 |
| Message-ID | <6fl9oaht64slfrnigejs5th0dita9uhv6b@4ax.com> |
| In reply to | #63622 |
On Fri, 19 Jun 2015 09:40:55 -0700 (PDT), David Kleinecke <dkleinecke@gmail.com> wrote: >PPS: Bart is right about one thing people have sort of forgotten. C is >originally line-oriented. This still shows in the pre-processor. Perhaps >giving up line-orientation was a good idea back in the days when a screen >had scarce character space. But now that is not necessary. C was certainly not line oriented at first. Nor was B line oriented. BCPL was partially line oriented. The line oriented pre-processor was a fairly late addition to C.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-06-19 22:36 -0500 |
| Message-ID | <mm2n25$mj9$3@dont-email.me> |
| In reply to | #63653 |
Robert Wessel wrote: > On Fri, 19 Jun 2015 09:40:55 -0700 (PDT), David Kleinecke > <dkleinecke@gmail.com> wrote: > >> PPS: Bart is right about one thing people have sort of forgotten. C is >> originally line-oriented. This still shows in the pre-processor. Perhaps >> giving up line-orientation was a good idea back in the days when a screen >> had scarce character space. But now that is not necessary. > > > C was certainly not line oriented at first. Nor was B line oriented. > BCPL was partially line oriented. > > The line oriented pre-processor was a fairly late addition to C. > SFAIK, the relationship the preprocessor had with lines has been around longer than I've been programming 'C'. That dates from the mid '80s. How recent is "recent"? -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-20 01:23 -0500 |
| Message-ID | <q01aoa1q1ru6a9pi6el7222nc92g15586m@4ax.com> |
| In reply to | #63658 |
On Fri, 19 Jun 2015 22:36:47 -0500, Les Cargill <lcargill99@comcast.com> wrote: >Robert Wessel wrote: >> On Fri, 19 Jun 2015 09:40:55 -0700 (PDT), David Kleinecke >> <dkleinecke@gmail.com> wrote: >> >>> PPS: Bart is right about one thing people have sort of forgotten. C is >>> originally line-oriented. This still shows in the pre-processor. Perhaps >>> giving up line-orientation was a good idea back in the days when a screen >>> had scarce character space. But now that is not necessary. >> >> >> C was certainly not line oriented at first. Nor was B line oriented. >> BCPL was partially line oriented. >> >> The line oriented pre-processor was a fairly late addition to C. >> > > >SFAIK, the relationship the preprocessor had with lines has been around >longer than I've been programming 'C'. That dates from the mid '80s. > >How recent is "recent"? Pre-K&R1, a series of papers/specifications/versions of C were produced. K&R1 was essentially the "7th edition" with minor changes. A recognizably modern preprocessor was included in the "5th edition", although a few basics existed earlier (a straight #include was in the 2nd edition, IIRC). You can find quotes from DMR to roughly that effect. They were also familiar with other languages (like PL/I) which had a preprocessor.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-19 17:54 +0100 |
| Message-ID | <mm1hda$qk6$1@dont-email.me> |
| In reply to | #63615 |
On 19/06/2015 17:06, Ben Bacarisse wrote: > Bartc <bc@freeuk.com> writes: >>> Rather than duplicate so much effort by writing your own, you could use >>> a programmable editor: >>> >>> (global-set-key [backspace] >>> (lambda () >>> (interactive) >>> (unless (looking-at "^") (backward-delete-char 1)))) >>> >>> The result is you can build up the configuration for a single tool that >>> fits all your peculiarities like a glove. >> >> Which is not that much different from 'writing your own'! Except you >> now have to learn a new language and a new set of APIs. > > Well, that comment tells me you are not being serious! What's not serious about it? If you have to tell a computer how to behave (and do it by writing lines of code) then that's programming. Maybe it saves you writing the bulk of a big application with graphics and a user interface and the rest, but I got the idea that a modern IDE would do a lot of that for you. > develop your own compilers for your own languages to write... I don't > know... your own editors and compilers? At any rate, your ideal seems > to be to live in a hermetic world of your own software. Yes, that would be perfect! (Just this morning I was wondering how to get rid of an annoying dependency on Nasm and gcc's 64-bit linker. However I can't get rid of Windows so easily...) Actually that all started out of necessity, and I never grew out of that. Working in isolation didn't help either. But I have sold $millions' worth of applications along the way, and all my own work, so it wasn't all pointless. I do believe that applications can be kept small and simple and still do very useful work. Actually, I *know* they can, because I've done it. Yesterday I was looking at 'Smaller C', an 11,000 line C compiler. It was a more much pleasant experience than looking at 11,000 *files* or however many there are of gcc source code and wondering where the hell you start. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-19 19:45 +0100 |
| Message-ID | <87a8vvo7uu.fsf@bsb.me.uk> |
| In reply to | #63625 |
Bartc <bc@freeuk.com> writes: > On 19/06/2015 17:06, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: > >>>> Rather than duplicate so much effort by writing your own, you could use >>>> a programmable editor: >>>> >>>> (global-set-key [backspace] >>>> (lambda () >>>> (interactive) >>>> (unless (looking-at "^") (backward-delete-char 1)))) >>>> >>>> The result is you can build up the configuration for a single tool that >>>> fits all your peculiarities like a glove. >>> >>> Which is not that much different from 'writing your own'! Except you >>> now have to learn a new language and a new set of APIs. >> >> Well, that comment tells me you are not being serious! > > What's not serious about it? If you have to tell a computer how to > behave (and do it by writing lines of code) then that's programming. Originally, because I took the plain meanng of your words, but now I have another reason: such words games should not be part of a serious discussion. You may claim, now, that you meant nothing but "its the same kind of a activity" but that's not what "not much different from" means in an honest exchange of ideas. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-21 07:19 -0700 |
| Message-ID | <3cb2df3d-079d-4ed1-af7d-0e9ba5c7eb80@googlegroups.com> |
| In reply to | #63615 |
On Friday, June 19, 2015 at 5:06:33 PM UTC+1, Ben Bacarisse wrote: > > Yes, that it *can* be is trivially true (it depends on what you want and > how hard the chosen editor is to program), but I'd say it's not true in > general. You get vastly more from building on the work of others. I > often find use-contributed configurations that do what I want (or close > enough that it's easy to alter). > It's always tempting to redo things. Other people often do things in a way that is not as good as you could do for yourself. Then, with programming in particular, integrating a library and learning an API is non-trivial. But generally it's something you should resist. Every man and his dog can write a better string library for C, for example. But unless your problem is string processing itself, you're far better off just using the C standard library. Focus efforts on providing functionality no-one has done before.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-20 08:52 +1200 |
| Message-ID | <cujdnvF43fuU1@mid.individual.net> |
| In reply to | #63585 |
Richard Heathfield wrote: > > Multi-Edit was very good. So was Brief. But I haven't seen hide nor hair > of them for a number of years, or should I say decades? I liked MSVC6's > Intellisense - that was very good indeed. Do MS still do Intellisense? Brief was my favourite editor back in the days of DOS. It was the first editor that allowed selection of rectangular blocks of text, handy for indenting blocks of code (before editor learned how to auto-indent). MS still do Intellisense. One of my current clients uses Visual Studio as their development environment and it isn't too bad. It does assume that you work in a particular way, which can be a pain if you don't. These days I put more weight on editor features like configurable automatic formatting (really important in a team environment for producing consistency in code) and version control integration. Being able to see what has changed since the last commit, or view a diff between versions (both local saves and commits) is really useful. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 18:44 -0700 |
| Message-ID | <kfnio9r31t4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #63585 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 19/06/15 11:02, Richard Bos wrote: >> "Morten W. Petersen" <morphex@gmail.com> wrote: >>> On 18.06.2015 23:52, Richard Bos wrote: >>>> "Morten W. Petersen" <morphex@gmail.com> wrote: >>>> >>>>> Yeah yeah. Then you also have vi and nano, etc etc. >>>> >>>> Yes, and some of us even use actual, functioning _editors_... >>> >>> Yes, and..? >> >> We find these a useful alternative to the abovementioned monstrosities. > > De gustibus non est disputandum. Out of all of the editors I've used: > XEDIT, edlin, edit, Multi-Edit, Brief, a wide variety of > built-into-IDE editors, Notepad, Notepad++, pico, nano, emacs, and of > course we must never forget the classic > too-numerous-to-be-mentioned-here... I have found *none* of them to be > as usable, powerful, and flexible as [g]vim. What makes a program usable is largely a subjective question. The matters of power and flexibility, however, are more objectively quantifiable. I doubt very much that vim, or gvim, could be viewed objectively as more powerful or more flexible than emacs; actually it seems likely to be the other way around. Do you have any kind of response to this, other than a subjective opinion?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-18 08:26 -0700 |
| Message-ID | <794fa229-8391-482a-a94d-4ccbade952ef@googlegroups.com> |
| In reply to | #63515 |
On Thursday, June 18, 2015 at 3:29:55 PM UTC+1, Richard Heathfield wrote: > > A few years ago, someone told this group about a company that was > distributing a "vim reference t-shirt" with lots of handy commands > printed *upside-down* on the front of the shirt (pull the shirt out and > forward a bit, and then look down to look up). Ben Pfaff responded by > asking whether they also did a reference tent, for emacs users. > I always run emacs. I hate being chucked into vim or vi, though it happens occasionally. I like to press the arrow keys and see the cursor move, and type text and have the system echo my keystrokes to the screen. You also need a fast scroll of some sort (even if it's only auto repeated page up / page down), and some block cut / copy / paste, connected to the clipboard. emacs is pretty good, although even it is capable of typing what it thinks you should type rather than the buttons you actually press.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-18 16:41 +0100 |
| Message-ID | <mluoom$b29$1@dont-email.me> |
| In reply to | #63525 |
On 18/06/15 16:26, Malcolm McLean wrote: > On Thursday, June 18, 2015 at 3:29:55 PM UTC+1, Richard Heathfield wrote: >> >> A few years ago, someone told this group about a company that was >> distributing a "vim reference t-shirt" with lots of handy commands >> printed *upside-down* on the front of the shirt (pull the shirt out and >> forward a bit, and then look down to look up). Ben Pfaff responded by >> asking whether they also did a reference tent, for emacs users. >> > I always run emacs. I hate being chucked into vim or vi, though it happens > occasionally. I can understand that, although of course my view is diametrically opposite to yours. > I like to press the arrow keys and see the cursor move, gvim > and type text and have > the system echo my keystrokes to the screen. gvim > You also need a fast scroll > of some sort (even if it's only auto repeated page up / page down), and gvim > some block cut / copy / paste, connected to the clipboard. gvim > emacs is pretty good, although even it is capable of typing what it thinks > you should type rather than the buttons you actually press. Well, for me that's a deal-breaker. I'm sick and tired of Web search engines that assume I can't spell or type, and which consequently show me 437,000,000 hits I don't want, but none of the hits I actually do want. Someone needs to develop a WYTIWYG search engine. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-18 17:13 +0100 |
| Message-ID | <87y4jhouyp.fsf@bsb.me.uk> |
| In reply to | #63526 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 18/06/15 16:26, Malcolm McLean wrote: >> On Thursday, June 18, 2015 at 3:29:55 PM UTC+1, Richard Heathfield wrote: >>> >>> A few years ago, someone told this group about a company that was >>> distributing a "vim reference t-shirt" with lots of handy commands >>> printed *upside-down* on the front of the shirt (pull the shirt out and >>> forward a bit, and then look down to look up). Ben Pfaff responded by >>> asking whether they also did a reference tent, for emacs users. >>> >> I always run emacs. I hate being chucked into vim or vi, though it happens >> occasionally. > > I can understand that, although of course my view is diametrically > opposite to yours. > >> I like to press the arrow keys and see the cursor move, > > gvim I seem to remember there was time when the arrow keys worked (on almost all terminals) with vi, let alone vim (or any of the newer variants). Did they ever stop working, or is my memory rosy? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web