<div dir="ltr">>I'm trying to learn Mercury, and I ran into some problems that I believe are because of partially<div>>instantiated data structures, which are currently unimplemented:<br>> <a href="http://mercurylang.org/information/doc-release/mercury_faq/Unimplemented.html#Unimplemented" rel="noreferrer" target="_blank">http://mercurylang.org/information/doc-release/mercury_faq/Unimplemented.html#Unimplemented</a><br><br>>Is this functionality being worked on?  If so, what's the status?  If not,<br>>why not?  (Would it require extensive changes to existing systems?  Is it<br></div><div>>considered unimportant?  Is it intrinsically difficult?)  How much effort</div><div>>would it likely be to implement?</div><div><br></div><div>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.  <br></div><div><br></div><div>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.  </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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). ).  </div><div><br></div><div>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 <i>aren't</i> pure and sound (unless you twist it's arm with pragmas).</div><div><br></div><div><br></div></div>