Re: Ann: SWI-Prolog 7.1.0

On Fri, Nov 22, 2013 at 4:36 PM, Jan Wielemaker <[email protected]> wrote:

> Hi,
>
> I have uploaded SWI-Prolog 7.1.0. As the major release indicates, this
> makes SWI-Prolog a different system. You find more elaborate
> documentation including motivations in the chapter "SWI-Prolog
> extensions" in the manual.
> (http://www.swi-prolog.org/pldoc/man?section=extensions).
>
> I understand that this move will make some users deeply unhappy. I am
> also convinced that (SWI-)Prolog badly needed some refreshment that
> enables smoother integration with modern IT platforms while making the
> language appear more natural to new users. The key issue is that
> many of us need a language to write applications that talk to other
> systems and not only a language that can "solve N-queens very elegantly,
> but in splendid isolation". Don't worry, it can still solve N-queens
> very elegantly, especially using Markus' clp(fd).
>
> I would like to thank all people that provided feedback on the original
> proposal.
>
> Vitor Santos Costa has expressed that he likes most aspects of the
> current proposal, which makes it likely that YAP users can enjoy
> these gadgets too at some point in the future.
>
> Below are the highlights:
>
>   - Lists are no longer represented as .(H,T).  Instead, the list
>     functor is now '$cons'(H, T).  The empty list is still [], but
>     this is not an atom.  I.e., '[]' == [] fails.
>
>   - By default, double quoted "text" is mapped to an object of type
>     string.  This already raised some discussions.
>
>   - The system introduces `maps' as primary citizens.  Maps are
>     collections of key-value pairs, optionally typed. Maps are
>     supported by read and write.  The syntax is
>
>         type{key1:value1, key2:value2, ...}
>
>     Keys in a map can be addressed using the functional notation
>     Map.Key.  User functions on maps can be accessed as Map.Compound
>     (e.g., Vector.multiply(V2)).
>
>   - Quoted atoms are no longer operators.
>
>   - Unquoted atoms may contain internal dots.  E.g., a.b is an
>     atom.
>
>   - functor() is valid syntax.  It produces a term that is distinct
>     from 'functor'.  The `block' operator '()' to hack this syntax
>     has been removed.
>
>   - The `block' operators [] and {} remain.
>
> Most of this can be disabled using "swipl --traditional". Notable this
> gets the old list datastructure and "text" as a list of character codes.
> It also disables functional notations on maps. The other syntax
> extensions remain valid as they do not cause incompatibilites by
> themselves.
>
> I expect the system to run fairly stable.  Depending on feedback, there
> could be minor changes to the extensions.  Certainly, there will be more
> predicates operating on strings and maps and more of the libraries will
> be prepared to work with these extensions.


Hi Jan,

Congratulations for the new release!

Some of the new features are really nice. Some experimental branch of Ciao
allows '.' as an operator for something similar to field access. Mercury
also switched some time ago from ':' to '.' for module qualifications. I
just want to let you know that some changes may be welcome by other systems.

However, I am not complete sure about a.b being an atom. Does 'a.b' = a.b
succeed?

Bests,

-- 
Jose
-------------- next part --------------
HTML attachment scrubbed and removed