Re: mutable object model

On 11/13/2013 04:05 PM, Alan Baljeu wrote:
> By "map" do you mean a special term, stored in a local variable?  Which

I was a little too quick. The maps are currently basically not mutable
(except for the limited sense as in setarg/3 and friends). I know how I
could make them mutable transparently without breaking things. I'm a
little reluctant about mutable datastructures. They do not fit Prolog
very well.

Yes, they are terms stored as (special) compound terms.

> When about is the next major version?

Getting close to a preview version. Everything is in a branch called V7
on the pl-devel.git repo. It is still a bit rough. It comes with a
number of changes, some of which with significant compatibility issues.
It has been discussed in a small group, which was already hard enough as
there are strong feelings both in favour and against change. All I want
to say right now is that you'll spend some time in porting, ranging from
nothing to about a day. Next, it is likely to change your daily routine
in Prolog considerably.

If you don't like it, there is "swipl --traditional" which disables the
stuff that causes incompatibilities as well as most of the new features.
Unfortunately this is a commandline switch and not a Prolog flag because
some of this affects the boot cycle.

	Cheers --- Jan


> Alan Baljeu
> ------------------------------------------------------------------------
> *From:* Jan Wielemaker <[email protected]>
> *To:* Torbj�rn Lager <[email protected]>; Alan Baljeu
> <[email protected]>
> *Cc:* Prolog <[email protected]>
> *Sent:* Wednesday, November 13, 2013 3:07:27 AM
> *Subject:* Re: [SWIPL] mutable object model
>
> Torbj�rn, Alan,
>
> You may be interesting to hear that the next major release of
> SWI-Prolog will provide `maps' as primary citizens that are
> supported throughout the system (parsing, writing, efficient
> low-level operations).  YAP is likely to copy these features.
> Just hold on ...
>
>      Cheers --- Jan
>
> On 11/12/2013 11:31 PM, Torbj�rn Lager wrote:
>  > Hi Alan,
>  >
>  > It may not be exactly what you need, but I have from time to time
>  > considered somthing similar to what you describe. Unfortunately, I'm
>  > far to occupied with the next version of Pengines to attempt an
>  > implementation. I share my ideas with you and with others on the list
>  > in the hope that it will feed into further discussions.
>  >
>  > My suggestion for a syntax, both for an immutable "record type" and
>  > for a mutable "dictionary type" would be something like this:
>  >
>  > {a: {b: 1},
>  >  c: [ {d: 2}, {d:3}],
>  >  e: foo,
>  >  f: [4, 5, 6],
>  >  g: @true
>  > )
>  >
>  > Note that:
>  > 1) This syntax is prolog readable
>  > 2) If ground, it *very* easily and naturally translates into JSON -
>  > just transform it into SWI-Prolog's JSON terms
>  > 3) A path language able to pick out any value can easily be defined
>  > 4) A graph unification operation can be defined that allows us to
>  > unify two immutable and "open" records
>  > 5) Assignment operation can be defined that allow us to update any
>  > instance of a mutable dictionary
>  > 6) One could probably define a predicate able to turn any immutable
>  > record into a mutable dictionary
>  > 7) One could probably define a predicate able to turn any mutable
>  > dictionary into a immutable record
>  >
>  > Oz/Mozart (http://mozart.github.io/) has such things. They are
>  > referred to as records and dictionaries, and I have therefore used
>  > this terminology.
>  >
>  > I would love to have something like this.
>  >
>  > I have no ideas for an *efficient* implementation at this point. :-(
>  >
>  > Best regards,
>  > Torbj�rn
>  >
>  >
>  > On Tue, Nov 12, 2013 at 7:51 PM, Alan Baljeu <[email protected]
> <mailto:[email protected]>> wrote:
>  >> What would people suggest I use for a mutable object model in
> Prolog?  Some specifics:
>  >>
>  >> An open model is preferred, like is implicit in XML and JSON specs.
>  >> Simple XPath type queries are desired.  Select speed is paramount.
>  >>
>  >> Data is public.  There are no methods as such.
>  >>
>  >> Usually member variables would be treated logically: Initially
> unbound, then later bound.
>  >>
>  >> At times selected variables will be reset to unbound.
>  >> Variables can share an object.
>  >>
>  >> Usually objects are made by instantiating classes.
>  >>
>  >> Standard serialization such as XML or JSON is desirable to
> communicate with other systems.
>  >>
>  >> I don't expect everything above to be ready-provided.  I'm looking
> for whatever might
>  >> be an efficient and simple foundation and I'll code the rest.
>  >>
>  >> Alan Baljeu
>  >> -------------- next part --------------
>  >> HTML attachment scrubbed and removed
>  >> _______________________________________________
>  >> SWI-Prolog mailing list
>  >> [email protected]
> <mailto:[email protected]>
>  >> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>  >
>  >
>  >
>
>

_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog