

SWI-Prolog extensions in version 7 - nickmain
http://www.swi-prolog.org/pldoc/man?section=extensions

======
rdtsc
It has built-in maps now! (like dicts or hashes in other languages).

[http://www.swi-prolog.org/pldoc/man?section=maps](http://www.swi-
prolog.org/pldoc/man?section=maps)

That is exciting. I'd want to play with it again. I like Prolog. Or rather, I
like idea of Prolog, until I go to solve a problem and it breaks my brain. I
love seeing elegant solutions to complicated problems in 10 lines of code, but
also realizing there is little chance of me coming up with those solutions.

Other languages, functional, OO, imperative, I can often iteratively improve a
solution. It goes from wrong,better, even better, almost works, good enough.
With logic languages it goes from wrong, wrong, wrong, x100 ..., aha I got it
and it is beautiful and short.

Also speaking of maps, Erlang is probably going to get them too in the next
release early next year -- R17,
[https://github.com/erlang/otp/tree/egil/maps/eep-
implementat...](https://github.com/erlang/otp/tree/egil/maps/eep-
implementation).

~~~
zvrba
> It has built-in maps now!

Prolog has always had that. You declare facts like parent(patricia, shelly),
and you cant make this at run-time too with assert and retract. Unification &
resolution makes this work like a 2-way map. What's the big deal now?

~~~
rdtsc
> 5.4.3 When to use maps? > Maps are a new type in the Prolog world

Sorry, I'll take SWI-Prolog developers' word over yours in this case.

Your argument is a bit like the "Well this old existing language is Turing
complete, so why bother with anything".

~~~
danieldk
_Your argument is a bit like the "Well this old existing language is Turing
complete, so why bother with anything"._

Except that he is right that Prolog facts (and other clauses) can be used as a
mapping. At the very least, modern Prolog implementations index on the first
argument (compute the hash code and look that up). So, you get similar
properties to a hashmap: you can look up in O(n) time and get an associated
atom/term/...

However, multiple clauses can match a query. For instance, given

    
    
      foo(bar(x),1).
      foo(bar(y),2).
    

the query _foo(bar(_),X)_ creates a backtracking point (both facts unify, so X
will be bound to x and y subsequently). SWI-Prolog's new maps behave more like
normal maps in that there cannot be duplicate keys. However, you could enforce
that with Prolog facts as well:

    
    
      assert_unique(parent(X,Y)) :-
        retractall(parent(X,_),
        assert(parent(X,Y)).
    

_assert_unique(parent(jack,john))_ will ensure that any _parent(jack,_)_ facts
are removed before asserting the new fact.

~~~
rdtsc
A prop list can be used as a mapping too. What about integers being keys. Or
say de-serializing a nested JSON document to clauses. How does a 3 level deep
map work with clauses?

>

    
    
         assert_unique(parent(X,Y)) :-
         retractall(parent(X,_),
         assert(parent(X,Y)).
    

Maybe to you that looks like an example why maps are _not_ needed as they just
reinvent the wheel or something. To me it looks like an example why maps _are_
needed.

~~~
danieldk
_What about integers being keys._

That works fine.

 _How does a 3 level deep map work with clauses_

The most straightforward manner is like you would do this in a relational
database (if the goal is to keep O(1) times). E.g. two-level:

    
    
      foo(a,x).
      foo(b,y).
    
      bar(x,a-x-one).
      bar(x,a-x-two).
      bar(y,b-y-one).
    

Again, you can add predicates to make this less unwieldy.

If the JSON conforms to a schema, there is also the possibility of mapping
particular keys to arguments. Since you know the set of possible keys in such
a case, you could map keys to fixed term arguments. E.g. a structure such as:

    
    
      { "foo": "apple", "bar": "pear" }
    

Could be mapped to:

    
    
      json(apple,pear)
    

You would have the same You could do this for deeper maps as well. It gives
you the same benefits as hash maps, O(1) indexing. In fact, the Hdrug[1]
system uses such a representation for partially typed feature structures,
which can have an arbitrary depth. It provides a DSL for easily specifying
types (the 'schema') and unifying structures and substructures. There is also
a short description in the introductory chapters of my thesis, though it is
definitely not my work ;).

Note: I am not for or against adding maps to the language. There are probably
applications where they are very handy in Prolog. For the things I worked on
in Prolog I never really needed first-class maps.

[1]
[http://www.let.rug.nl/~vannoord/Hdrug/](http://www.let.rug.nl/~vannoord/Hdrug/)

[2] [http://danieldk.eu/Research/Publications/phd-
thesis.pdf](http://danieldk.eu/Research/Publications/phd-thesis.pdf) (starting
at the end of page 19)

~~~
hnriot
syringes???

~~~
danieldk
It's a joke. RUG (Rijksuniversiteit Groningen, University of Groningen) is
actually where it was developed. Hdrug was probably an acronym at some point,
and with such a name you quickly think of other substances ;).

------
mindcrime
I've been looking for a reason to use Prolog for some time, as I've always had
a sort of latent interest in learning it... but never had a project that just
_screamed_ for using Prolog.

Now, I think I may have that project. We're at a point with some of our
projects to where we are extracting structured information (as RDF) from
unstructured content, and storing that RDF in a triplestore, and allowing
SPARQL queries. So you can do things like asking for system for all "entries"
(where an "entry" can be a tweet, a blog post, an email message, etc.) where
say, "all entries that mention a musician who was born in the UK" or "all
entries that mention a college or university in the US, founded after 1800" or
whatever. Of course, normals don't write SPARQL queries, which leads us to
doing a certain level of natural language understanding, and then
automatically generating the corresponding SPARQL.

As it happens, Prolog has long been associated with NLP and there is quite a
bit of literate on doing this kind of work with Prolog. So now I'm very
excited about a chance to learn Prolog and apply it to a problem that I find
very interesting.

 _Aside: Yes, I am aware of Quepy[1], which does this in Python. But I also
want to learn Prolog for other reasons as well, and want to spend at least a
little bit of effort exploring doing in Prolog. But if it proves to be too
challenging to get something working, we may use Quepy._

[1]:
[https://pypi.python.org/pypi/quepy/](https://pypi.python.org/pypi/quepy/)

------
nickmain
Version 7 now installs as an app on OS X.

It is heartening to see the icon in the task switcher:
[http://twitpic.com/dmc8pb](http://twitpic.com/dmc8pb)

------
mark_l_watson
Excellent! I used to enjoy swi-prolog a lot, especially the semantic web
library.

