Re: Layout syntax

Hans Aberg wrote:
> <joachim.durchholz@web.de> wrote:
>
>>>>This is probably because most mathematical objects don't have much of
>>>>a nested structure.
>>>
>>>Quite on the contrary, pure math has a lot of nested structures, even
>>>though perhaps not so much in formulas.
>>
>>Oops - right, mathematical objects tend to be nested, and deeply so.
>
> I am not sure how deeply nested they are: I want to make a system that (in
> principle) is OK to the working mathematician. Part of the fascination
> with working with it, is to figure out what this means in practise.


Mathematical nesting can go to the same sort of depth as computerized
ones (and they tend to go a bit farther since abstraction has zero
cost in mathematics, but nonzero cost in computers). For example, a
matrix of real numbers consists of real numbers, each of which
consists of an infinite sequence of ever-shrinking intervals of
rational numbers, each of which consists of two natural
numbers. Tensors can be defined as matrices of matrices. Things are
getting quite deeply nested.


In practice, mathematicians don't usually go much farther than two or
three nesting levels. At that point, you usually hit whatever objects
are considered primitive in the currently interesting theory. In this
sense, mathematical objects indeed "don't have much of a structure" -
the structure is there, but it isn't prevalent in the thinking
process, and hence doesn't need to be expressed well in the notations
used.


In other words, mathematical objects are deeply nested, but
mathematical formulae usually aren't. Actually, I'm hard pressed to
remember having ever seen a mathematical formula that had more than
three nesting levels.


>>>>That's also why I think that mathematical tradition isn't a source
>>>>of inspiration for questions in this specific area.
>>>
>>>I write on a proof-verification system, which is the reason it is a source
>>>of inspiration to me. :-)
>>
>>I'm pretty sure that it's more semantic than syntactic inspiration.
>
> Actually, there is a intricate interplay between syntax and semantics
> (or notation and notions).


[Interesting exposition on syntax problems for doing mathematics on a
computer snipped.]


  > So if I try to implement a syntax that easily parsable to me, then I
  > end up having to wrestle with such grammar implementation problems. In
  > the other variation, where one simply introduces a more computer like
  > syntax, then it quickly becomes very difficult for me to parse the
  > mathematics of the code, and so I cannot detect whether the
  > implementation is strictly mathematically rigorous.


That's exactly my point: mathematical syntax, designed for consumption
by humans, isn't easily transferable to computer language syntax,
designed for consumption by computers. In other words, drawing
syntactical inspiration from actual mathematical usage may be helpful,
but sooner or later one is going to run into trouble. Which is just
my point: mathematics isn't the best source of inspiration when it
comes to syntax. (It's an excellent source of inspiration when
considering semantics! At least if a precise semantics is desired.)


>>>I agree that if one should use an indentation system, then one
>>>should probably avoid a tab-to-space conversion, or make it
>>>explicit in the file.
>>How would "making it explicit" work?
>
> My idea was merely that one should be able to write "tabs = 4 spaces"
> or something.
>
>
>>I'm a bit sceptical that this would interact well with editors, but I
>>might have overlooked something, so I'm interested in what you have
>>in mind.
>
> This certainly will screw up the look in any editors that cannot parse
> it, but it will ensure that files are correctly handled when read by
> the compiler, which is more important.


Hmm... both is important.
Correct handling by compilers is important to get the thing compiled,
but correct handling by editors is important for maintenance. And in
my experience, maintenance has taken up more time and effort than
initial write-up, so easing maintenance is quite high on my priority
list.


> Also, layout syntax becomes even more complicated in Unicode, which has
> spaces of different width, "EN SPACE", "EM SPACE", etc.


I don't think that this is very different from the space-tab
problem. A programming language that uses indentation syntax should
state an explicit policy about handling alternate forms of whitespace.
There are various design constraints, with trade-offs between them, in
no particular order:


* KISS
* not restricting the user more than necessary
* invariance under typical transformations by editors
* reliable detection when an editor transformation altered the semantics
* invariance under source file concatenation
* easily understood error messages


(Did I forget a design constraint?)


Regards,
Jo

Return to the comp.compilers page.
Search the comp.compilers archives again.