[m-dev.] Adding Loops to Mercury
pschachte at gmail.com
Mon Jan 6 12:37:02 AEDT 2014
The big problem, as observed earlier, is the lack of support for
constructor classes. That means we can't allow people to define
sequence_empty and sequence_next for their own types, so this would be
limited to lists. But more importantly, we couldn't overload them to
handle lockstep iteration, filtering, and folding, at least not the same
way I did for Prolog. If you can't handle them, there's not much point.
As for modes, I assumed they'd be:
:- mode sequence_empty(in).
:- mode sequence_empty(out).
:- mode sequence_next(in, out, out).
:- mode sequence_next(out, in, in).
I don't think uniqueness is very important for this. I mean, how often
do you actually use unique lists in your Mercury code?
On 05/01/14 10:52, Mark Brown wrote:
> On Fri, Jan 3, 2014 at 10:49 AM, Peter Schachte <pschachte at gmail.com> wrote:
>> As for the semantics, a generalisation of Mercury's 'all' construct that can
>> generate output would fit well with Mercury. Here's a paper I wrote a
>> decade ago doing this for Prolog. At the time, Fergus Henderson told me
>> there was some shortcoming in Mercury's type or mode system that would make
>> this difficult to do for Mercury, but I don't remember the specifics.
> Mercury's modes can't describe the aliasing in sequence_next/3 that is
> used to thread the accumulator values through the loop.
> Incidentally, how would you describe the mode of sequence_next/3 in this case?
> developers mailing list
> developers at lists.mercurylang.org
Peter Schachte Politics, n. A strife of interests
University of Melbourne masquerading as a contest of principles.
schachte at unimelb.edu.au The conduct of public affairs for private
www.cs.mu.oz.au/~schachte/ advantage. -- Ambrose Bierce, 1906 (The
Phone: +61 3 8344 1338 Devil's Dictionary)
I support the NTEU's campaign for a fair enterprise agreement.
Find out more: nteu.org.au/melb | facebook.com/nteu.unimelb
More information about the developers