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@ncifcrf.gov permanent email: toms@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.
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 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
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@umich.edu
Thank you.
HF
----- Original Message ----- From: Frank Heckenbach To: gpc@gnu.de Sent: Saturday, September 11, 2004 1:15 AM Subject: Re: Upper/lower case in identifiers
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 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
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
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
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 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.
- 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)?
- 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).
- 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
- 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 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 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
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
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 | -------------------------
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.
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.
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
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.
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
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
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 | -------------------------
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.
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:
- 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 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:
- 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.
Scott Moore wrote:
... snip ...
- 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.
On Wed, 15 Sep 2004, CBFalconer wrote:
Scott Moore wrote:
.. snip ...
- 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
Scott Moore wrote:
Ok, 550 pages. The following questions apply (for starters):
- Is it too incomplete to print at this time ? Better to wait ?
Maybe better, but potential customers may tell ...
- 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).
- What cover art ?
So far we have the "Gnu & Blaise Pascal" drawing by Markus Gerwinski. Any objections to it?
- 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.
- 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 wrote:
Scott Moore wrote:
Ok, 550 pages. The following questions apply (for starters):
- 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.
- 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.
- 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).
- 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.
- 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 ?
Scott Moore wrote:
Frank Heckenbach wrote:
Scott Moore wrote:
- 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.
- 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
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
-
Adriaan van Os -
CBFalconer -
Frank Heckenbach -
Grant Jacobs -
John L. Ries -
Peter N Lewis -
Prof. Harley Flanders -
Russell Whitaker -
Scott Moore -
Tom Schneider -
Tom Verhoeff -
Waldek Hebisch