Discussion:
Upper/lower case in identifiers
(too old to reply)
Tom Schneider
2004-09-10 22:42:00 UTC
Permalink
program capbug(output);

(* capbug: capitalization bug in gpc compiler

Dr. Thomas D. Schneider
National Cancer Institute
Laboratory of Experimental and Computational Biology
Molecular Information Theory Group
Frederick, Maryland 21702-1201
toms at ncifcrf.gov
permanent email: toms at alum.mit.edu (use only if first address fails)
http://www.lecb.ncifcrf.gov/~toms/

*)

const
(* begin module version *)
version = 1.00; (* of capbug.p 2004 Sep 10
2004 Sep 10, 1.00: origin
*)
(* end module version *)

(* begin module describe.capbug *)
(*
name
capbug: capitalization bug in gpc compiler

synopsis
capbug(output: out)

files

output: messages to the user

description

Demonstrate capitals bug in GPC. The name of a local procedure is
objected to by GPC if there is a global by the same name but
different capitalization.

In theory the compiler should keep track of what is local and what
is global anyway, so it should be able to avoid this.

It is a problem because if one imports procedures from another
program, they are not being treated as pure 'black boxes'.
Instead, local variable names are being compared to the global
variable names.

In otherwords, the scope rule of Pascal is being violated
when these warnings are generated.

This problem is not fixed by adding the flag:

-Widentifier-case-local
Warn about an identifier written with varying case within one
program/module/unit.

examples

gpc 20040516, based on gcc-3.3.3

for this program itself gives:

capbug.p:113: warning: capitalisation of `x' doesn't match
capbug.p:111: warning: previous capitalisation `X'
capbug.p:113: warning: capitalisation of `y' doesn't match
capbug.p:111: warning: previous capitalisation `Y'
capbug.p: In procedure `themain':
capbug.p:138: warning: capitalisation of `X' doesn't match
capbug.p:113: warning: previous capitalisation `x'
capbug.p:139: warning: capitalisation of `Y' doesn't match
capbug.p:113: warning: previous capitalisation `y'

The result is:

capbug 1.00
outside: x = 1
outside: y = 2
inside: x = 3
inside: y = 4
themain: X = 5
themain: Y = 6

which demonstrates that the scope rules are being followed when the
progrm runs, because X and Y are set before the calls to routines
outside and inside, but they are not affected by those calls. That
is, the outside and inside routines have local variables.

documentation

see also

{Manual on GPC that gives the -Widentifier-case-local flag:}
http://www.gnu-pascal.de/gpc/GPC-Command-Line-Options.html

{Discussion on the topic, "Upper/lower case in identifiers":}
http://www.gnu-pascal.de/crystal/gpc/en/raw-mail7665.html

author

Thomas Dana Schneider

bugs

technical notes

*)
(* end module describe.capbug *)

var
X, Y: integer; (* global X and Y *)

procedure outside(x, y: integer);
(* an outside procedure *)
begin
x := 1;
y := 2;
writeln(output,'outside: x = ',x:1);
writeln(output,'outside: y = ',y:1);
end;

(* begin module capbug.themain *)
procedure themain;
(* the main procedure of the program *)

procedure inside(x, y: integer);
(* an inside procedure *)
begin
x := 3;
y := 4;
writeln(output,'inside: x = ',x:1);
writeln(output,'inside: y = ',y:1);
end;

begin
writeln(output,'capbug ',version:4:2);

X := 5;
Y := 6;
outside(X, Y);
inside(X, Y);
writeln(output,'themain: X = ',X:1);
writeln(output,'themain: Y = ',Y:1);

end;
(* end module capbug.themain *)

begin
themain;
end.
Waldek Hebisch
2004-09-11 00:51:31 UTC
Permalink
Dr. Thomas D. Schneider wrote:
>
> Demonstrate capitals bug in GPC. The name of a local procedure is
> objected to by GPC if there is a global by the same name but
> different capitalization.
>
> In theory the compiler should keep track of what is local and what
> is global anyway, so it should be able to avoid this.
>
> It is a problem because if one imports procedures from another
> program, they are not being treated as pure 'black boxes'.
> Instead, local variable names are being compared to the global
> variable names.
>
> In otherwords, the scope rule of Pascal is being violated
> when these warnings are generated.
>
> This problem is not fixed by adding the flag:
>
> -Widentifier-case-local
> Warn about an identifier written with varying case within one
> program/module/unit.
>

Note that your program consted of a single module (in other words it
contained just main program, without EP modules or units). The compiler
internally keeps only one copy of given identifier -- the meaning
changes according to the scope, but there is only one place to store
the spelling. It is natural to take scope rules into account when
warning about capitalization, but that requires extra work.


--
Waldek Hebisch
hebisch at math.uni.wroc.pl
Frank Heckenbach
2004-09-11 05:15:29 UTC
Permalink
Waldek Hebisch wrote:

> Dr. Thomas D. Schneider wrote:
> >
> > Demonstrate capitals bug in GPC. The name of a local procedure is
> > objected to by GPC if there is a global by the same name but
> > different capitalization.
> >
> > In theory the compiler should keep track of what is local and what
> > is global anyway, so it should be able to avoid this.
> >
> > It is a problem because if one imports procedures from another
> > program, they are not being treated as pure 'black boxes'.
> > Instead, local variable names are being compared to the global
> > variable names.
> >
> > In otherwords, the scope rule of Pascal is being violated
> > when these warnings are generated.
> >
> > This problem is not fixed by adding the flag:
> >
> > -Widentifier-case-local
> > Warn about an identifier written with varying case within one
> > program/module/unit.
>
> Note that your program consted of a single module (in other words it
> contained just main program, without EP modules or units). The compiler
> internally keeps only one copy of given identifier -- the meaning
> changes according to the scope, but there is only one place to store
> the spelling. It is natural to take scope rules into account when
> warning about capitalization, but that requires extra work.

It may be natural for some. I actually prefer it the way it is, i.e.
I prefer to use the same spelling (capitalization) throughout. So if
you or someone else implements the other way (which is indeed more
work), it should at least be optional.

BTW, calling it a bug is a bit strange, anyway. In Pascal, even
occurrences of an identifier referring to the same declaration can
have different capitalizations; the same applies to different
declarations (e.g., local vs. global) as well. Therefore, all this
is an optional warning, not an error.

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Prof. Harley Flanders
2004-09-11 13:36:57 UTC
Permalink
Speaking of fonts, can anyone out there please
tell me the name of a Windows font with these
properties (in one of its character sets):

Fixed width, not proportional.

Contains the whole Latin alphabet and punctuation marks
as usual within ASCII 1 - 127.

Contains the whole Greek alphabet, upper and lower case.

No need to bother the group, just me at harley at umich.edu

Thank you.

HF

----- Original Message -----
From: Frank Heckenbach
To: gpc at gnu.de
Sent: Saturday, September 11, 2004 1:15 AM
Subject: Re: Upper/lower case in identifiers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.g-n-u.de/pipermail/gpc/attachments/20040911/465d764a/attachment.htm>
Waldek Hebisch
2004-09-11 16:01:27 UTC
Permalink
Frank Heckenbach wrote:
> Waldek Hebisch wrote:
>
> > the spelling. It is natural to take scope rules into account when
> > warning about capitalization, but that requires extra work.
>
> It may be natural for some. I actually prefer it the way it is, i.e.
> I prefer to use the same spelling (capitalization) throughout. So if
> you or someone else implements the other way (which is indeed more
> work), it should at least be optional.
>

I belive that capitalization is meaningfull for people. So it is
natural that different meanings needs different capitalizations. Of
course, some persons may wish warning for re-using an identifier
with different meaning (or as compromise, a warning when meaning
is different enough to require different capitalization :)). But
IMHO the main use of `-Widentifier-case' is to ensure that standard
(case insensitive) interpretation coincides with case sensitive
one. And for _that_ purpose current behaviour is defective (gives
spurious warnings).

--
Waldek Hebisch
hebisch at math.uni.wroc.pl
Frank Heckenbach
2004-09-11 18:02:15 UTC
Permalink
Waldek Hebisch wrote:

> Frank Heckenbach wrote:
> > Waldek Hebisch wrote:
> >
> > > the spelling. It is natural to take scope rules into account when
> > > warning about capitalization, but that requires extra work.
> >
> > It may be natural for some. I actually prefer it the way it is, i.e.
> > I prefer to use the same spelling (capitalization) throughout. So if
> > you or someone else implements the other way (which is indeed more
> > work), it should at least be optional.
>
> I belive that capitalization is meaningfull for people.

I don't really. In natural language, capitalization is used as a
help in reading (used differently in different languages), but it
does not carry meaning itself (e.g., a text written in all-caps
still has the same meaning).

In my experience, variations in capitalization in Pascal code arise
mostly in the following cases:

- Typos -- good when warned

- Less strict used of capitalization (e.g., parts of the code having
all-lowercase identifiers) -- also good when warned (if you care
about capitalization at all, otherwise turn off the warning
anyway).

- Different arbitrary choices (e.g. `DOS' (acronym) vs. `Dos'
(everyday way)). Still it doesn't really carry meaning.

- Short identifiers such as `x' vs. `X'. These names are not
actually meaningful anyway.

> So it is
> natural that different meanings needs different capitalizations. Of
> course, some persons may wish warning for re-using an identifier
> with different meaning (or as compromise, a warning when meaning
> is different enough to require different capitalization :)). But
> IMHO the main use of `-Widentifier-case' is to ensure that standard
> (case insensitive) interpretation coincides with case sensitive
> one.

Which case-sensitive one? It's Pascal code, and Pacal is
case-insensitive. If you mean translating Pascal code to C or
another case-sensitive language, this may become an issue, but
certainly one of the least ones.

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Tom Verhoeff
2004-09-11 21:07:49 UTC
Permalink
On Sat, Sep 11, 2004 at 08:02:15PM +0200, Frank Heckenbach wrote:
> Waldek Hebisch wrote:
>
> > I belive that capitalization is meaningfull for people.
>
> I don't really. In natural language, capitalization is used as a
> help in reading (used differently in different languages), but it
> does not carry meaning itself (e.g., a text written in all-caps
> still has the same meaning).
>
> > So it is
> > natural that different meanings needs different capitalizations. Of
> > course, some persons may wish warning for re-using an identifier
> > with different meaning (or as compromise, a warning when meaning
> > is different enough to require different capitalization :)). But
> > IMHO the main use of `-Widentifier-case' is to ensure that standard
> > (case insensitive) interpretation coincides with case sensitive
> > one.

Waldek continued to write, but Frank didn't quote this part:

... And for _that_ purpose current behaviour is defective (gives
spurious warnings).

And I must say, I agree with Waldek. I think Frank may have misunderstood
Waldek's argument. Let me try to explain why I feel that current behavior
is not appropriate.

I recently recompiled a project containing some seven thousand lines
of Pascal code distributed over some twenty units. A couple of years
ago when it was last compiled, gpc didn't have the identifier-case
checking feature. During the recent recompile, I was overwhelmed with
casing complaints. Some of them were legitimate: same variable referred
to by different casings. And I changed the source accordingly. But many
warnings were completely unexpected for me, and unwarranted.

Consider the following situation. I have a record type Event,
with a Integer field sc, holding a score. The identifier sc
is meaningful only within the scope of the record. It is a local
identifier. Obviously (to me), all references to this field would
best be done by the spelling sc, and not Sc, or sC, or SC. The warnings
keep me honest (thank you!).

But I also have a procedure that has a local variable called SC of type
ScoreCard. Again, this is a local name, only meaningful within the scope
of the procedure. In fact, it could have been someone else who decided
on that name, someone unaware of the record Event with a field sc. It is
a local variable in a local name scope. But gpc warns about the casing
of SC being inconsistent, because it remembers the casing of the field sc.
At least, so it seems to me.

That does not sound right to me. These are two completely different
name scopes, where different casings may be called for. I would hope
that the casing is for me to decide, and I don't want a warning from
the compiler. It is almost as bad as warning me that I have
two procedures that use the same name, such as i, for a local variable.
In fact, it may be even worse to use case-identical names
for entities that are actually very different. (Think of

var i: Integer; { index in array a } versus
var i: Real; { imaginary part of approximation of smallest zero of f }

But that is a different issue. You could also warn me when using names
that are nearly equal, such Block and Blok, for different entities.

So, the behavior that I had expected from gpc when it comes to identifier
case checking is that names that refer to the SAME entity (hence,
within the same scope) are checked to have the same casing, warning
me if they are not. Of course, such identifiers must be equal modulo
case differences, for otherwise they would not refer to the same entity
according to the rules of Pascal.

It is another matter, what it would take to make gpc behave this way.
But I would think, that it should be quite easy to do. For each
entity, the casing of the defining occurrence is stored. When a reference
to this entity is encountered (i.e. a name that modulo casing is equal
to the defining occurrence), then the casing is checked against that of
the defining occurrence, and a warning is issued if it is different.

The current implementation seems to be something like: if a name
is encountered in a defining occurrence, its casing is remembered;
and any other name, regardless of scope or entity it refers to, is
checked against that global table to have the same casing.

Waldek, is this what you mean?

Tom
--
E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science
PHONE: +31 40 247 41 25 | Eindhoven University of Technology
FAX: +31 40 247 54 04 | PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/ | The Netherlands
Frank Heckenbach
2004-09-11 21:58:48 UTC
Permalink
Tom Schneider wrote:

> > The compiler internally keeps only one copy of given identifier --
> > the meaning changes according to the scope, but there is only one
> > place to store the spelling. It is natural to take scope rules into
> > account when warning about capitalization, but that requires extra
> > work.
>
> The compiler already keeps track of scope for each variable. So
> keeping one copy of an identifier just (apparently) reveals

Again: The warning is about *identifiers* (including keywords
actually), not about *declarations* (and it doesn't claim
otherwise).

> that the
> GPC code is not efficient.

Not really. This way, the capitalization can be checked right after
a word (identifier or keyword) is recognized. When doing it after
distinguishing between keywords and various kinds of declarations,
there would be more places to add the checks.

> In other words, the warning code could
> (should!) use the code already used for tracking the scope.

As I said, I prefer to check the capitalization of identifiers. If
you prefer to check the capitalization of declarations, go ahead and
implement it (optionally). It's free software. But please contact
Waldek before about the details to avoid conflicts with his
qualified identifier changes.

Tom Verhoeff wrote:

> On Sat, Sep 11, 2004 at 08:02:15PM +0200, Frank Heckenbach wrote:
> > Waldek Hebisch wrote:
> >
> > > I belive that capitalization is meaningfull for people.
> >
> > I don't really. In natural language, capitalization is used as a
> > help in reading (used differently in different languages), but it
> > does not carry meaning itself (e.g., a text written in all-caps
> > still has the same meaning).
> >
> > > So it is
> > > natural that different meanings needs different capitalizations. Of
> > > course, some persons may wish warning for re-using an identifier
> > > with different meaning (or as compromise, a warning when meaning
> > > is different enough to require different capitalization :)). But
> > > IMHO the main use of `-Widentifier-case' is to ensure that standard
> > > (case insensitive) interpretation coincides with case sensitive
> > > one.
>
> Waldek continued to write, but Frank didn't quote this part:
>
> ... And for _that_ purpose current behaviour is defective (gives
> spurious warnings).

Because I don't see a "case sensitive interpretation" of Pascal
code.

There may be other Pascal compilers which are case-sensitive, which
is obviously non-standard. Our general attitude to non-standard
compilers is to be at best backwards-compatible, which this warning
surely makes it.

> I recently recompiled a project containing some seven thousand lines
> of Pascal code distributed over some twenty units. A couple of years
> ago when it was last compiled, gpc didn't have the identifier-case
> checking feature. During the recent recompile, I was overwhelmed with
> casing complaints. Some of them were legitimate: same variable referred
> to by different casings.

Again, Pascal isn't concerned with the capitalization of identifiers
referring to the same declaration any more than it is with that of
identifiers referring to different declarations. If you consider one
thing more "legitimate" than the other, that's your opinion, but
please don't state it as a fact.

> In fact, it may be even worse to use case-identical names
> for entities that are actually very different. (Think of
>
> var i: Integer; { index in array a } versus
> var i: Real; { imaginary part of approximation of smallest zero of f }

I don't agree. IMHO, using different cases to distinguish them is
just asking for trouble (because the identifiers are still
equivalent in Pascal). So if you feel you need to distinguish the
names, use different identifiers at all.

> But that is a different issue. You could also warn me when using names
> that are nearly equal, such Block and Blok, for different entities.

Interesting idea, to guard against the effects of typos.
Unfortunaly, this will probably need quite some heuristics (and be
more expensive at compile-time).

> It is another matter, what it would take to make gpc behave this way.
> But I would think, that it should be quite easy to do. For each
> entity, the casing of the defining occurrence is stored. When a reference
> to this entity is encountered (i.e. a name that modulo casing is equal
> to the defining occurrence), then the casing is checked against that of
> the defining occurrence, and a warning is issued if it is different.

Basically yes. Except that there are many places where an occurrence
(especially an applied occurrence) of an identifier is first
detected. Due to the various standards and dialects, this is often
not possible until deep within the parser.

> The current implementation seems to be something like: if a name
> is encountered in a defining occurrence, its casing is remembered;
> and any other name, regardless of scope or entity it refers to, is
> checked against that global table to have the same casing.

As I stated above, its about identifiers, not declarations. So omit
the defining occurrence part. It's simply, when a name is first
encountered [...]. (E.g. in types, the defining occurrence doesn't
have to be first, but it doesn't matter.)

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Waldek Hebisch
2004-09-11 21:43:35 UTC
Permalink
> Waldek Hebisch wrote:
>
> > Frank Heckenbach wrote:
> > > Waldek Hebisch wrote:
> > >
> > > > the spelling. It is natural to take scope rules into account when
> > > > warning about capitalization, but that requires extra work.
> > >
> > > It may be natural for some. I actually prefer it the way it is, i.e.
> > > I prefer to use the same spelling (capitalization) throughout. So if
> > > you or someone else implements the other way (which is indeed more
> > > work), it should at least be optional.
> >
> > I belive that capitalization is meaningfull for people.
>
> I don't really. In natural language, capitalization is used as a
> help in reading (used differently in different languages), but it
> does not carry meaning itself (e.g., a text written in all-caps
> still has the same meaning).
>

That argument is bogus. You can distort text quite a lot and people
still may read it correctly. But in all caps text one can easily
misread proper name and take it as ordinary word. If you take a
single word in isolation, then your chance to get correct meaning
is significantly lower with case-folded word. In math it is usual
to use names differing only in case for different objects.

Note also that capitalization have meaning beyond literal meaning
of the text -- it helps express emotions, respect or stress something.
Programming languages have much less redundancy then natural language
so capitalization becomes more valuable.

> In my experience, variations in capitalization in Pascal code arise
> mostly in the following cases:
>
> - Typos -- good when warned
>
> - Less strict used of capitalization (e.g., parts of the code having
> all-lowercase identifiers) -- also good when warned (if you care
> about capitalization at all, otherwise turn off the warning
> anyway).
>
> - Different arbitrary choices (e.g. `DOS' (acronym) vs. `Dos'
> (everyday way)). Still it doesn't really carry meaning.
>
> - Short identifiers such as `x' vs. `X'. These names are not
> actually meaningful anyway.
>

You forgot:

- NamesConsistingOfMultipleWords (most frequent in my experience)

- conventions like:
globals capitalized, locals lowercase
or
agregates capitalized, scalars lowercase

And we should divide programmers into two groups, one that does not
care about capitalization and the second that cares. The first group
produces lot of meaningless variation, but they are irrelevant for
the discussion since they wish no warning. The second group IMHO
is much more likely to associate meaning with capitalization.

> > So it is
> > natural that different meanings needs different capitalizations. Of
> > course, some persons may wish warning for re-using an identifier
> > with different meaning (or as compromise, a warning when meaning
> > is different enough to require different capitalization :)). But
> > IMHO the main use of `-Widentifier-case' is to ensure that standard
> > (case insensitive) interpretation coincides with case sensitive
> > one.
>
> Which case-sensitive one? It's Pascal code, and Pacal is
> case-insensitive. If you mean translating Pascal code to C or
> another case-sensitive language, this may become an issue, but
> certainly one of the least ones.
>

1) If you use a convention assigning meaning to case, then reader
point of view is case-sensitive.

2) When working both with case sensitive and case insensitive languages
a programmer may save sanity by treating both as case-preserving.

3) Many tools are easier to use as case sensitive ones (simple example
is global regex search&replace)

--
Waldek Hebisch
hebisch at math.uni.wroc.pl
Frank Heckenbach
2004-09-11 22:20:57 UTC
Permalink
Waldek Hebisch wrote:

> > > I belive that capitalization is meaningfull for people.
> >
> > I don't really. In natural language, capitalization is used as a
> > help in reading (used differently in different languages), but it
> > does not carry meaning itself (e.g., a text written in all-caps
> > still has the same meaning).
>
> That argument is bogus. You can distort text quite a lot and people
> still may read it correctly.

Sorry, but *that* argument is bogus. All-caps text is not quite the
same as distorted text.

> In math it is usual
> to use names differing only in case for different objects.

In math, it's usual to use single letters, perhaps indexed etc.,
rather than words.

> Note also that capitalization have meaning beyond literal meaning
> of the text -- it helps express emotions, respect or stress something.

Well, I was about to write "these comparisons go too far" before I
read this paragraph, but now it's really too much! Emotions in a
Pascal program, eh? ;-)

Let's stick to Pascal based arguments, perhaps?

> > In my experience, variations in capitalization in Pascal code arise
> > mostly in the following cases:
> >
> > - Typos -- good when warned
> >
> > - Less strict used of capitalization (e.g., parts of the code having
> > all-lowercase identifiers) -- also good when warned (if you care
> > about capitalization at all, otherwise turn off the warning
> > anyway).
> >
> > - Different arbitrary choices (e.g. `DOS' (acronym) vs. `Dos'
> > (everyday way)). Still it doesn't really carry meaning.
> >
> > - Short identifiers such as `x' vs. `X'. These names are not
> > actually meaningful anyway.
> >
>
> You forgot:
>
> - NamesConsistingOfMultipleWords (most frequent in my experience)

True. But using different concatenations resulting in the same
identifier (such as `FooBar' and `FoobAr' -- I know there are real
examples of this, I just don't have them in mind right now) is
asking for trouble in a case-insensitive language. In C, you can do
this and get away with it. In Pascal, sooner or later, you might use
those names in the same scope and get a conflict. So even here, I
prefer the current behaviour which warns me as soon as possible and
lets me choose another name for one of the things.

> - conventions like:
> globals capitalized, locals lowercase
> or
> agregates capitalized, scalars lowercase

IMHO these are archaic conventions, coming from languages such as C
(where there's only one global and one local level, in contrast to
Pascal which has arbitrarily many levels, and a local variable of
level 1 can behave like a global variable, seen from a routine at
level 2, etc.), and assembler (where there's a general difference
between aggregates and scalars). So I don't care much for such
conventions.

> And we should divide programmers into two groups, one that does not
> care about capitalization and the second that cares. The first group
> produces lot of meaningless variation, but they are irrelevant for
> the discussion since they wish no warning. The second group IMHO
> is much more likely to associate meaning with capitalization.

So do I, yet I prefer to avoid different capitalizations of the same
identifier (see above).

> > > So it is
> > > natural that different meanings needs different capitalizations. Of
> > > course, some persons may wish warning for re-using an identifier
> > > with different meaning (or as compromise, a warning when meaning
> > > is different enough to require different capitalization :)). But
> > > IMHO the main use of `-Widentifier-case' is to ensure that standard
> > > (case insensitive) interpretation coincides with case sensitive
> > > one.
> >
> > Which case-sensitive one? It's Pascal code, and Pacal is
> > case-insensitive. If you mean translating Pascal code to C or
> > another case-sensitive language, this may become an issue, but
> > certainly one of the least ones.
>
> 1) If you use a convention assigning meaning to case, then reader
> point of view is case-sensitive.

And if this point of view differs too much and may get in conflict
with the compiler's point of view (cf. the `FoobAr' example above)?

> 2) When working both with case sensitive and case insensitive languages
> a programmer may save sanity by treating both as case-preserving.

In this case (which actually applies to me as well), one should use
the lowest-common denominator. I.e., never declare `I' and use `i'
(would break in C), but also never declare an `I' and another `i'
(would break in Pascal, perhaps even in non-obvious ways (read: hard
to find bugs), if these declarations "meet" later).

> 3) Many tools are easier to use as case sensitive ones (simple example
> is global regex search&replace)

My editor (and many of the tools I use) can actually do
case-insensitive regex operations, BTW. But that's beside the point,
because I do program in a case-sensitive way.

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Grant Jacobs
2004-09-12 03:53:39 UTC
Permalink
> > - conventions like:
>> globals capitalized, locals lowercase
>> or
>> agregates capitalized, scalars lowercase
>
>IMHO these are archaic conventions, coming from languages such as C
>(where there's only one global and one local level, in contrast to
>Pascal which has arbitrarily many levels, and a local variable of
>level 1 can behave like a global variable, seen from a routine at
>level 2, etc.), and assembler (where there's a general difference
>between aggregates and scalars). So I don't care much for such
>conventions.

They might be archaic (and I think so too), but one thing I'd like
gpc to keep in mind is porting code to and from other languages.
Silly things like this can help porting. Another example might be the
use of leading underscores in identifiers; de facto std. in C for
internal variables in libraries. In Pascal there is no practical need
for these, but they are useful when shifting code to C or some other
language.

I tend to program case-sensitive myself, partly habit and partly to
create one less problems if I have to shift the code to another
language.

Grant
--
-------------------------------------------------------------------
Grant Jacobs Ph.D. BioinfoTools
ph. +64 3 478 0095 (office, after 10am) PO Box 6129,
or +64 25 601 5917 (mobile) Dunedin,
gjacobs at bioinfotools.com NEW ZEALAND.
Bioinformatics tools: deriving knowledge from biological data
Bioinformatics tools - software development - consulting - training
Check out the website for more details: http://www.bioinfotools.com

The information contained in this mail message is confidential and
may be legally privileged. Readers of this message who are not the
intended recipient are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you
have received this message in error please notify the sender immed-
iately and destroy the original message. This applies also to any
attached documents.
Frank Heckenbach
2004-09-12 13:01:19 UTC
Permalink
Grant Jacobs wrote:

> > > - conventions like:
> >> globals capitalized, locals lowercase
> >> or
> >> agregates capitalized, scalars lowercase
> >
> >IMHO these are archaic conventions, coming from languages such as C
> >(where there's only one global and one local level, in contrast to
> >Pascal which has arbitrarily many levels, and a local variable of
> >level 1 can behave like a global variable, seen from a routine at
> >level 2, etc.), and assembler (where there's a general difference
> >between aggregates and scalars). So I don't care much for such
> >conventions.
>
> They might be archaic (and I think so too), but one thing I'd like
> gpc to keep in mind is porting code to and from other languages.
> Silly things like this can help porting. Another example might be the
> use of leading underscores in identifiers; de facto std. in C for
> internal variables in libraries. In Pascal there is no practical need
> for these, but they are useful when shifting code to C or some other
> language.

All of these are warnings and can be turned off. I basically agree
with your argument, that's why I also wouldn't like to turn the
underscore warnings into errors (except in strict standard Pascal
mode where it's prescribed).

> I tend to program case-sensitive myself, partly habit and partly to
> create one less problems if I have to shift the code to another
> language.

Me too, and the current warning does not hinder doing so (just
enforces more case-sensitivity than a (declaration-wise)
case-sensitive language would demand).

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Adriaan van Os
2004-09-11 22:33:35 UTC
Permalink
Frank Heckenbach wrote:

> Which case-sensitive one? It's Pascal code, and Pacal is
> case-insensitive.

That may have been a wise design decision in the 1970's when programs
were written on punch forms and then typed out by card punch operators.
Anno 2004, it is an anachronism. I agree with Waldek that humans are
case-sensitive - at least I am.

Regards,

Adriaan van Os
Frank Heckenbach
2004-09-11 22:36:43 UTC
Permalink
Adriaan van Os wrote:

> Frank Heckenbach wrote:
>
> > Which case-sensitive one? It's Pascal code, and Pacal is
> > case-insensitive.
>
> That may have been a wise design decision in the 1970's when programs
> were written on punch forms and then typed out by card punch operators.
> Anno 2004, it is an anachronism.

So is the lack of `endif', and a few other things IMHO. We can't
change the fundamentals of Pascal, I'm afraid.

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
John L. Ries
1970-01-01 00:00:00 UTC
Permalink
On Sun, 12 Sep 2004, Adriaan van Os wrote:

> Frank Heckenbach wrote:
>
>> Which case-sensitive one? It's Pascal code, and Pacal is
>> case-insensitive.
>
> That may have been a wise design decision in the 1970's when programs were
> written on punch forms and then typed out by card punch operators. Anno 2004,
> it is an anachronism. I agree with Waldek that humans are case-sensitive - at
> least I am.
>
> Regards,
>
> Adriaan van Os
>
>
>
OK. Time to shoot off my keyboard...

IMHO, case-sensitivity is the single worst feature of both UNIX and C.
In human language, capitalization is a grammatical construct which carries
little or no semantic meaning (ie. the meaning of a word is almost never
dependent on how it is capitalized). People will thus expect
computer languages to work the same way. Given that this is the case,
case-sensitive file systems and programming languages are guaranteed to
confuse the unwary (and sometimes even the wary) without providing any
discernable benefits other than a slightly simpler parser. It is one of
the many reasons why C code is much more difficult to debug than Pascal
or Fortran code.

Mind you, having a file system or programming language remember the
capitalization of a word for display purposes can be useful for
readibility, but to me, it makes no sense at all to permit two variable
or file names with identical spellings, but different capitalizations.

Back to work...

-------------------------|
John L. Ries |
Salford Systems |
Phone: (619)543-8880 x23 |
Cell: (760)445-6122 |
-------------------------
Scott Moore
2004-09-14 00:03:30 UTC
Permalink
John L. Ries wrote:

> On Sun, 12 Sep 2004, Adriaan van Os wrote:
>
>> Frank Heckenbach wrote:
>>
>>> Which case-sensitive one? It's Pascal code, and Pacal is
>>> case-insensitive.
>>
>>
>> That may have been a wise design decision in the 1970's when programs
>> were written on punch forms and then typed out by card punch
>> operators. Anno 2004, it is an anachronism. I agree with Waldek that
>> humans are case-sensitive - at least I am.
>>
>> Regards,
>>
>> Adriaan van Os
>>
>>
>>
> OK. Time to shoot off my keyboard...
>
> IMHO, case-sensitivity is the single worst feature of both UNIX and C.
> In human language, capitalization is a grammatical construct which
> carries little or no semantic meaning (ie. the meaning of a word is
> almost never dependent on how it is capitalized). People will thus
> expect computer languages to work the same way. Given that this is
> the case, case-sensitive file systems and programming languages are
> guaranteed to confuse the unwary (and sometimes even the wary) without
> providing any discernable benefits other than a slightly simpler
> parser. It is one of the many reasons why C code is much more
> difficult to debug than Pascal or Fortran code.
>
> Mind you, having a file system or programming language remember the
> capitalization of a word for display purposes can be useful for
> readibility, but to me, it makes no sense at all to permit two
> variable or file names with identical spellings, but different
> capitalizations.
>
> Back to work...
>
A little history: Capitals and Italics began life as separate type
styles. In the old (old) days of printing, there were no punctuation
marks and writing looked like

thisisasentenceiexpectyoutoread

As type styles evolved, punctuation and spaces between words became
customary. In addition, both capitalization and italics became seen as
simply alternate styles of the same type set. Another
"minor style difference" was bold; an example of a style difference that
didn't become a style
of each typeface is serifs.

The question of what to use these differences for was decided by common
use. Bold and italic became emphasis characters. Capitalization is a
stranger case. Because it started as an alternate typeface, whole
documents were written in it. However it became considered as a hard to
read typeface, and
became depreciated for use in more than a character or two. Hence, it
fell into todays common conventions, as a sentence start character
(essentially a punctuation aid), or the start of proper
names. It also became common to use all caps for signs, but this itself
is fairly controversial
(among typographers). Headlines use it, but freeway signs don't.

When telegraphs evolved to teletypes, circa 1930, only one set of
characters was deemed more economical. All caps was the most common set
of characters, probably because it was seen as a
sign (or headline) font. This carried over into computers for obvious
reasons. When computer
terminals that used both upper and lower case evolved, upper case was
still misused as an
emphasis character, probably because it was the only other font on the
keyboard. To this day,
emphasis characters remain second class citizens. There is no bold or
italic key on a computer
keyboard. There is a shift key.

Having "computers work differently than people" is and old controversy.
Infix vs. Polish
notation in expressions, the ":=" operator vs. "=" for assignment, array
indexes starting with
"1" and not "0", these were all about making sure the computer notations
followed common
usages outside of computers, irregardless of the "right/wrong" nature of
what are, after all,
fairly arbitrary conventions.

In as far as case is concerned with Pascal, Pascal was clearly designed
with pains to use
human conventions, even if arguably inefficient (the "1" based
convention of Pascal sometimes
generates extra bounds adjustment code). C was not. GPC clearly has as
one of its design goals
the integration of Pascal and C (not considering if that is a good or
bad idea at the moment).

Therefore, unfortunately, the proper behavior of GPC is clear. It must
warn against Pascal
types that are exported, which rely on case insensitivity, i.e.,
exporting both MyVar and
myvar. These names will clearly cause trouble between the two languages.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Being right is more powerfull than large corporations or governments.
The right argument may not be pervasive, but the facts eventually are.
John L. Ries
2004-09-14 01:45:59 UTC
Permalink
I agree with everything you said in your reply. What I take issue
with is the notion that Pascal's case insensivity is an anachronism or in
any way unfortunate; I regard it as a asset. Furthermore, I have yet to
see a rational argument in favor of case sensitivity in programming
languages. Given, however, the widespread use of C and other
case sensitive languages (I use them too), it is useful to have
case sensitivity warnings available if one wants them, as long as they
are off by default.

-------------------------|
John L. Ries |
Salford Systems |
Phone: (619)543-8880 x23 |
Cell: (760)445-6122 |
-------------------------


On Mon, 13 Sep 2004, Scott Moore wrote:

> John L. Ries wrote:
>
>> On Sun, 12 Sep 2004, Adriaan van Os wrote:
>>
>>> Frank Heckenbach wrote:
>>>
>>>> Which case-sensitive one? It's Pascal code, and Pacal is
>>>> case-insensitive.
>>>
>>>
>>> That may have been a wise design decision in the 1970's when programs were
>>> written on punch forms and then typed out by card punch operators. Anno
>>> 2004, it is an anachronism. I agree with Waldek that humans are
>>> case-sensitive - at least I am.
>>>
>>> Regards,
>>>
>>> Adriaan van Os
>>>
>>>
>>>
>> OK. Time to shoot off my keyboard...
>>
>> IMHO, case-sensitivity is the single worst feature of both UNIX and C.
>> In human language, capitalization is a grammatical construct which carries
>> little or no semantic meaning (ie. the meaning of a word is almost never
>> dependent on how it is capitalized). People will thus expect computer
>> languages to work the same way. Given that this is the case,
>> case-sensitive file systems and programming languages are guaranteed to
>> confuse the unwary (and sometimes even the wary) without providing any
>> discernable benefits other than a slightly simpler parser. It is one of
>> the many reasons why C code is much more difficult to debug than Pascal or
>> Fortran code.
>>
>> Mind you, having a file system or programming language remember the
>> capitalization of a word for display purposes can be useful for
>> readibility, but to me, it makes no sense at all to permit two variable or
>> file names with identical spellings, but different capitalizations.
>>
>> Back to work...
>>
> A little history: Capitals and Italics began life as separate type styles. In
> the old (old) days of printing, there were no punctuation marks and writing
> looked like
>
> thisisasentenceiexpectyoutoread
>
> As type styles evolved, punctuation and spaces between words became
> customary. In addition, both capitalization and italics became seen as simply
> alternate styles of the same type set. Another
> "minor style difference" was bold; an example of a style difference that
> didn't become a style
> of each typeface is serifs.
>
> The question of what to use these differences for was decided by common use.
> Bold and italic became emphasis characters. Capitalization is a stranger
> case. Because it started as an alternate typeface, whole documents were
> written in it. However it became considered as a hard to read typeface, and
> became depreciated for use in more than a character or two. Hence, it fell
> into todays common conventions, as a sentence start character (essentially a
> punctuation aid), or the start of proper
> names. It also became common to use all caps for signs, but this itself is
> fairly controversial
> (among typographers). Headlines use it, but freeway signs don't.
>
> When telegraphs evolved to teletypes, circa 1930, only one set of characters
> was deemed more economical. All caps was the most common set of characters,
> probably because it was seen as a
> sign (or headline) font. This carried over into computers for obvious
> reasons. When computer
> terminals that used both upper and lower case evolved, upper case was still
> misused as an
> emphasis character, probably because it was the only other font on the
> keyboard. To this day,
> emphasis characters remain second class citizens. There is no bold or italic
> key on a computer
> keyboard. There is a shift key.
>
> Having "computers work differently than people" is and old controversy. Infix
> vs. Polish
> notation in expressions, the ":=" operator vs. "=" for assignment, array
> indexes starting with
> "1" and not "0", these were all about making sure the computer notations
> followed common
> usages outside of computers, irregardless of the "right/wrong" nature of what
> are, after all,
> fairly arbitrary conventions.
>
> In as far as case is concerned with Pascal, Pascal was clearly designed with
> pains to use
> human conventions, even if arguably inefficient (the "1" based convention of
> Pascal sometimes
> generates extra bounds adjustment code). C was not. GPC clearly has as one of
> its design goals
> the integration of Pascal and C (not considering if that is a good or bad
> idea at the moment).
>
> Therefore, unfortunately, the proper behavior of GPC is clear. It must warn
> against Pascal
> types that are exported, which rely on case insensitivity, i.e., exporting
> both MyVar and
> myvar. These names will clearly cause trouble between the two languages.
>
> --
> Samiam is Scott A. Moore
>
> Personal web site: http:/www.moorecad.com/scott
> My electronics engineering consulting site: http://www.moorecad.com
> ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
> Classic Basic Games web site: http://www.moorecad.com/classicbasic
> The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
> compiler system: http://www.moorecad.com/ippas
>
> Being right is more powerfull than large corporations or governments.
> The right argument may not be pervasive, but the facts eventually are.
>
>
>
Adriaan van Os
2004-09-14 07:55:34 UTC
Permalink
John L. Ries wrote:

> IMHO, case-sensitivity is the single worst feature of both UNIX and C.

But what is "case-sensitive" and "not case-sensitive" ?

Does "not case-sensitive" mean that "theInt" is converted to "THEINT"
or "Theint" or "_Theint" ? Then, we back in the middle ages of
computing. We are simply ignoring the fact that humans really don't
like that (and thus start passionate discussions about it).

Or, does "case-sensitive" mean that "MyProgram.pas" is listed in a file
system as "MyProgram.pas" (not "MYPROGRAM.PAS") but that at the same
time a file "myprogram.pas" in the same directory is not allowed ? I
would call that a clever design decision. The human sensitive-to-case
aspect of it is retained (rather than subordinated to technical
considerations) and at the same time the mistakes of UNIX and C are
avoided.

Regards,

Adriaan van Os
Peter N Lewis
2004-09-14 14:16:36 UTC
Permalink
Guys, this is a really pointless discussion.

Even if you believe (as I happen to do) that there should be a
warning for case mismatches that honors scope rules and does not
detect case mismatches where the different cases are used in
different contexts, the fact is that Frank does not believe that is
necessary or useful and so he is not interested in implementing it
which is perfectly within his rights. If folks want a warning to
work in a different way then they need to find a way to implement it,
not just argue with Frank who clearly has thought through the issue
and made his own decision. We (and he) have heard all these
arguments already several times and just repeating them is unlikely
to get any results.

Either write the code to produce a warning in the scope sensitive way
(without impacting on the warning that Frank obviously values) or
hire or find someone to do this work. You can't just expect Frank to
decide to do it just because you want it done in a different way.
You might have some hope of expecting that if you paid for the
software, but this is open source software, and while there are lots
of advantages of open source software, one of the disadvantages is
that a legal user doesn't have any leverage over the developers.

Personally, I'd love to see a switch to turn on full case
sensitivity, which is how I program in Metrowerks Pascal (and which
as a customer I encouraged them to implement). I don't find case
sensitivity a drawback because I always compile with warnings on and
get rid of all warnings so there is never any issue. But then again,
I am probably not going to spend the time to implement this or hire
someone to do it, and I'm certainly not going to badger Frank or
anyone else to do it.

So lets just drop the subject unless someone wants to volunteer to
put some effort in to doing something constructive about it...?
Peter.
--
<http://www.stairways.com/> <http://download.stairways.com/>
Tom Verhoeff
2004-09-14 14:45:09 UTC
Permalink
On Tue, Sep 14, 2004 at 10:16:36PM +0800, Peter N Lewis wrote:
> Guys, this is a really pointless discussion.
>
> Even if you believe (as I happen to do) that there should be a
> warning for case mismatches that honors scope rules and does not
> detect case mismatches where the different cases are used in
> different contexts, the fact is that Frank does not believe that is
> necessary or useful and so he is not interested in implementing it
> which is perfectly within his rights. If folks want a warning to
> work in a different way then they need to find a way to implement it,
> not just argue with Frank who clearly has thought through the issue
> and made his own decision. We (and he) have heard all these
> arguments already several times and just repeating them is unlikely
> to get any results.

I completely agree with your point of view here. Nice summary!

Let's get onto some work now (and leave Frank to do his work).

Cheers,

Tom
Frank Heckenbach
2004-09-15 04:06:08 UTC
Permalink
Peter N Lewis wrote:

> Either write the code to produce a warning in the scope sensitive way
> (without impacting on the warning that Frank obviously values) or
> hire or find someone to do this work. You can't just expect Frank to
> decide to do it just because you want it done in a different way.
> You might have some hope of expecting that if you paid for the
> software, but this is open source software, and while there are lots
> of advantages of open source software, one of the disadvantages is
> that a legal user doesn't have any leverage over the developers.

Since you mention it, I work as a programmer, so if somebody really
wants to pay for it, there's a chance I might do it. However, since
it will be a feature I have no personal interest in, I'd charge the
full rate, so ...

> Personally, I'd love to see a switch to turn on full case
> sensitivity, which is how I program in Metrowerks Pascal (and which
> as a customer I encouraged them to implement).

BTW, by "full case sensitivity", do you mean that the same
identifier must always have the same capitalization, or even that
there can be different identifiers with the same spelling and
different capitalization, without conflicting? (I like the former,
but I'd consider the latter rather dangerous in a Pascal dialect.)

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
John L. Ries
2004-09-14 16:47:35 UTC
Permalink
Adriaan van Os wrote:

> John L. Ries wrote:
>
>> IMHO, case-sensitivity is the single worst feature of both UNIX and C.
>
>
> But what is "case-sensitive" and "not case-sensitive" ?
>
> Does "not case-sensitive" mean that "theInt" is converted to "THEINT" or
> "Theint" or "_Theint" ? Then, we back in the middle ages of computing.
> We are simply ignoring the fact that humans really don't like that (and
> thus start passionate discussions about it).
>
In a case-insensitive programming language, one can capitalize (or not)
a name however one likes and it won't change the meaning. That is what
Fortran, Pascal and other case-insensitive languages do and C, Perl,
AWK, etc. don't. How the name is capitalized internally is an
implementation detail (nothing wrong with writing a Fortran compiler
that uses mixed-case variable names in listings; maybe the first
capitalization it sees for each name, which is what one sees in modern
Windows directory listings). Even if the names are internally converted
to upper or lower case, it doesn't affect the readibility of the code,
which is under the control of the programmer. Certainly, Pascal doesn't
force you to write everything in upper-case, though you could, if you
wanted.

> Or, does "case-sensitive" mean that "MyProgram.pas" is listed in a file
> system as "MyProgram.pas" (not "MYPROGRAM.PAS") but that at the same
> time a file "myprogram.pas" in the same directory is not allowed ? I
> would call that a clever design decision. The human sensitive-to-case
> aspect of it is retained (rather than subordinated to technical
> considerations) and at the same time the mistakes of UNIX and C are
> avoided.

That's called display case sensitivity and it's a good thing (semantic
case sensitivity, which is what I was discussing, is not). I'll even
give the devil his due and credit MS for making it a standard feature of
Windows file systems (having imported it from OS/2's HPFS).

While it is true that C has become the Industry Standard (aka the
"established religion") and that many newer programming languages copy
C's syntax and case sensitivity (to make it easier for C programmers to
learn them), this does not mean that the case insensitivity of Pascal,
Fortran, BASIC, and the like is an anachronism (ie. a formerly useful
feature that has now become a burden); it it still a useful feature
because it eliminates a major source of syntax errors and confusion at
very low cost. It is unfortunate that the developers of GPC have to
spend time writing code to flag case inconsistancy issues; we have only
the dominance of C to blame for it.

I think we can lay this discussion to rest at this point.

-------------------------|
John L. Ries |
Salford Systems |
Phone: (619)543-8880 x23 |
Cell: (760)445-6122 |
-------------------------
Scott Moore
2004-09-14 22:23:57 UTC
Permalink
It occurred to me, I have the means to give GPC a printed manual, if you
guys
are interested. I have the ability to make manuals for IP Pascal,
perfect bound.
There is a GCC manual, but the volume on that no doubt justifies one of
those
1000's of copy printings with the big price tags. I have the ability to do
"print on demand", so could send these out in onesy twosey basis.

If this is interesting to the group, the caveats are as follows:

1. I don't really have much time to rework manuals, so I would need a
postscript
or PDF file that is all ready to go, i.e., an exact image of the book,
and its
cover (GCC manuals appear to be a fairly trivial rework of the online docs).

2. I'm not a non-profit (or particularly altruistic) person. We would
agree on
a reasonable price to cover costs (what I would charge purchasers). It would
be similar to the price of current GNU manuals.
Frank Heckenbach
2004-09-15 03:45:39 UTC
Permalink
Scott Moore wrote:

> It occurred to me, I have the means to give GPC a printed manual, if you
> guys
> are interested. I have the ability to make manuals for IP Pascal,
> perfect bound.
> There is a GCC manual, but the volume on that no doubt justifies one of
> those
> 1000's of copy printings with the big price tags. I have the ability to do
> "print on demand", so could send these out in onesy twosey basis.
>
> If this is interesting to the group, the caveats are as follows:
>
> 1. I don't really have much time to rework manuals, so I would need a
> postscript
> or PDF file that is all ready to go, i.e., an exact image of the book,
> and its
> cover (GCC manuals appear to be a fairly trivial rework of the online docs).

So is GPC's. You can find the version (as of the last release) on
the home page (PostScript and PDF). There may be some details to
take care of before printing it, but for a first attempt, you might
want to have a look at them.

The other big caveat is, of course, that GPC's documentation is
still quite incomplete. So I don't know if there will be big demand
for a printed version yet, but others here might answer ...

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Scott Moore
2004-09-15 06:56:52 UTC
Permalink
Frank Heckenbach wrote:

>Scott Moore wrote:
>
>
>
>>It occurred to me, I have the means to give GPC a printed manual, if you
>>guys
>>are interested. I have the ability to make manuals for IP Pascal,
>>perfect bound.
>>There is a GCC manual, but the volume on that no doubt justifies one of
>>those
>>1000's of copy printings with the big price tags. I have the ability to do
>>"print on demand", so could send these out in onesy twosey basis.
>>
>>If this is interesting to the group, the caveats are as follows:
>>
>>1. I don't really have much time to rework manuals, so I would need a
>>postscript
>>or PDF file that is all ready to go, i.e., an exact image of the book,
>>and its
>>cover (GCC manuals appear to be a fairly trivial rework of the online docs).
>>
>>
>
>So is GPC's. You can find the version (as of the last release) on
>the home page (PostScript and PDF). There may be some details to
>take care of before printing it, but for a first attempt, you might
>want to have a look at them.
>
>The other big caveat is, of course, that GPC's documentation is
>still quite incomplete. So I don't know if there will be big demand
>for a printed version yet, but others here might answer ...
>
>Frank
>
>
>
Ok, 550 pages. The following questions apply (for starters):

1. Is it too incomplete to print at this time ? Better to wait ?

2. Is the postscript or PDF suitable to be cut down to manual size ?
For example, the GCC manual is cut to 7x9 inches. Most people don't
like 8.5x11" books, and the "perfect" in perfect binding occurs
because the books are cut after binding, which cleans up the book
considerably. I usually custom format my books for the final print
size, and add "trim marks", which are marks on the 8.5x11 page that
show where to cut it.

3. What cover art ?

4. Does FSF get funds from this (appears to be the standard arrangement
for GNU prints) ?

5. Straight or lay-flat binding ?

6. What arrangements does GNU allow for printers of its material ?
I.e., does the FSF/GNU have problems with people printing under their
name ? What conditions ? Does FSF/GNU run its own bindery, or allow
for-profit printers to create material ? Does FSF/GNU want express
control of that ? etc.

Thanks.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Being right is more powerfull than large corporations or governments.
The right argument may not be pervasive, but the facts eventually are.
CBFalconer
2004-09-15 21:26:09 UTC
Permalink
Scott Moore wrote:
>
... snip ...
>
> 2. Is the postscript or PDF suitable to be cut down to manual size ?
> For example, the GCC manual is cut to 7x9 inches. Most people don't
> like 8.5x11" books, and the "perfect" in perfect binding occurs
> because the books are cut after binding, which cleans up the book
> considerably. I usually custom format my books for the final print
> size, and add "trim marks", which are marks on the 8.5x11 page that
> show where to cut it.

Get hold of fineprint (www.fineprint.com) as a printer driver on
Windoze, and just print the 8.5 x 11 pages. Set fineprint to
output in booklet form on 8.5 x 11 sheets, which, especially with
a gutter (fineprint configuration) makes an ideal size printed
format. The printer driver takes care of the appropriate
reductions. Try it on something smaller for size.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR
Russell Whitaker
2004-09-16 00:21:15 UTC
Permalink
On Wed, 15 Sep 2004, CBFalconer wrote:

> Scott Moore wrote:
> >
> .. snip ...
> >
> > 2. Is the postscript or PDF suitable to be cut down to manual size ?
> > For example, the GCC manual is cut to 7x9 inches. Most people don't
> > like 8.5x11" books, and the "perfect" in perfect binding occurs
> > because the books are cut after binding, which cleans up the book
> > considerably. I usually custom format my books for the final print
> > size, and add "trim marks", which are marks on the 8.5x11 page that
> > show where to cut it.
>
> Get hold of fineprint (www.fineprint.com) as a printer driver on
> Windoze, and just print the 8.5 x 11 pages. Set fineprint to
> output in booklet form on 8.5 x 11 sheets, which, especially with
> a gutter (fineprint configuration) makes an ideal size printed
> format. The printer driver takes care of the appropriate
> reductions. Try it on something smaller for size.
>
For a while, instead of bound books, how about loose-leaf format with
printing on both sides of the paper? The object is to make it easier to
update individual pages until the documentation becomes nearly complete.

Russ
Frank Heckenbach
2004-09-16 02:56:30 UTC
Permalink
Scott Moore wrote:

> Ok, 550 pages. The following questions apply (for starters):
>
> 1. Is it too incomplete to print at this time ? Better to wait ?

Maybe better, but potential customers may tell ...

> 2. Is the postscript or PDF suitable to be cut down to manual size ?
> For example, the GCC manual is cut to 7x9 inches. Most people don't
> like 8.5x11" books, and the "perfect" in perfect binding occurs
> because the books are cut after binding, which cleans up the book
> considerably. I usually custom format my books for the final print
> size, and add "trim marks", which are marks on the 8.5x11 page that
> show where to cut it.

If you're building the manual yourself (`make gpc.ps' or `make
gpc.pdf' in the <build>/gcc directory; requires (pdf)tex and the
texinfo package), you can customize the paper size. Currently
p/Make-lang.in contains `@afourpaper' (once for PS and PDF each).
You could try replacing it with `@smallbook'. I haven't done this
myself; according to the texinfo manual, this makes a paper size of
7 by 9.25 inch. Or by `"@pagesizes height,width"' for a completely
custom size (text area, not paper size).

I don't think there's support for trim marks in texinfo, but it's
easy to add them to the PostScript file afterwards (probably also to
PDF, don't know myself).

> 3. What cover art ?

So far we have the "Gnu & Blaise Pascal" drawing by Markus
Gerwinski. Any objections to it?

> 4. Does FSF get funds from this (appears to be the standard arrangement
> for GNU prints) ?

I think it's common practice, but it's not an obligation.

> 6. What arrangements does GNU allow for printers of its material ?
> I.e., does the FSF/GNU have problems with people printing under their
> name ? What conditions ? Does FSF/GNU run its own bindery, or allow
> for-profit printers to create material ? Does FSF/GNU want express
> control of that ? etc.

The GPC manual is released under the GNU GPL (with the exception of
the copies of the licenses within the manual as well as the "GNU"
chapter which may not be modified), so these terms apply (for the
rest of the manual). Before you start seriously, you might want to
check the license yourself. The main points are:

- You can use it and distribute it, in whichever form, modified or
unmodified, for any price you are able to get.

- For program source code the GPL says if you distribute a binary,
you must make the sources available. In this case, this could
mean, if you distribute a printed version, you have to make the
texinfo sources available. This should not be a real problem,
since people can get them from our server anytime, but to be sure,
you might want to keep a copy of the exact version you print, to
be able to provide them on request (or put them on your web server
if you like). If you make substantial changes, you might want to
submit them back to us for future inclusion, though this is not
strictly required (unless and until a purchaser of a printed
manual demands those sources).

- You have to grant the same rights to the recipients. (E.g., you
cannot prohibit making photocopies of the printed manual.)

- You have to retain the list of authors and copyright and licensing
information, as given on the first few pages (and a few other
places in the manual).

(IANAL.)

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Scott Moore
2004-09-16 06:14:49 UTC
Permalink
Frank Heckenbach wrote:

>Scott Moore wrote:
>
>
>
>>Ok, 550 pages. The following questions apply (for starters):
>>
>>1. Is it too incomplete to print at this time ? Better to wait ?
>>
>>
>
>Maybe better, but potential customers may tell ...
>
>
Alright, the letters I have received to be on the side of waiting. That
is fine. The offer still goes
for later.

>
>
>>2. Is the postscript or PDF suitable to be cut down to manual size ?
>>For example, the GCC manual is cut to 7x9 inches. Most people don't
>>like 8.5x11" books, and the "perfect" in perfect binding occurs
>>because the books are cut after binding, which cleans up the book
>>considerably. I usually custom format my books for the final print
>>size, and add "trim marks", which are marks on the 8.5x11 page that
>>show where to cut it.
>>
>>
>
>If you're building the manual yourself (`make gpc.ps' or `make
>gpc.pdf' in the <build>/gcc directory; requires (pdf)tex and the
>texinfo package), you can customize the paper size. Currently
>p/Make-lang.in contains `@afourpaper' (once for PS and PDF each).
>You could try replacing it with `@smallbook'. I haven't done this
>myself; according to the texinfo manual, this makes a paper size of
>7 by 9.25 inch. Or by `"@pagesizes height,width"' for a completely
>custom size (text area, not paper size).
>
>
This is probally a trivial item. However, I should make it clear, at the
risk of offending
now (instead of later). If there is such work to be done, it should be
done by a GNU member.
I'm not offering my time, just the ability to create manuals. If you
guys want 8.5x11, or
some other size, thats fine. I brought it up principly because all GNU
manuals I have seen
are cut downs.

>I don't think there's support for trim marks in texinfo, but it's
>easy to add them to the PostScript file afterwards (probably also to
>PDF, don't know myself).
>
>
>
Sure, or I can work with measurements.

>>3. What cover art ?
>>
>>
>
>So far we have the "Gnu & Blaise Pascal" drawing by Markus
>Gerwinski. Any objections to it?
>
>
None, but if you are talking about the one that appears in the GPC
manual, it has no color.
Most GNU manuals are color covers. PS, if you want full bleed (color
runs to the edge),
it also needs to be a cut manual (less than 8.5x11).

>
>
>>4. Does FSF get funds from this (appears to be the standard arrangement
>>for GNU prints) ?
>>
>>
>
>I think it's common practice, but it's not an obligation.
>
>
>
>>6. What arrangements does GNU allow for printers of its material ?
>>I.e., does the FSF/GNU have problems with people printing under their
>>name ? What conditions ? Does FSF/GNU run its own bindery, or allow
>>for-profit printers to create material ? Does FSF/GNU want express
>>control of that ? etc.
>>
>>
>
>The GPC manual is released under the GNU GPL (with the exception of
>the copies of the licenses within the manual as well as the "GNU"
>chapter which may not be modified), so these terms apply (for the
>rest of the manual). Before you start seriously, you might want to
>check the license yourself. The main points are:
>
>- You can use it and distribute it, in whichever form, modified or
> unmodified, for any price you are able to get.
>
>
Yes, but that mainly applies to my producing "my brand" of the book. I'm
proposing to use
the standard GNU format and name. I.e., I don't really wish to do other
than be your binder.
I make that offer mainly because, whatever printing arrangements GNU/FSF
has, whether
done in house or contracted out, I am guessing that they are not going
to be thrilled to hear
that the GPC group wants to print a hundred or so manuals instead of the
1000's they are
used to.

>- For program source code the GPL says if you distribute a binary,
> you must make the sources available. In this case, this could
> mean, if you distribute a printed version, you have to make the
> texinfo sources available. This should not be a real problem,
> since people can get them from our server anytime, but to be sure,
> you might want to keep a copy of the exact version you print, to
> be able to provide them on request (or put them on your web server
> if you like). If you make substantial changes, you might want to
> submit them back to us for future inclusion, though this is not
> strictly required (unless and until a purchaser of a printed
> manual demands those sources).
>
>
As I went into above, this would pretty much be a GPC group produced
document.

>- You have to grant the same rights to the recipients. (E.g., you
> cannot prohibit making photocopies of the printed manual.)
>
>- You have to retain the list of authors and copyright and licensing
> information, as given on the first few pages (and a few other
> places in the manual).
>
>(IANAL.)
>
>Frank
>
>
>
So perhaps (if I have not offended you all to badly yet), we can talk
about this down the
line when the GPC manual is more complete, and perphaps the GPC group
can find
a volunteer to get a print-ready version together ?

--

Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Being right is more powerfull than large corporations or governments.
The right argument may not be pervasive, but the facts eventually are.
Frank Heckenbach
2004-09-20 03:07:58 UTC
Permalink
Scott Moore wrote:

> Frank Heckenbach wrote:
>
> >Scott Moore wrote:
> >
> >>2. Is the postscript or PDF suitable to be cut down to manual size ?
> >>For example, the GCC manual is cut to 7x9 inches. Most people don't
> >>like 8.5x11" books, and the "perfect" in perfect binding occurs
> >>because the books are cut after binding, which cleans up the book
> >>considerably. I usually custom format my books for the final print
> >>size, and add "trim marks", which are marks on the 8.5x11 page that
> >>show where to cut it.
> >
> >If you're building the manual yourself (`make gpc.ps' or `make
> >gpc.pdf' in the <build>/gcc directory; requires (pdf)tex and the
> >texinfo package), you can customize the paper size. Currently
> >p/Make-lang.in contains `@afourpaper' (once for PS and PDF each).
> >You could try replacing it with `@smallbook'. I haven't done this
> >myself; according to the texinfo manual, this makes a paper size of
> >7 by 9.25 inch. Or by `"@pagesizes height,width"' for a completely
> >custom size (text area, not paper size).
> >
> >
> This is probally a trivial item. However, I should make it clear, at the
> risk of offending
> now (instead of later). If there is such work to be done, it should be
> done by a GNU member.
> I'm not offering my time, just the ability to create manuals. If you
> guys want 8.5x11, or
> some other size, thats fine. I brought it up principly because all GNU
> manuals I have seen
> are cut downs.

In the next release, I'll introduce a variable `GPC_PAGESIZE', so
modifications (even if trivial) of the Makefile should no more be
necessary. Something like this should work then (after configuring
GPC):

cd gcc; make gpc.ps GPC_PAGESIZE=@smallbook

If there are any other things that should be "fixed" regarding the
printable version, you or someone else might want to tell me. Please
note that I almost exclusively use the info and html versions and
rarely look at the "printed" (PS/PDF) version myself, so I don't
know very well how nice or ugly it looks.

So then, hopefully, building the manual will be a simple matter of
getting a GPC release and running some configure/make command (which
can be automated in a script). If you set this up for yourself,
you'd have the advantage of being able to build the current manual
of each release whenever you want, not having to wait for someone to
make a smallbook format.

> >>3. What cover art ?
> >
> >So far we have the "Gnu & Blaise Pascal" drawing by Markus
> >Gerwinski. Any objections to it?
> >
> None, but if you are talking about the one that appears in the GPC
> manual, it has no color.
> Most GNU manuals are color covers. PS, if you want full bleed (color
> runs to the edge),
> it also needs to be a cut manual (less than 8.5x11).

Since Markus also reads the list AFAIK, he might want to comment on
it. I don't mind either way.

> >- You can use it and distribute it, in whichever form, modified or
> > unmodified, for any price you are able to get.
>
> Yes, but that mainly applies to my producing "my brand" of the book. I'm
> proposing to use
> the standard GNU format and name. I.e., I don't really wish to do other
> than be your binder.

No problem, AFAICS, whether or not you want to mention you name as
the printer/binder.

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
NEW! GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
Frank Heckenbach
2004-09-15 03:59:24 UTC
Permalink
John L. Ries wrote:

> It is unfortunate that the developers of GPC have to
> spend time writing code to flag case inconsistancy issues; we have only
> the dominance of C to blame for it.

Just to prevent a misunderstanding: The warning is not because of
any C compatibility issues. I added it intentionally because I
prefer to write in a case-consistent way and let the compiler help
me (the same goes for some others here, as we've seen, though there
are disagreements on how far the consistency should go).

Frank

--
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Continue reading on narkive:
Loading...