Prolog - List cons functor (was Re: The meaning of module overriding syntax

Author

List cons functor (was Re: The meaning of module overriding syntax

Joachim Schimpf

2005-02-28, 3:59 pm

Brian Hulley wrote:
> ...
> Of course, there is no special reason why the :/2 operator has to be
> used, and in fact I was wondering whether it might at some point be
> possible to resurrect the humble full stop ( :-)) from its current
> oblivion as the list cons functor (which doesn't need such a nice
> symbol since it already has the [] notation),
> ...

That would be such a good move. In fact, recent versions of Mercury
have changed the list functor to '[|]'/2, which I like because it is
similar to the convention that {...} is parsed as '{}'(...).

I'm quite inclined to make this same change for ECLiPSe, but so far
we were afraid to break with tradition...

--
Joachim Schimpf / phone: +44 20 7594 8187
IC-Parc / mailto:J.Schimpf@imperial.ac.uk
Imperial College London / http://www.icparc.ic.ac.uk/eclipse

Bart Demoen

2005-02-28, 8:59 pm

Joachim Schimpf wrote:

> That would be such a good move. In fact, recent versions of Mercury
> have changed the list functor to '[|]'/2, which I like because it is
> similar to the convention that {...} is parsed as '{}'(...).
>
> I'm quite inclined to make this same change for ECLiPSe, but so far
> we were afraid to break with tradition...

I took the Mercury parser for my Prolog system hProlog and inherited
that (to me) very weird change from ./2 to '[|]'/2 convention -
knowingly: I made sure that ./2 is also still recognized as the list
constructor. I would consider code that relies on it (or any other
convention) just plain bad code - unless it is in the parser/compiler
of a Prolog system.

So I do not understand this change in Mercury neither anybody's
obsession with the latest brand of the list constructor: any convention
seems ok and harmless enough not to want to change it. So I would be
glad if someone could explain the real benefits.

Thanks

Bart Demoen

Joachim Schimpf

2005-03-01, 3:59 pm

Brian Hulley wrote:
> But it is not what convention you use for the *list* constructor that
> is important: what is important is that the full stop is a really
> really really great symbol and it is totally wasted if it is just used
> for some obscure theoretical pretend list constructor when everyone
> uses the bracket notation.

The fact that ./2 is the list constructor _does_not_ actually stop
you from using it as an infix operator! NU-Prolog had it predefined
as :- op(600, xfy, .) and most Prolog systems will allow you to do
that yourself if you want to.

Once you've done that, you can write lists like a.b.c.[]
No changes in the parser are needed, you just have to be careful
1. not to put blank space after a dot (because that will make it an
end-of-term fullstop)
2. to watch out for the conflict with the decimal point in floating
point numbers: 1.2.3.4 will most likely be parsed as [1.2|3.4]

The other issue is that ./2 is usually a built-in predicate, equivalent
to compile/1 or consult/1. This is what allows you to write ['file.pl'].
Some Prologs will allow you to redefine this as well. E.g. in ECLiPSe
nobody stops you from redefining ./2 as an alias for :/2 as follows:

:- local op(600, xfy, .). % declare it infix
:- local '.'/2. % hide the built-in ./2

Module.Goal :- Module:Goal. % define your own

So, while the different uses of ./2 can in principle coexist happily,
such overuse of a notation can make error detection more difficult.
Also, you may find it annoying that write/1 will insist on printing
your Module.Goal terms as [Module|Goal]. It is only for those minor
reasons that I'd consider renaming the list functor a good idea.

--
Joachim Schimpf / phone: +44 20 7594 8187
IC-Parc / mailto:J.Schimpf@imperial.ac.uk
Imperial College London / http://www.icparc.ic.ac.uk/eclipse

Bart Demoen

2005-03-02, 8:58 pm

rafe@cs.mu.oz.au wrote:

> The main reason, IIRC, was that we wanted to use infix `.' as a
> module name separator.

That raises the question: why was the old module name separator not
good enough - or, so bad that it needed changing - or what was so more
attractive to . instead of the old one so that a change was needed ...

Not that I care a . about which is the list constructor: it shows up in
about 3 places in a reasonable language implementation and it should
show up in zero user programs. But why CHANGE ?

> Which we have been for a while now.

"We" ... twice ...
oh Ralph, are you outing now as a Mercury guy ?
I thought you were a HAL guy in the first place !

:-)

Cheers

Bart Demoen

Joachim Schimpf

2005-03-03, 3:58 pm

Bart Demoen wrote:
> Not that I care a . about which is the list constructor: it shows up in
> about 3 places in a reasonable language implementation and it should
> show up in zero user programs. But why CHANGE ?

I would have thought Brian Hulley already answered this very clearly:

> But it is not what convention you use for the *list* constructor that
> is important: what is important is that the full stop is a really
> really really great symbol and it is totally wasted if it is just used
> for some obscure theoretical pretend list constructor when everyone
> uses the bracket notation.

I.e. you can't use nice (infix) dots in user programs without
accidentally writing lists (usually improper ones).

--
Joachim Schimpf / phone: +44 20 7594 8187
IC-Parc / mailto:J.Schimpf@imperial.ac.uk
Imperial College London / http://www.icparc.ic.ac.uk/eclipse

Bart Demoen

2005-03-03, 8:57 pm

Joachim Schimpf wrote:

> I.e. you can't use nice (infix) dots in user programs without
> accidentally writing lists (usually improper ones).

What is so nice about the dot ? It is the most invisible of all
characters except for white space. I have always been happy that Prolog
only wanted the . for the end of clause (or term) (*) so that I was
never forced to use a . in any other context.

But it is good to know that all this is just a matter of taste - nothing
really fundamental or pressing and this just makes me repeat my
rethorical question: why CHANGE ?

Cheers

Bart Demoen

(*) and also forced upon us by strange syntax for floats: we'd use
rather a , for separating what comes before the comma and what comes
after :-)

Sponsored Links