Re: [] \= '[]' (was Re: Ann: SWI-Prolog 7.1.0)

Hi Paul,

On 11/27/2013 02:47 PM, Paul Singleton wrote:
> On 27/11/2013 07:37, Richard A. O'Keefe wrote:
>
>> One important thing to remember is that not all Prolog data is
>> generated by Prolog, and not all SWI Prolog data is generated
>> by SWI Prolog.
>
> Indeed, e.g. JPL presents traditional Prolog's *abstract* syntax to JVM
> languages as an obviously corresponding class hierarchy:
>
>    Term
>        Variable
>        Integer
>        Float
>        Atom
>        Compound(Atom, Term[])
>
> It is unaware of lists or any other term-encoding convention, and
> supports them all.

Not really. There have been attributed variables and strings for a long
time. At some point, it is likely that there will be rational numbers as
a real type rather than a compound rdiv(N,D).

> Jan's [] is a new, single-valued primitive type, and JPL will not work
> with existing apps under V7 unless this classic term model is extended.

True. Ideally (IMHO), the JPL model incorporates lists. That is how it
has been in the C API for a long time and is common practice in most
foreign interfaces to Prolog. Probably for various reasons. One is that
the internal representation of lists is generally different from other
terms in Prolog.  Another is that you can have more general routines,
such as mapping lists to arrays instead of doing the job cell-by-cell.

> At the heart of the current debate is a disagreement on the sacredness
> of this term model.
>
> For me, it is sacred (if anything, I want to simplify it, but that's
> another topic).
>
> For Jan, it's OK to complicate it as long as an elegant and
> coder-friendly illusion can be maintained at the source code level (is
> that fair? I'm not trying to denigrate it).

What I'm after is more runtime type information, such that the important
syntactical constructs as well as the data types from other languages
are represented by types that can be detected at runtime without having
to wrap everything into compound terms. I would have been happy to
introduce a real type `list'. I think you should see that as the
ultimate goal. Introducing lists distinct from compound now is a bridge
too far as it breaks too much code.

> I always expected to see developments in concrete syntax, layered over
> the classic syntax (which would live on as an increasingly hidden legacy
> markup language), layered over the classic term model (untouchable
> unless we can find and justify smart generalisations which are fully
> backward compatible).
>
> I have a large investment in Prolog code, a considerable amount of it
> dependent on metaprogramming and introspecting the classic term model
> (memoing, cycle-detecting meta-interpreters, deep indexed terms in
> secondary storage, interfaces to other languages, etc. etc.) and never
> expected this to be broken.
>
> A year ago, I gambled my business (literally) on SWIPL and its
> httpd/HTML support, forsaking ten years of JavaServer Pages and MySQL
> (how quaint that seems now) to fulfil a government contract in what I
> felt confident was a smarter infrastructure for agile development of
> modern web apps.  Experience so far has vindicated this faith, but I am
> *seriously* spooked to be sidelined into a --traditional mode.

If you want to stick with the classical data model, you are indeed in a
difficult situation. On the one hand, V7 conflicts with this simple data
model. You can `fix' that using --traditional. On the other hand, V7
will significantly improve the web server infrastructure. Many of the
data structures involved in the web server infrastructrure will move to
dicts (just finished renaming map -> dict). I do not yet know what the
migration path will look like. I suspect that some of the libraries will
get a `dict' version and the old one will be deprecated.

The alternative is to add lists and strings to JPL.  I don't know how
much Java code using JPL needs updating after that.  After adding these
types to JPL, old Java code should keep working with --traditional, while
new Java code using lists and strings will work with both settings.

	Cheers --- Jan