[mercury-users] Mercury as a 1st class prototyping language ?

Tyson Dowd trd at cs.mu.OZ.AU
Fri Oct 27 20:57:12 AEDT 2000


There are a few things that haven't been mentioned in this discussion.

We have in the past considered some extensions to the Mercury
implementation to support quicker prototyping.  From memory, essentially
this would boil down to a compiler switch to allow unwritten predicates
to be replaced with throwing an exception at runtime and turning on all
type and mode inference.  This means you can prototype code but you
don't have to worry about writing code for unused code paths, just leave
it out.  This would let you write programs top-down, writing only the
details when you are interested in them.

We have long discussed a more interactive development environment for
Mercury, including some sort of top level query mechanism.  This would
speed prototyping using a bottom-up approach as it would be easier to
interactively test out low-level code by using the query interface.
The debugger already allows queries to be given, but is a little more
trouble to use than a true top-level query prompt.

Finally, the (very experimental) logic programming language HAL
probably fits your ideals even better.  HAL is built on top of Mercury
(it compiles to Mercury) and uses Mercury type and mode declarations 
if available, otherwise it uses a more general (Prolog-like) execution
algorithm with dynamic scheduling.  It also includes constraint solving
facilities.  (Excuse any liberties I've taken with the description of
HAL, this is also from memory and trying to be brief).  I think that
fairly rapid prototyping (using that term loosely) should be possible in
HAL (or something like HAL), and then there should be a very smooth
transition to Mercury for real implementation (possibly by adding
declarations until you get Mercury, but of course this might have poor
software engineering consequences if your prototype was not designed to
start with).  In HAL there are plenty of declarations are only used for
optimization.

On 25-Oct-2000, david wallin <david at wallin.cx> wrote:
> Hi,
> 
> To get a program to pass the Mercury compiler without errors consumes 
> a lot of time, at least from an new mercury programmer (like me). 
> Some will argue that this time is well spent and that you get it back 
> when you are (not) debugging the program.
> I suppose you could also argue that a lot of the time spent is to 
> help the compiler do its job as effectively as possible: type 
> declarations, modes, instantiations, etc. However, wrapping your 
> brain around all of these concepts takes a lot of time, and 
> unfortunately it seems you have to grasp them all to get anywhere, I 
> would say Mercury has a steep learning curve. (It could of course be 
> the lack of Mercury books that makes me feel this way). 
> Unfortunately, no matter how big reward there is in the end, a 
> language that is hard to master will not get that many users.
> 
> What I would like to see is a language that gives you the possibility 
> to quickly build a prototype of your idea; a proof-of-concept. When 
> you see if this idea holds you can add information that will make it 
> easy for the compiler to optimize.
> Today you either write directly in C[++] and get stuck in debugging 
> mode or you first develop a prototype of your application in an 
> "easy" language  (whatever that is) and then rewrite it (parts or 
> whole) in an efficient language. If you can combine these (ease & 
> efficiency) you have a killer language.
> 
> I don't know how hard it would be to actually implement such a 
> language. How easy would it be to make Mercury optionally more 
> forgiving and make the compiler optionally require less information 
> (at the cost of less optimized code) ?
> 
> any comments ?
> 
> 
> 
> --david.
> 
> (BTW: How accurate is the TODO list on the web, it hasn't been 
> updated for almost a year)
> 
> --------------------------------------------------------------------------
> 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
> --------------------------------------------------------------------------

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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