
Alloy*: A Higher-Order Relational Constraint Solver - Cieplak
https://aleksandarmilicevic.github.io/hola/
======
sidereal
Before learning about Alloy*, you might want to learn about Alloy itself:
[http://alloy.lcs.mit.edu/alloy/index.html](http://alloy.lcs.mit.edu/alloy/index.html)

Hillel Wayne has a great series of blog posts on using Alloy to solve software
design problems:
[https://www.hillelwayne.com/tags/alloy/](https://www.hillelwayne.com/tags/alloy/)

~~~
yesenadam
(I'm no expert but..) I recently got into Prolog, and Alloy sounds very
similar. So I was asking "How is it different?" Strangely, in the FAQ, no
mention of Prolog. I found just this:

>How does the Alloy Analyzer differ from theorem provers?

>The Alloy Analyzer's analysis is fully automatic, and when an assertion is
found to be false, the Alloy Analyzer generates a counterexample. It's a
"refuter" rather than a "prover".

(i.e. where Prolog would just write "no" if nothing found.) In the Alloy*
paper also, no mention of Prolog. To find a counterexample, couldn't you set
Prolog to find one?

~~~
sriram_malhar
Alloy is a specification language. To verify the specification, the alloy
analyser (a model checker) has to artificially create some number of instances
and simulate it.

Prolog is an executable language. You, the user, give it a database, and it
searches for solutions that satisfies constraints. It doesn't create the basic
facts on its own.

There exists a compiler from imperative alloy to prolog to make this
transition.

~~~
yesenadam
Hmm well, not all Prolog uses fit the 'give it a database' model..(In fact I
can't think of any Prolog programs I've seen that do fit it) e.g. I was tried
the the finite domain solver in Gnu Prolog[0] recently, I wanted arrangements
of about 15 shapes that obeyed certain constraints, the program was 6 very
short lines! I didn't tell it anything except the constraints.

But yeah, alloy and alloy* sound fascinating, I must investigate further,
thank you.

[0][http://www.gprolog.org/manual/html_node/gprolog054.html](http://www.gprolog.org/manual/html_node/gprolog054.html)

~~~
sriram_malhar
You are right. Constraint solving in general is a specific area that does not
require a knowledge base; instead it is a search for a solution from the
specified domain that fits all the specified constraints. Here there is
considerable overlap between prolog, alloy and z3.

However, most general prolog programming has the same requirements placed on
other executable languages, to transform, store and communicate data. Alloy is
not the tool for this aspect.

------
bayesian_horse
Sometimes it would be great for such posts to somehow explain to the
uninitiated why you want to be initiated.

"Relational Constraint Solver" sounds sort of interesting, but I haven't the
faintest clue what I could use it for, and that's not that common for me.

~~~
fspeech
Alloy (and the philosophy it is based on) is explained in Daniel Jackson's
book <<Software Abstractions>>, which is a very nice book to read on
techniques of specification and verification (at the specification level).

~~~
bayesian_horse
I got that. What exactly is exciting about such verification, especially
despite the theoretical complexity, effort, and lack of common use?

I really don't want to insult anyone with these questions. I'm genuinely
curious why people spend time on such things and presuppose there are good
reasons. I just don't know them yet.

------
_pmf_
What would be really great if Alloy (or any spec language) allowed for code
generation (even if inefficient code).

------
rurban
I still find cbmc easier to find exhaustive counterexamples or test cases,
because I can do it in straight C.

With ATS or spark/Ada I can also do the same, but much more. I can actually
solve the problem, not only prove that it is solvable or incorrect.

