[m-dev.] collect

[Erwan Jahier]

Fergus wrote:
| > 1) Opium-M command language is nothing more than Prolog + 2 primitives that
| > manipulate the trace (current/1 and fget/1), which is not such a big step for
| > Mercury programmers.
| 
| Well, I'm not so sure about that.  Prolog has lots of stuff like cut,
| repeat-fail loops, side effecting I/O, etc. which will be new to
| Mercury programmers who don't know Prolog.

I'm pretty sure that most users will easily get used to side effects I/O ;o)

| And fget/1 uses side effects, and failure-driven loops seem to be a
| commonly used paradigm in Opium-M code, so they really can't just
| ignore these things.

I don't think failure-driven loops are (and should be) commonly used in Opium-M
code. On the other hand, we think that failure-driven loops can be very usefull
at the Opium-M prompt when you type in queries; they let you specify very
easily quite complex queries on the fly. 
That's why I said Mercury would be well-suited to write Opium-M code, but
Prolog is better to type queries on the fly.

| I don't think the semantics are a problem at all.
| The current implementation technology is the problem.
| If we had a Hugs-like implementation of Mercury, then I think you
| would be convinced.

Ok, I will have a look at that.

| Of course, currently we don't have a Hugs-like implementation of Mercury,
| and so that leaves the question of what to do in the meantime.
...
| What happens if the user accidentally writes
| 
|     :- pred filter(collected_type::in, event::in, collected_type::out) is det.
| 
| instead of
| 
|     :- pred filter(event::in, collected_type::in, collected_type::out) is det.
| 
| ?
| I suspect the answer in your current implementation is "undefined behaviour",
| probably a seg fault.

Probably. But my intent was that the user wouldn't need to write the interface
(since it is always the same) but just the implementation.

Otherwise, since the interface is always the same, we could easily check that
the user correctly wrote the interface.
 
| > Note that I could have let the collecting variable uninstanciated:
| > 
| > :- pred initialize(T) .
| > :- pred filter(event, T, T).
| 
| No, that wouldn't work, because the type variables there are implicitly
| universally quantified

I see.

| > In which sense do you say it is more elegant?
| 
| Well, I said it _might_ be more elegant.

[cutting arguments for and against the typeclass version]

Ok, thanks; we will carefully consider that.

-- 
R1.


--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------