[mercury-users] Suggested DCG extension

Peter Driscoll peter_driscoll at bigpond.com
Mon Apr 1 14:58:04 AEST 2002


It seems to me that the problem with DCG is that you only get one pair or
in/out variables.

What if you had a type,

:- type streamer_info(T) ---> streamer(input :: T, output :: T).
:- mode streamer_mode == bound(streamer(ground, free)) >>
bound(streamer(ground, ground)).

and you took the functor streamer to have the special meaning, similar to
DCG.  For example,

:- pred example(streamer(io_state)::streamer_mode).
example(IO) :-
	my_write("First,", IO),
	my_write("Second", IO).

would mean,

:- pred example(streamer(io_state)::streamer_mode).
example(streamer(DCG0, DCGN) :-
	my_write_string("First,", streamer(DCG0, DCG1)),
	my_write_string("Second,", streamer(DCG1, DCGN)).

Then from functional programming we would borrow the idea of currying.  We
would write,

:- pred example(streamer(io_state)::streamer_mode).
example :-
	my_write_string("First,"),
	my_write_string("Second").

and mean,

:- pred example(streamer(io_state)::streamer_mode).
example(IO) :-
	my_write_string("First,", IO),
	my_write_string("Second", IO).

That is, any parameter ommitted would automatically passed on to any calls.
As usual curly brackets would exclude calls from receiving these implicit
parameters.

The advantage is that you can then add as many streamers as you like.  One
for input, one for the database, one for unique identifiers, one for
timestamps etcetera.  You also wouldn't need a separate --> symbol.

Regards

Peter Driscoll

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the users mailing list