21 Dec 2003 23:12:44 -0500

Related articles |
---|

Layout syntax haberg@matematik.su.se (2003-12-03) |

Re: Layout syntax joachim.durchholz@web.de (Joachim Durchholz) (2003-12-08) |

Re: Layout syntax haberg@matematik.su.se (2003-12-13) |

Re: Layout syntax cdc@maxnet.co.nz (Carl Cerecke) (2003-12-13) |

Re: Layout syntax joachim.durchholz@web.de (Joachim Durchholz) (2003-12-14) |

Re: Layout syntax haberg@matematik.su.se (2003-12-20) |

Re: Layout syntax joachim.durchholz@web.de (Joachim Durchholz) (2003-12-21) |

Re: Layout syntax haberg@matematik.su.se (2003-12-23) |

Re: Layout syntax joachim.durchholz@web.de (Joachim Durchholz) (2003-12-27) |

Re: Layout syntax haberg@matematik.su.se (2004-01-02) |

Re: Layout syntax joachim.durchholz@web.de (Joachim Durchholz) (2004-01-07) |

Re: Layout syntax haberg@matematik.su.se (2004-01-09) |

Re: Layout syntax joachim.durchholz@web.de (Joachim Durchholz) (2004-01-12) |

[7 later articles] |

From: | Joachim Durchholz <joachim.durchholz@web.de> |

Newsgroups: | comp.compilers |

Date: | 21 Dec 2003 23:12:44 -0500 |

Organization: | Oberberg Online Infosysteme |

References: | 03-12-016 03-12-060 03-12-081 03-12-104 03-12-112 |

Keywords: | syntax |

Posted-Date: | 21 Dec 2003 23:12:44 EST |

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

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.