What I would like to understand better is: “modern Prolog” seems to be a phrasing which has a precise meaning in the Prolog community. Does it denote some recent developments in the language dating exactly to which period? Are these developments peculiar to Prolog in general or just to swi-prolog? Thanks
1 Like
Wow. Postmodern sounds really interesting in the field of programming! 
Certain new things were refused. Ok. Thanks
Ok. That the list-constructor has changed I had noticed it. Because they needed the full stop as selector for dictionaries if I understood well
I have a social science-humanities background, so when I first made “acquaintance” with prolog what really interested me was the idea of processing linguistic data. It seemed to me extremely challenging and interesting (it still does). Then of course if you start getting interested in something you find yourself naturally involved in some more technical stuff, if you want to understand how something works, but i don’t really come from computer science and all these worlds, these communities, that gather around languages I didn’t know about their existence. I think in any case it’s good to have someone with whom you can exchange ideas or more experienced people who can give some advice or directions
Sorry. I meant to say “natural language processing” in a broad sense. Parsing is one of the major areas of course
I wonder if any Prolog implementation uses CDR-coding? That would allow the flexibility of the “classic” string operations (where a string is a list of codes) together with the compactness of a special string type. CDR-coding would also require giving up ('.')/2 for lists nodes.
Why were dictionaries introduced? Because they are more efficient than compound terms? Or because it’s easier to work with them via named keys instead of having to write, let’s say,
employee(_, _, _, WhatImInterestedIn, _, _)? More in general I have the impression that there might be some tensions between wanting to be efficient on one side, and at the same time wanting to keep faithful to the original “logical purity” of the language. These my impressions
You can read about this in the docs. Pay attention specifically to “When to use dicts?” and “A motivation for dicts as primary citizens”.
The short answer: they are quite much easier to use and acceptably efficient in several very common use cases where solutions existed but are a pain to use. They are an example of what I would call “progress”.
1 Like
Dictionaries cannot be asserted/retracted like compound terms, I noticed. One might say:“Well, they are not dynamic predicates in the end…”. But of course this implies a somewhat different discipline, if one wants to store a knowledge base in a file and access it and change it from a running prolog file. If I understood well, heavy use of dynamic predicates (assertz, retract, etc) was always deprecated from the standpoint of “clean” prolog writing
Ok. But don’t leave me in this no man’s land…how can one assert/retract dictionaries? If you know the trick…Thanks
ahhh…ok…I see that you prefer the strategy of answering without answering 
inductive reasoning…ok… thanks for the hint at least
I didn’t know lists could be asserted…so there are several new things I have to learn…I am pretty sure that I’m dealing with superancient prolog…thanks for the moment
I have found a stack overflow thread where the topic of asserting lists is discussed…so I’ll start from there. Thanks
I “discovered” this:
?- employee{name:bob, family_name:worker} =.. X.
X = [C'dict', employee, bob, name, worker, family_name].
wow. that was pretty awesome, I have to admit. univ for dictionaries…with that strange C’dict’ operator or what it is… 
While I can’t comment directly on what constitutes “modern” Prolog. (My experience with Prolog outside of a classroom is very limited).
I hope I can shed some light on “modern” programming in general. I don’t think it’s a very precise term at all and you’re unlikely to get consensus on what dialect of Prolog is “modern”.
As languages grow, it can be hard to get rid of some features entirely - doing such would break existing codebases. But often new features or changes in thought render older features obsolete.
I can think of three reasons why a feature or programming style might not be a part of “modern Prolog”
- It relies on systems that aren’t actively maintained or updated or sees very little use
- There’s an alternative feature that accomplishes the same thing in a better way
- That style of programming often leads to errors, poor performance, security vulnerabilities, etc
As for what features or programming patterns fit these criteria; I’m not really sure - generally up to date and high quality learning resources will not spend much time on anything but “modern Prolog”.
Code can also be considered “modern” in a sense if it fits in with the wider ecosystem. E.g. if it consumes third party packages in the standard way or can be imported by other modules that follow convention.
1 Like
There are some interesting things about dicts, that I’m slowly getting accustomed at. For example by looking at them from the outside one might think that the tag works as the functor of the dict, like in compound terms, but no…even in this respect they are more similar to lists and the functor is that strange C’dict’ constructor:
functor(employee{nome:bob, cognome:worker}, Fun, Ar).
Fun = C'dict',
Ar = 5.
This means that the tag is considered the first argument of the dict rather than the functor:
arg(N, employee{nome:bob, cognome:worker}, Arg).
N = 1,
Arg = employee ;
N = 2,
Arg = bob ;
N = 3,
Arg = nome ;
N = 4,
Arg = worker ;
N = 5,
Arg = cognome.
It wasn’t meant to be a critical observation… I was just curious to understand better how dicts are structured internally. But it’s not a matter of life or death…maybe we have already spent too much time on the subject. Have a nice day
I didn’t want to waste yours…
Your yesterday’s explanation on how to assert dicts in any case was clear enough.
Thanks for the suggestion. I’ll check this sweep out.
That was exactly my error at first…I was trying to assert them directly as if they were compound terms