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

[Milan Zamazal]

>>>>> "RAO" == Richard A O'Keefe <ok at cs.otago.ac.nz> writes:

[Remarks about personal presentation and editor preferences omitted.]

    >> (defmodule sort
    >> (:export main))
		
    RAO> What happened to the arity?
	
    >> It's intentionally omitted as well as the type specification.  I
    >> think it's not a good idea to export only a certain part of the
    >> predicate definitions put under the same name.

    RAO> You are free to make that choice, but you are NOT free to call
    RAO> the result an alternative syntax for Mercury.  It is a lisp-ish
    RAO> syntax for a related but semantically different language.

That's no problem, since both the arity and types can be easily added to
the declaration.

    >> (define main (* *)
    >> (:types (io:state io:state)
    >> :modes ((di uo :det)))
	
    RAO> This strikes me as rather un-lispy.  Why not
	
    RAO> (define (main (W0 io:state) (W io:state))
	
    >> This is what I tried at the first attempt, but I've found it a
    >> bit unreadable.  The problem is that you must specify types for
    >> all the arguments in Mercury, and there are often many arguments
    >> in logic programming.

    RAO> So?  What's the problem?  Programmers in other languages have
    RAO> faced and solved this problem long ago.  If you have too many
    RAO> arguments to fit on one line, you switch to an alternative
    RAO> layout that puts one argument per line.

    RAO>     (define (foo
    RAO>               (t1)      ; comment
    RAO>               (t2)      ; comment
    RAO>               (t3))     ; comment

... which consumes a lot of lines, so you won't stop scrolling up and
down all the time.  Yes, I might dislike my notation with separated
variable names, types, and modes more, but we have to introduce it to
some extent anyway because of multiple modes.  Well, you say:
	
    RAO> Can we agree that there ought to be a fused syntax for the common case
    RAO> where there is a single mode?

    RAO>     (define (foo
    RAO>               (:in t1)    ; comment
    RAO>               (:in t2)    ; comment
    RAO>               (:out t3)   ; comment
    RAO>               :det)

I'd like it, but I haven't found any good idea how to deal with multiple
modes in such a notation.  I don't like the Mercury way of partial
"deuglification" in cases where it's possible.  I'd like to find a
consistent, elegant solution instead.
	
    RAO> If you want a Lispy syntax that clearly separates terms and lists,
    RAO> make terms follow the normal Lisp convention for functions, and make
    RAO> *lists* the things that are different.  E.g.,

    RAO>     (define (append (Xs (list T)) (Ys (list T)) (Zs (list T))
    RAO>               :mode (in in out det)
    RAO>               :mode (out out in non-det))
    RAO>       (case [Xs Zs]
    RAO>         ([[] []]              (true))
    RAO>         ([[A . As] [A . Cs]]  (append As Ys Cs))))

    RAO> The average Lisp programmer writes more function calls than
    RAO> data lists.

I tried to write it this way at the first attempt (it's obvious when
transcripting Mercury sources), but then I changed my mind.  The reason
is that *term* is the different thing.  Lisp already has got (a lot of)
lists notated in a very traditional way.  `define' and `case' are likely
to be Lisp macros, while `(true)' and `(append As Ys Cs)' are not
standard function nor macro nor special form calls in the Lisp sense.
Moreover, when it is a just plain term not corresponding to any call
(e.g. `ok(Result)'), then you would notate it as a list, while you would
introduce a different non-Lisp notation for lists.

    RAO> Well, no.  You can elide the 'and' in many cases, just as you
    RAO> can elide the 'progn' in many cases in Lisp.  In particular,
    RAO> the top level of a predicate definition, or a clause of a COND
    RAO> or CASE form.  You only need explicit 'and' inside 'or'.

[...]

    RAO> It is just too confusing to try to combine Lispy syntax and
    RAO> infix syntax.  (Take it from me; I've used Interlisp and I know
    RAO> these things (:-))

You're right.  When I was originally rewriting the `sort' example, I
didn't think about CASE and COND and the nested disjunctions looked very
bad.  If one starts using macros, there's no longer motivation to use
the infix separator.

    RAO> (Although I repeat that enough Prolog dialects have used "*"
    RAO> for an anonymous variable that I find these stars confusing.)

I see.
	
    RAO> The comma syntax is not arbitrary; it's Lisp (more precisely,
    RAO> Scheme, in my mind) backquote syntax without the backquote.

When you look at it that way, how would you use backquote then without
introducing a lot of confusion?  (I'd certainly like to use regular
backquote in the Lisp syntax.)

    RAO> The "?" notation is hardly Paul Graham's; IIRC it goes back at
    RAO> least as far as PLANNER and CONNIVER.  At any rate, it has been
    RAO> "conventional" Lisp notation for pattern variables for a long
    RAO> time.

But I still don't like it. :-)

    RAO> One final suggestion.  Others have embedded Prolog dialects in Lisp.
    RAO> The most notable was Alan Robinson's LogLisp.
    RAO> Dorai Sitaram's ScheLog has been quite popular:
    RAO> http://www.ccs.neu.edu/home/dorai/schelog/schelog.html
    RAO> Norvig's Prolog-In-Common-Lisp (compiles Prolog to Lisp) in his
    RAO> well-known book is also fairly popular.
    RAO> Then of course there's the old micro-PROLOG which used a paren-heavy
    RAO> syntax of its own.

    RAO> It might be well to look for ideas among those.

Thank you for the pointers.  I couldn't find anything syntactically
useful in the Norvig's book, but I'll try to look at the other pointers.
Nevertheless, I'm afraid the problem is that Mercury is much more
complex language than Prolog.  I mean number of operators, presence of
declarations (influencing higher-order calls), use of io__state, etc.
(ISO) Prolog itself wouldn't motivate me to look for another syntax, its
syntax is readable.

Milan Zamazal

-- 
SomeProgrammersLikeWritingLikeThis.However,IDontThinkThisFormOfCommunicationIs\
AGoodIdea.IApologizeToAllWhoCantReadMyTextsWrittenInATraditionalStyle.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------