Re: Bison function argument style

[Hans Aberg]

At 13:04 -0800 2002/11/19, Paul Hilfinger wrote:
>> Another funny thing with computer code is that older books often use
>> variable width fonts.
>
>Yes they do, and I often found it difficult to read; it's a little
>tricky to do right.  Xerox PARC technical reports from the 1970's used
>variable-width fonts and italics, and program text in them looks just
>awful (they didn't know about kerning).  Perhaps the move to
>monospacing was in reaction.

I thought monospace fonts were used in order to facilitate tabular styles,
as it is hard to achieve alignments in variable width fonts. -- That is the
reason I used it anyway.

>  Certainly, I have a hard time dealing
>with variable-width fonts in typical program editors.  This is in
>large part, I suspect, because of the lower resolution of displays vs.
>paper. This again might be a reason for the move to monospacing.

If the code somehow relies on achieving certain alignments, then monospace
will be necessary. But otherwise, one can probably use any type of font:

When I look into say Aho, Sethi & Ullman, "Compilers...", it uses monospace
for computer code, but normal typesetting for algorithms, and I do not see
any disadvantages with the latter.

So it probably hinges much on what one is used to, if there are no specific
goals one must achieve, such alignments. (In C/C++ code, I use an editor
that can produce styled text markups, which I find helpful. But I can still
read unmarked code in say books.)

>> > and vanishingly few function applications
>> >spread over more than one line in mathematical text.
>>
>> You have never seen any more complicated math formulas then? :-)
>
>Complicated FORMULAE, yes, plenty of those.  Complicated FUNCTION
>APPLICATIONS, many fewer.  When a function application gets that big,
>one usually introduces some auxiliary notation to condense the arguments.

The main point is that the principle for typesetting complicated formulas
is not achieved by inserting extra spaces, but to break it up properly.

So the extra space "f (x)" is wrong from this point of view -- and the
style does not say "use this extra space if the argument is complicated".

>> My own little investigations of typical math syntaxes suggest that they are
>> a great deal more sophisticated than what one has bothered to use in
>> computer languages. It is possible to do computer language syntaxes that
>> are much better by comparing to math syntax usage.
>
>For the opposite point of view (i.e., mathematicians have a lot to
>learn about notation for computer scientists), see the works of Edsger
>Dijkstra and some of his followers, such as
>
>  A. J. M. van Gasteren: On the Shape of Mathematical Arguments. Springer 1990

Do you have an electronic version? Or some examples?

Returning to GNU and styles, I think that if one wants code to be written
according a specific style, then one should have a tool able to do the
formatting. In math, that corresponds to the use of a macro based language
like TeX, which can ensure a consistent typesetting.

>I think Leslie Lamport has had something to say about proof, at least,
>and possibly notation.

I have hanged around the LaTeX3 development list for about a decade or so.
One thing I can notice with newbies approaching math typesetting is that
they have a lot of ideas on how to formalize it in ways which will never be
generally accepted by mathematicians. The reason is that math notation is
dictated by bringing out complicated logical structures, and there is no
easy way around that.

By contrast, the components of computer code has so far been built up
around rather simple logical structures, so perhaps that allows more room
for these styling dogmas. But as computer programs become better at
describing complicated logical structures, I think they may close into an
approach more similar to math in terms of syntaxes.

For example, computer languages which admits dynamic grammars haven't
caught on in the past, and I think the reason might be that there was no
great need for it in view of the simple logical structures one in actuality
programs around. But for a program that would be convenient to express
typical math, I think that would be insufficient:

I started to write on a version of Prolog based on metalogics instead of
logics (like in Mendelson, "Introduction to Mathematical Logic". The "B :-
A" of Prolog is interpreted as metalogic provability "A |- B", and the idea
to hook it up so that one cannot pass unproved results as proved; so I call
it a metalogic "inference" program, as opposed to programming languages
that do not have this restriction of accuracy. The style is declarative
according to metalogic.

What I do right now is to classify multicomponent operators with
priorities. -- It turns out that it is easy to pretty print those grammars.
(For single component operators, this is easy, but I want say "f(x)" to be
viewed as a binary operator with an infix "(" and a suffix ")", etc.)

Then this should somehow be merged into the metalogic inference program so
that math syntaxes can be expressed more freely.

  Hans Aberg