[mercury-users] Re: Lisp-like syntax for Mercury (Mercury & macros)

[Richard A. O'Keefe]

schachte at cs.mu.OZ.AU (Peter Schachte) replied:
	> I don't want, don't use, and therefore in my editor, don't have
	> font-lock.  So no problem.  However, term movement gets 0'a and 'xxx'
	> perfectly correct, not hard at all.
	
	I have to disagree here.  Travarsing terms *backwards* is difficult
	due in part to single quotes.  For example, if you see on the last
	line of a term:
	
		X = 0' .
	
	You can't tell whether the previous line (or some line further back)
	has an unbalanced single quote, maybe looking like:
	
		Y = ',
	
	which binds Y to the atom ',\n\tX = 0'.

When backslash escapes were added to QP, unescaped newlines in strings
are forbidden.  That means you only have to worry about single quotes
on the current line.

But the real secret is "in order to move backwards, tokenise FORWARDS".
I don't know _any_ programming language where something nasty like this
doesn't occur.  For each of them there are ad hoc solutions.  Given a
layout style in which only "top level forms" start in column 1, then
moving backwards to the beginning of the current top level form, then
tokenising *FORWARDS*, then moving back over the appropriate number of
tokens, works better for most languages.  (I do not except Lisp here.)

	I haven't found one I'm happy with, either, including the one I wrote.
	But I still find them better than doing all the layout myself.

Newline at same indentation: <LF>.
Increase indentation: <ESC><Ctrl-I>
Decrease indentation: <ESC><Ctrl-U>

Given these keys, I find getting the indentation right manually
is practically effortless; certainly far less effort than to be
constantly fixing up Emacs' efforts.

You can only really get indentation right by knowing the full context.
Prolog's portray_clause/1 is in a position to do this.
Emacs is not.
Even with the "find beginning of definition and parse from there" trick,
Prolog layout can depend on what the NEXT token is (as can good indentation
for C).

Alpha's auto-layout for C is *almost* tolerable, but any time an
editor moves a token I've just placed without me telling it to is jarring.
I find that 
	
	And I
	look back on Xerox Lisp's SEdit structure editor with increasing
	nostalgia and impatience for such a beast to appear again, but able to
	handle languages with a more complex syntax than Lisp's.

Well, I look back on the Xerox lisp machines with increasing nostalgia
for many reasons.  SEdit wasn't, I must admit, one of them.  I did all
the Lisp editing I could in the same editor I use for Prolog.

There was a vogue for language-sensitive editors.  What happened to them?

The nearest experience to Xerox Lisp machines that I've found of recent
years is Squeak Smalltalk.  It might be quite interesting for someone to
try to build a language-sensitive editor in that.  (Squeak handles
pretty-printing by waiting for you to enter valid code, parsing it, and
generating the layout from the compiler's parse tree.)

	To me, laying out my source code is about as interesting as laying out
	paragraphs like this one:  I just can't see why I should spend any
	time, effort, or attention on it.
	
I find that the effort disappears from consciousness.  It certainly
doesn't slow me down.

	> However, '.' followed by white space is
	> end of clause, '.' followed by anything else isn't.
	
	Not true:
	
		  X =  0'.
		, Y = '0'.
	
	is a single Prolog term, not two.
	
Remember, the trick is to parse FORWARDS.
Start at the beginning of the line, and you see
(X) (=) (0'.)
(,) (Y) (=) ('0') (.<newline>)
No ambiguities.  No problems.

	Of all the possible characters that could have been chosen as a radix
	mark, using a single quote seems like one of the worst possibilities.
	
I've come to appreciate Lisp's #\<char> syntax, except that it doesn't
work in strings.  My preferred syntax for characters would have been
`<char>`.

However, ' as radix character is entirely harmless as long 
as you remember to tokenise FORWARDS even when moving BACKWARDS.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------