[m-dev.] Partially instantiated data structures

Charlie McGee c4cypher at gmail.com
Fri Oct 5 23:18:01 AEST 2018


>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?

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20181005/e19d32a1/attachment.html>


More information about the developers mailing list