Ann: SWI-Prolog Pack that adds a new Global Variable syntax to Prolog

[Douglas Miles]

SWI-Prolog Pack that adds a new Global Variable syntax to Prolog

Installation

Using SWI-Prolog 7.1 or later:

?- pack_install(
​'
https://github.com/TeamSPoon/gvar_syntax
​.git'​).

Source code available and pull requests accepted at http://github.com/TeamSPoon/gvar_syntax

?- use_module(library(gvar_syntax)).
true.

?- $foo.value = 1.
true.

?- $foo.value = 2.
false.

?- writeln($foo.value).
1
true.

?- writeln($foo.get()).
1
true.

?- $foo.clear().
true.

?- writeln($foo.value).
_8350

?- writeln($bar.set(2).value).
2

?- $foo.value = yyyyyyy.
true.

?- $baz.set(point{ x: ($foo.get()) , y:vy, z:vz}).
true.

?- writeln($baz.value.x).
yyyyyyy
true.

[Douglas Miles]

On Sat, Feb 11, 2017 at 9:56 PM, Anne Ogborn <an...@theelginworks.com> wrote:

How does it interact with modules?

That is, are your $foo variables in a truly global space?

They are.. but I think maybe it'd be nice to limit it to modules as well? ​

I wonder the right way to have users enable that option?

:- set_prolog_flag(gvar_syntax_lookup,module).  ?​

​

[Douglas Miles]

On Sat, Feb 11, 2017 at 10:09 PM, Anne Ogborn <an...@theelginworks.com> wrote:

You could either do

$module:foo.get()

​Presently this works​.

But also I can see people might want variable names scoped to

`module`- use the current source module as the scope (sicstus gvars are always scoped to at least some module) 

`global` is the present case  and allows users to prefix them.

 

or

be outside the normal module space and be


$namespace$sub_namespace$foo.get() 

where you can have an arbitrary nesting of subnamespaces.

​

​I have another pack that I haven't announced yet https://github.com/TeamSPoon/dictoo

This allows us to build up namespaces as dictionary members 

Why i haven't "announced that one yet" 

Is I am trying to decide how people want to add new methods and fields to objects.

If I should build that upon Logtalk or not.   Currently its built upon SWICLI, JPL, Attvars and Dicts.

But the declarative syntax of getting users to add new things besides use current things is an open question.

[Douglas Miles]

On Sat, Feb 11, 2017 at 10:31 PM, Anne Ogborn <an...@theelginworks.com> wrote:

>If I should build that upon Logtalk or not.   Currently its built upon SWICLI, JPL, Attvars and Dicts.

Any of those are, IMHO, too much coupling. 

I don't want to drag in all of logtalk or swicli just to get your pack!

dictoo​ checks to see if modules are loaded before it enables those features of JPL and SWICLI objects.

I built up the system initially on dicts and attvars.   Using Jan's methodology for adding new Functions to classes of dictionaries.

Also I am allowing new field members to be built upon any existing dictionary in dictoo.

Haven't yet enabled Logtalk objects..  But my interest in Logtalk is in the long run people will need a source file format (that I don't need to invent) to enable adding new synthetics to existing classes. Also for describing the sub classing. 

(Separate thread, I am not sure Logtalk's pack actually installs all the support needed to be used as a dependency)