[m-dev.] Partially instantiated data structures

[Matthew Ewer]

I'm trying to learn Mercury, and I ran into some problems that I believe
are because of partially instantiated data structures, which are currently
unimplemented:
http://mercurylang.org/information/doc-release/mercury_faq/Unimplemented.html#Unimplemented

Is this functionality being worked on? If so, what's the status? If not,
why not? (Would it require extensive changes to existing systems? Is it
considered unimportant? Is it intrinsically difficult?) How much effort
would it likely be to implement?

Thanks,
Matthew

[Julien Fischer]

Hi Matthew,

Post by Matthew Ewer
I'm trying to learn Mercury, and I ran into some problems that I
believe are because of partially instantiated data structures, which
http://mercurylang.org/information/doc-release/mercury_faq/Unimplemented.html#Unimplemented
Is this functionality being worked on? 

Not at the moment. It has been in the past, but those efforts are
either too incomplete or do not perform well enough to be useful.

Post by Matthew Ewer
If not, why not?  

It would be a large undertaking (see below). Also, the Mercury
developers are currently working on other things.

Post by Matthew Ewer
(Would it require extensive changes to existing systems? 

Yes, it would require implementing a new mode analyser. Since mode
analysis is by far the most complicated part of the Mercury compiler
*and* the part which affects almost every other part of thee copmiler,
doing this will be a substantial undertaking.

Post by Matthew Ewer
Is it considered unimportant? 

In my opinion, partial instantiation (in Mercury) is unimportant. On
the list of language features that I would like to see implemented
it's pretty far down. Other opinions may differ of course ;-)

Post by Matthew Ewer
Is it intrinsically difficult?)  
How much effort would it likely be to implement?

Lots :-(

Cheers,
Julien.

[Charlie McGee]

Post by Matthew Ewer
I'm trying to learn Mercury, and I ran into some problems that I believe

are because of partially
http://mercurylang.org/information/doc-release/mercury_faq/Unimplemented.html#Unimplemented

Post by Matthew Ewer
Is this functionality being worked on? If so, what's the status? If not,
why not? (Would it require extensive changes to existing systems? Is it
considered unimportant? Is it intrinsically difficult?) How much effort
would it likely be to implement?

I'm not a dev, and in many ways I'm a newbie to Mercury myself in terms of
experience. I hope sharing what I know and understand of the language
helps.

Mercury can be a bit of an odd beast, given that the syntax is like Prolog,
and the semantics are similar but the direction that Mercury approaches
Prolog's semantics are strict, static and as functionally pure as
possible.

I get the impression that the reason that partial instantiation got left by
the wayside as a language feature is that, with the Mercury approach, by
the time the compiler is done with a predicate, nothing should be left
unbound, one way or another. It's a bit difficult to explain, but 'no
partial instantiation' doesn't mean that you MUST ALWAYS completely ground
a variable with one simple constructor, but when calling a constructor in
order to unify a variable, the compiler must be able to infer a complete
variable binding with the rules and goals available.

Mercury implements a huge number of language features (many of which can be
frustrating to learn and understand, to speak from personal experience,
existential typing, typeclasses and the like) that allows you to define a
logic program in terms that never leave variables unbound when all is said
and done.

Instead of having to rely on genuine partial instantiation (pred
badlist(list(T)::out) is erroneous. badlist(Partial) :- Partial = [ foo | _
].) trust the compiler to properly instantiate your variables through goal
inference (pred goodlist(T::in, list(T)::out) is det. goodlist(BarInit,
GoodList) :- Goodlist = [ foo | Bar], somegoal(BarInit, Bar). ).

Remember that Mercury isn't Prolog, Mercury is Prolog's anally retentive
younger cousin. Mercury doesn't just want your programs to be functionally
pure and logically sound in ways that Prolog only pretends to be capable
of, MMC will slap you wit a wet cod if they *aren't* pure and sound (unless
you twist it's arm with pragmas).

[Mark Brown]

Hi,

Post by Charlie McGee
I get the impression that the reason that partial instantiation got
left by the wayside as a language feature is that, with the Mercury
approach, by the time the compiler is done with a predicate,
nothing should be left unbound, one way or another.

The reasons Julien just gave were:
- It would be a large undertaking.
- The Mercury developers are currently working on other things.
- In his opinion (which I share) it is unimportant in Mercury,
relative to other features.

The impression you got doesn't resemble very much what was actually said ;-)

Post by Charlie McGee
Remember that Mercury isn't Prolog, Mercury is Prolog's anally
retentive younger cousin. Mercury doesn't just want your programs
to be functionally pure and logically sound in ways that Prolog only
pretends to be capable of, MMC will slap you wit a wet cod if they
aren't pure and sound (unless you twist it's arm with pragmas).

I don't see that anything impure or unsound has been requested here.

(And do you really interpret compiler error messages pointing out an
inconsistency in what you've written as some sort of personal slight?
If so, I hope I never have to review any of your code!)

Mark

[Zoltan Somogyi]

Post by Mark Brown
Hi,

Post by Charlie McGee
I get the impression that the reason that partial instantiation got
left by the wayside as a language feature is that, with the Mercury
approach, by the time the compiler is done with a predicate,
nothing should be left unbound, one way or another.

- It would be a large undertaking.
- The Mercury developers are currently working on other things.
- In his opinion (which I share) it is unimportant in Mercury,
relative to other features.
The impression you got doesn't resemble very much what was actually said ;-)

My impression is that Charlie was trying to explain part of your third point:
i.e. the *reason* why we don't consider it a high priority to work on.

Post by Mark Brown

Post by Charlie McGee
Remember that Mercury isn't Prolog, Mercury is Prolog's anally
retentive younger cousin. Mercury doesn't just want your programs
to be functionally pure and logically sound in ways that Prolog only
pretends to be capable of, MMC will slap you wit a wet cod if they
aren't pure and sound (unless you twist it's arm with pragmas).

I don't see that anything impure or unsound has been requested here.
(And do you really interpret compiler error messages pointing out an
inconsistency in what you've written as some sort of personal slight?

I read Charlie's words as being a humorous take on the difference
between Prolog and Mercury. Granted, different people can find
very different things funny, especially at 3am :-)

Zoltan.

[Mark Brown]

Hi,

Post by Zoltan Somogyi

Post by Mark Brown
(And do you really interpret compiler error messages pointing out an
inconsistency in what you've written as some sort of personal slight?

I read Charlie's words as being a humorous take on the difference
between Prolog and Mercury. Granted, different people can find
very different things funny, especially at 3am :-)

What do you mean humorous? I actually do slap people with a wet cod
when I review their code.

Mark

[Matthew Ewer]

Sounds like the answer is, "not being worked on, for all of the reasons."
Ah, well. Perhaps later, after I've learned more Mercury, I'll either
understand why it's not necessary or argue more vociferously for it, haha.

Thanks,
Matthew

Post by Mark Brown
Hi,

Post by Zoltan Somogyi

Post by Mark Brown
(And do you really interpret compiler error messages pointing out an
inconsistency in what you've written as some sort of personal slight?

I read Charlie's words as being a humorous take on the difference
between Prolog and Mercury. Granted, different people can find
very different things funny, especially at 3am :-)

What do you mean humorous? I actually do slap people with a wet cod
when I review their code.
Mark
_______________________________________________
developers mailing list
https://lists.mercurylang.org/listinfo/developers

[Mark Brown]

Hi,

Sounds like the answer is, "not being worked on, for all of the reasons." Ah, well.
Perhaps later, after I've learned more Mercury, I'll either understand why it's not
necessary or argue more vociferously for it, haha.

By all means :-)

All of the things currently being worked on are, I believe, being
driven by real world use cases. So I'd suggest that providing use
cases would be a good way to argue for the feature.

Mark

[Charlie McGee]

Post by Mark Brown

Post by Mark Brown
- In his opinion (which I share) it is unimportant in Mercury,

relative to other features.

Post by Mark Brown
The impression you got doesn't resemble very much what was actually

said ;-)

Post by Mark Brown
My impression is that Charlie was trying to explain part of your third
i.e. the *reason* why we don't consider it a high priority to work on.

Exactly this, or at least my attempts to explain as such. I didn't mean to
speak for anybody else, I just have a tendency to ramble.

Post by Mark Brown

Post by Mark Brown
I don't see that anything impure or unsound has been requested here.

My lack of academic background may be biting me here, but in a general (not
mercury specific) sense, isn't a logic program with that has ungrounded
variables in it's extensional database (left hand side :-) unsound? I know
I'm probably futzing my semantics here, but I know the MMC pitches a fit if
it can't properly ground all the terms in a data constructor.

Post by Mark Brown

Post by Mark Brown
(And do you really interpret compiler error messages pointing out an
inconsistency in what you've written as some sort of personal slight?

I read Charlie's words as being a humorous take on the difference
between Prolog and Mercury. Granted, different people can find
very different things funny, especially at 3am :-)

It's a personal failing of mine. It's less that I see the compiler as
antagonistic so much as the chiding of a master teaching a student. I may
grouse about the way the compiler has to say, but I'm very grateful for the
help it provides. It's irrational to anthropomorphize the equipment, but
my sense of humor helps me greatly when my attempts to debug my own code
grow tiring. ^_^

[Zoltan Somogyi]

Post by Charlie McGee
My lack of academic background may be biting me here, but in a general (not
mercury specific) sense, isn't a logic program with that has ungrounded
variables in it's extensional database (left hand side :-) unsound?

Negating a goal that contains unbound variables is unsound if (and only if)
the execution of that goal binds any of those variables.

Executing non-negated goals containing variables is (or at least can be) sound,
though this soundness is wrt a logic that is more complicated than the logic
that applies to goals that contain no variables.

Post by Charlie McGee
I know
I'm probably futzing my semantics here, but I know the MMC pitches a fit if
it can't properly ground all the terms in a data constructor.

Some of the error messages that mmc generates for nonground data
are required by theory for the preservation of soundness, but some others
are caused only by limitations in the compiler. The main limitation is that
at present, it cannot keep track of the relationship between different
occurrences of the same variable. This means that if some goal binds X,
it does not know that all the *other* occurrences of X, in other goals
or even in the same goal, have also become bound. To avoid the problems
that this could cause, the compiler rejects such code, even though the
unsoundness is in the compiler, not (necessarily) in the code.
The post that triggered this thread was asking about the lifting
of this limitation.

Zoltan.