[mercury-users] Handy Programming tool for Mercury.

[Peter Schachte]

> > Is there any strong reason why didn't you implement that script in Mercury
> > itself ?
> 
> I considered using Mercury, and it's doubtless the case that a Mercury
> implementation would be more robust.  However, it's essentially a text
> mangling task and it's easier to do that kind of thing in Awk.
> 
> If I/someone eventually gets around to providing a decent generic
> parsing module then the next version will probably be in Mercury.

I tend to use perl for that kind of task.  (Please: no perl vs. awk
vs. tkl vs. guile vs. anything else wars.  Which language is best for
this sort of programming isn't the point.  The point is that it isn't
Mercury.)  And having a good parser- and lexer-generator for Mercury
would certainly make some text transformation tasks like this a lot
easier.  Also, having a good powerful general-purpose regular
expression library would be useful.

But even with all those things, I think I would still tend to prefer
perl for many such tasks.  I've been trying to think of what
facilities Mercury would have to have to make it a really good
language for writing text transformation scripts.  I think these
things would help:

     o	A convenient way to traverse a file.  Perl and awk both make
	this very easy.  I think the nicest way to do this would be to
	have a sequence constructor class, and have file be an
	instance of this class as a sequence of chars.  To make it
	really pleasant, make the class require this method:

	    :- func [T:out | Sequence:out] = Sequence:in is det.

	Strings should also be an instance of this class.  Of course,
	implementing this (allowing backtracking) would require being
	able to seek in the file, but that shouldn't be a problem.
	And doing this for pipes would require being prepared to
	buffer the whole stream in memory.  But I think that would be
	OK for the sorts of programs I'm thinking of; memories are big
	these days.  I often read whole files into memory in my perl
	scripts.

     o	A convenient way to generate a file.  The above class is a
	read-only sequence; for output you'd probably also want a
	write-only sequence.  It would be nice if the method

	    :- func [T:in | Sequence:in] = Sequence:out is det.

	would be the right way to do that, but I don't think it would,
	because this encourages you to build on the front of the
	sequence instead of the end.  I don't have a good proposal for
	this now.

	Also important for generating output would be a nicer
	formatting predicate/function, as well as a version of this
	that would let you apply a format to a sequence of tuples
	of data (for generating tables and such).

     o	A convenient way to thread state.  Of course, I'd prefer an
	approach similar to that proposed in my global variables
	paper (http://www.cs.mu.oz.au/~schachte/papers/iclp97.ps.gz),
	but the exact syntax isn't so important.   The point is that
	dealing with things like command line switches gets to be a
	real nuisance in Mercury as it is now.  You invoke getopt to
	parse the switches, and then you have to thread your io__state
	everywhere through your program just so you can find out what
	options the user specified where you need to know it.  I won't
	rehash all the arguments about this.

These are all the things I can think of offhand that would be
important for making Mercury a good language for writing text
transformation tools.  Does anyone have anything to add?  Any
alternatives to these?


-- 
Peter Schachte                     Start at the Beginning, go through till
mailto:schachte at cs.mu.OZ.AU        the End, then stop.
http://www.cs.mu.oz.au/~schachte/  -- Lewis Carroll, "Alice in Wonderland" 
PGP: finger schachte at 128.250.37.3  
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------