[Haskell-cafe] Is Curry alive?

[wren ng thornton]

On 11/4/10 6:32 PM, Gregory Crosswhite wrote:
> On 11/04/2010 03:06 PM, Dan Doel wrote:
>> Implementing type inference can be very easy in a logic language,
>> because most
>> of the work in a non-logic language is implementing unification:
>>[...]
>
> Cool! Thank you very much; that is exactly the kind of thing I was
> looking for. :-)

And for constraint languages just think of, er, constraint problems.

That is, I'm running a factory that needs to make a bunch of different 
widgets, but different workers/stations only know how to make certain 
widgets, or certain workers are only available for so many hours a day 
or certain days of the week, and certain widgets are needed in order to 
make other bigger widgets. What is the best scheduling of jobs to 
maximize my productivity?

Or to pick a less practical (but no less actual) example: you're a 
crossword puzzle designer. You have a big dictionary of words and you 
need to come up with a 32*32 board where all the words intersect in the 
right way. Oh, and it should be a pretty symmetric design too.

Some formalisms for parsing (or generating) natural language work by 
declaring a bunch of constraints on how words can interact, rather than 
postulating a grammar of tree structures. In certain ways it's a lot 
nicer, right? You just put down rules like "adjectives precede the nouns 
they modify", and that's that; no need to worry about left corner 
transforms, or making your grammar deterministic, or unary rule cycles, 
or the other traps awaiting an unwary CFG designer.

Or, I have a system of linear inequalities and I want to find the 
solutions. That is, the "interesting" ones: the boundary solutions.


In a language like ECLiPSe you just need to state whatever the 
constraints are and then hit the START button. In general you shouldn't 
have to worry about how the runtime searches for answers, though 
worrying about that is how you do optimization in constraint programming.

-- 
Live well,
~wren