One Year of SWI 7 (Dicts, Etc..)

[Jan Burse]

Hi,

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:
> (*->)//2 was added in 2002 to SWI. SWI does not have fully
> conforming control constructs. Nor does it advertise to be fully
> conforming nor advertise to plan to become fully conforming.
> So differences are unlikely to be reported and identified. See
> "Errors of call/1" in
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and_ISO

Yeah, the '[|]' breaks the following clause of the ISO standard:

6.3.5 Compound terms - list notation
List notation can be used for inputting or outputting a
compound term with principal functor '.'/2 (dot).

(Means doc http://www.swi-prolog.org/pldoc/man?function=./2
isn't precise for SWI 7)

What is the experience with dicts so far in SWI-Prolog?
Are they heavily used?

Wouldn't another syntax also do, for example a :> f to access
a field? The :> would be defined via function expansion.


Bye

P.S.: Quite interesting generalization of []/0 and {}/0 in SWI:

Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version 7.1.31)
Copyright (c) 1990-2014 University of Amsterdam, VU Amsterdam

?- op(200,xfx,{}).
true.

?- X = a {b} c, write_canonical(X).
{}({b},a,c)
X = a{b}c.

?- X = a {} c, write_canonical(X).
{}(a,c)
X = a{}c.

But things can go wrong, inhibiting normal list parsing:

?- op(200,fx,[]).
true.

12 ?- X = [a] b, write_canonical(X).
[]([a],b)
X = [a]b.

13 ?- X = [a], write_canonical(X).
ERROR: Syntax error: Operator expected
ERROR: X = [a],
ERROR: ** here **
ERROR: write_canonical(X) .

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Hi,
>
>ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:
> > (*->)//2 was added in 2002 to SWI. SWI does not have fully
> > conforming control constructs. Nor does it advertise to be fully
> > conforming nor advertise to plan to become fully conforming.
> > So differences are unlikely to be reported and identified. See
> > "Errors of call/1" in
> > http://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and_ISO
>
>Yeah, the '[|]' breaks the following clause of the ISO standard:
>
> 6.3.5 Compound terms - list notation
> List notation can be used for inputting or outputting a
> compound term with principal functor '.'/2 (dot).
>
> (Means doc http://www.swi-prolog.org/pldoc/man?function=./2
> isn't precise for SWI 7)
>
>What is the experience with dicts so far in SWI-Prolog?
>Are they heavily used?
>
>Wouldn't another syntax also do, for example a :> f to access
>a field? The :> would be defined via function expansion.

Even the dot-syntax could be used in a conforming manner with
virtually no impact on the intended uses.

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

>> Wouldn't another syntax also do, for example a :> f to access
>> >a field? The :> would be defined via function expansion.
>
> Even the dot-syntax could be used in a conforming manner with
> virtually no impact on the intended uses.

But a dot-syntax is a new feature. Using just an operator :> is
not a new feature. Also a dot syntax has a lot of drawbacks.
Can you for example explain what happens below?

?- P = point{? :1}, X = P. ?.

P = X, X = point{? :1}.

2 ?- write(hello).

ERROR: Syntax error: Operator expected

ERROR: ?.

ERROR: ** here **
ERROR:

write(hello) .

I think restoring lists would be important, otherwise a lot
of books and internet postings are just invalid for SWI-Prolog.
Take for example this post:

http://stackoverflow.com/a/27007676/502187

I think dot-syntax would require rewriting Prolog parser/unparser
and operator handling. And this is probably not viable, a lot of
overhead for a small thing.

The cheapest is just using another operator :> which doesn't
have some special meaning already.

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:
>>> Wouldn't another syntax also do, for example a :> f to access
>>> >a field? The :> would be defined via function expansion.
> >
>> Even the dot-syntax could be used in a conforming manner with
>> virtually no impact on the intended uses.
>
>But a dot-syntax is a new feature. Using just an operator :> is
>not a new feature. Also a dot syntax has a lot of drawbacks.

I cannot see a fundamental difference between

. as a quasi infix (as long as there is no infix declaration present)

and

:> as a similar infix.

Once and infix declaration via op/3 is given, both notation
have to resort to standard behavior.

>Can you for example explain what happens below?

The . in SWI is effectively never used in such situations.
So there is no space that makes things worse.

>I think dot-syntax would require rewriting Prolog parser/unparser
>and operator handling. And this is probably not viable, a lot of
>overhead for a small thing.
>
>The cheapest is just using another operator :> which doesn't
>have some special meaning already.

:> does have a meaning, if you add a user-provided infix\
declaration. It remains the same problem.

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

> I cannot see a fundamental difference between
>
> . as a quasi infix (as long as there is no infix declaration present)
>
> and
>
> :> as a similar infix.
>
> Once and infix declaration via op/3 is given, both notation
> have to resort to standard behavior.

Well the difference is well known. You
can input:

A :> B.

And it gives :>(A,B).

But you cannot input:

A . B.

It will not give .(A,B).

>> The cheapest is just using another operator :> which doesn't
>> have some special meaning already.
>
> :> does have a meaning, if you add a user-provided infix\
> declaration. It remains the same problem.

If :> is used and . remains what it is in lists,
no problems whatever arise.

If . is used and [|] replaces the . in lists,
then problems can arrise. All books and posts
about Prolog are invalidated, for example the
following SO entry is rendered rubish for
SWI 7:



A decend Prolog system with modules will also
allow to override an operator in a module and
warn if an operator is accidentially overridden.

Suppose you have the following end_user code,
here is a projection what the future release
of Jekejeke Prolog 1.0.6 should do:

File 1: mymodule.p

:- module(mymodule, []).

:- public op(100,xfx,:>).

If :> is not already defined, consulting the
mymodule works as follows:

?- ['mymodule']
Yes

If :> is already defined, consulting the
mymodule works as follows:

?- ['mymodule'].
Override operator infix(:>), declare accordingly.

The warning can then be fixed as follows, which
basically results in having two operator definitions,
one :> globally visible and one :(mymodule,:>) visible
in the mymodule and the modules that import mymodule:

File 2: mymodule.p

:- module(mymodule, []).

:- override op(100,xfx,:>).
:- public infix(:>).

Just a sketch. The overriding stuff works already
for predicates in Jekejeke Prolog 1.0.3. But did
not yet implement it for operators. The override
directive is a new invention.

Same warning and explicit overriding if needed can
also be done for the operator . .

But the point is not to replace . by [|] in lists.

With modules one could anyway stash :> into a module,
and it wouldn't be necessary to make it globally
visible. Making the overriding accident even less
likely.

Bye

[Jan Burse]

Jan Burse schrieb:

>> Once and infix declaration via op/3 is given, both notation
>> have to resort to standard behavior.
>
> Well the difference is well known. You
> can input:
>
> A :> B.
>
> And it gives :>(A,B).
>
> But you cannot input:
>
> A . B.
>
> It will not give .(A,B).

Well its a matter of layout characters. One
can input:

A.B

And it will give .(A,B). But if B starts with
a graphic character, then this is not anymore
possible, since the . and the graphic character
B will form a single token.

So if A.B is used to access fields or methods,
and B always starts with a letter, then there
is no problem. I admit.

[Jan Burse]

Jan Burse schrieb:

> hen problems can arrise. All books and posts
> about Prolog are invalidated, for example the
> following SO entry is rendered rubish for
> SWI 7:
>

Oops, forgot the link:
http://stackoverflow.com/questions/27001659/prolog-member-of-list/27007676#27007676

I don't really see what SWI-Prolog is offering
to mitigate this break of the codex. It says:

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/swi/Directions

How about SWI-Prolog and education?
In the long run we would like to establish
comprehensive tutorial material for
SWI-Prolog's extensions.

I don't think it is that easy to rewrite history.
For example the "learn Prolog now" text still uses
the dot to explain how list internally work:

Lists as terms
http://www.learnprolognow.org/lpnpage.php?pagetype=html&pageid=lpn-htmlse38

One cannot break the codex and sell it as an
extension. And then expect the history rewrites
itself.

As long as a Prolog system provides =../2 one can
possibly not make the list constructor fully opaque.
One could possibly also introduce a Prolog flag,
telling the list constructor. This would be
a more proper solution.

But how confusing would the "learn Prolog now"
look like then? Just a footnote, BTW in some
Prolog systems the dot is replaced by [|]? And
this doesn't matter as long as one uses the
list notation solely and doesn't read canonical
terms with the dot? Maybe this is what
will happen.

Bye

[Jan Burse]

Jan Burse schrieb:

>
> I don't think it is that easy to rewrite history.
> For example the "learn Prolog now" text still uses
> the dot to explain how list internally work:
>
> Lists as terms
> http://www.learnprolognow.org/lpnpage.php?pagetype=html&pageid=lpn-htmlse38

And this is what I get on the SWISH version of LNP:

.(a,[]) == [a].

Arguments are not sufficiently instantiated

'[|]'(a,[]) == [a].
true

http://lpn.swi-prolog.org/lpnpage.php?pagetype=html&pageid=lpn-htmlse38

The web site says also: "Also Learn Prolog Now! needs
some updating to be more compatible with SWI-Prolog."

Woa! I think its the other way around, via some flags
or what ever SWI should adapt to Learn Prolog Now, so
that the examples run correctly.

Bye

[Ulrich Neumerkel]

There is another condition: And A and B do not
happen to be operators.

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

>> >So if A.B is used to access fields or methods,
>> >and B always starts with a letter, then there
>> >is no problem. I admit.

> There is another condition: And A and B do not
> happen to be operators.

Why should this be relevant here?

Third condition: The computer is switched on.

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:
>>> >So if A.B is used to access fields or methods,
>>> >and B always starts with a letter, then there
>>> >is no problem. I admit.
>
>> There is another condition: And A and B do not
>> happen to be operators.
>
>Why should this be relevant here?

To be a valid syntax extension, the extension must only use
otherwise invalid Prolog text.

The dot-notation might be seen as an extension as long as no
corresponding op declaration is present. Now consider the
Prolog text:

fx.xf.

with fx and xf defined as operators. So this is valid
Prolog text that would be given a different meaning.

Therefore the requirement that fx and xf are not
operators.

>Third condition: The computer is switched on.

Out of scope. See 1 Scope - in particular Note c.

[Jan Burse]

Jan Burse schrieb:

>> There is another condition: And A and B do not
>> happen to be operators.
>
> Why should this be relevant here?
>
> Third condition: The computer is switched on.
>

Its not relevant since I am assuming that

A.B

gives already .(A,B) when parsing.

Question is only whether

A . B

Gives the same.

If B is or isn't an operator doesn't matter.
The Prolog reader will anyway not read past
the terminating period.

This problem does not happen for :> . It is
not that :> terminates a line if it is followed
by a layout character, a new line or the percent
sign (%).

On the other hand the period has this property,
so most likely . isn't really meant to become
an infix operator in Prolog. But I don't known
the true story.

Apparently in some places . was used as an
infix operator already in the past. But it didn't
undergo a semantic shift. For example the
. is used as an infix operator here:


ISO/IEC 13211-1:1995(E)
Annex
A Formal semantics

For example in the following line:

D-term-to-predication(V, func(call, V.nil)) <=
L-var(V).

But when the period is use in the above line,
it is still used as the cons operator for
lists.

Bye

P.S.: The above is a funny error of Annex A.
I don't think Prolog heads are call wrapped.
At least I don't see this in GNU Prolog:

GNU Prolog 1.4.4 (64 bits) Compiled Apr 23 2013
Copyright (C) 1999-2013 Daniel Diaz

?- [user].
compiling user for byte code...
A :- B.
user:1: fatal error: head is a variable


Bye

[Jan Burse]

Jan Burse schrieb:

> P.S.: The above is a funny error of Annex A.
> I don't think Prolog heads are call wrapped.
> At least I don't see this in GNU Prolog:

It is also not fixed by the following note:

NOT -- D-is-a-clause (D-is-a-body) define
what is a well-formed term clause (term goal),
or convertible in the sense of 7.6.

The above wouldn't allow variables in the body
that are wrapped at all.

[Jan Burse]

Jan Burse schrieb:

> Its not relevant since I am assuming that
>
> A.B
>
> gives already .(A,B) when parsing.
>
> Question is only whether
>
> A . B
>
> Gives the same.

And vice versa. Assuming A . B would give
.(A,B). For :> we would know the result.

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

> The dot-notation might be seen as an extension as long as no
> corresponding op declaration is present. Now consider the
> Prolog text:
>
> fx.xf.
>
> with fx and xf defined as operators. So this is valid
> Prolog text that would be given a different meaning.

This is actually invalid Prolog text, possibly also
according to ISO (if I take GNU Prolog as the
relevant system for the ISO syntax).

GNU Prolog:
?- op(100,fx,fx).
?- op(100,xf,xf).
?- op(100,yfx,.).
?- write_canonical(a.b).
'.'(a,b)
?- write_canonical(fx.xf).
uncaught exception: error(syntax_error('...
current or previous operator needs brackets'),read_term/3)


Jekejeke Prolog:
?- op(100,fx,fx).
?- op(100,xf,xf).
?- op(100,yfx,.).
?- write_canonical(a.b).
'.'(a,b).
?- write_canonical(fx.xf).
Error: Term missing.
write_canonical(fx.xf).
^

It is accepted by SWI-Prolog because SWI-Prolog has
a more tollerant parser.

Bye

[Jan Burse]

Jan Burse schrieb:

> It is accepted by SWI-Prolog because SWI-Prolog has
> a more tollerant parser.

Not sure what is exactly going on here. Not sure
whether the same phaenomena would be seen for :>
and some fx and xf argument.

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:
>> The dot-notation might be seen as an extension as long as no
>> corresponding op declaration is present. Now consider the
>> Prolog text:
>>
>> fx.xf.
>>
>> with fx and xf defined as operators. So this is valid
>> Prolog text that would be given a different meaning.
>
>This is actually invalid Prolog text, possibly also
>according to ISO (if I take GNU Prolog as the
>relevant system for the ISO syntax).
>
> GNU Prolog:
> ?- op(100,fx,fx).
> ?- op(100,xf,xf).
> ?- op(100,yfx,.).

Please reread: This is with fx and xf as operators but
not . as operator!

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

>> This is actually invalid Prolog text, possibly also
>> >according to ISO (if I take GNU Prolog as the
>> >relevant system for the ISO syntax).
>> >
>> > GNU Prolog:
>> > ?- op(100,fx,fx).
>> > ?- op(100,xf,xf).
>> > ?- op(100,yfx,.).
> Please reread: This is with fx and xf as operators but
> not . as operator!

Who cares about . not as an operator in this thread?
When you work with SWI-Prolog 7, you have .
automatically as an operator. Look see:

Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version 7.1.31)
Copyright (c) 1990-2014 University of Amsterdam, VU Amsterdam

?- current_op(X,Y,.).
X = 100,
Y = yfx.


Could you please enlighten us, when you say fx.xf is
a valid text, and related to problems of parsing
A . B respectively A.B, were we supposedly have . as
an operator defined?

I am perplexed. Were you simply saying that A.B can
be also parsed when A and B are operators AND . is
not an operator. How does this relate to the problem
of what happens when . is an operator?

Bye

[Jan Burse]

Jan Burse schrieb:

> How does this relate to the problem
> of what happens when . is an operator?

Its a counterexample to saying A.B and A . B
can have different parsing. Due to . defined
as an operator.

A.B and A . B can also have different parsing
when fx and xf have operator definitions and
. is used as an atom without any operator
definition.

Oki, Doki accepted.

But still when I say one should not use
. in text I mean of course:
- Not as an operator.
- Not as an atom in an unescaped position.
(For example using (.) would be ok,
some systems display it as '.' and
some as ('.')) (*)

So SWI-Prolog 7 violates only part of the
above advice. But it violates it. Thats
a fact.

Bye

(*)

Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version 7.1.31)
Copyright (c) 1990-2014 University of Amsterdam, VU Amsterdam

?- X = '.'.
X = ('.').

?- X = (.).
X = ('.').

GNU Prolog 1.4.4 (64 bits)

Copyright (C) 1999-2013 Daniel Diaz

?- X = '.'.
X = '.'

?- X = (.).
X = '.'

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:
>>> This is actually invalid Prolog text, possibly also
>>> >according to ISO (if I take GNU Prolog as the
>>> >relevant system for the ISO syntax).
>>> >
>>> > GNU Prolog:
>>> > ?- op(100,fx,fx).
>>> > ?- op(100,xf,xf).
>>> > ?- op(100,yfx,.).
>> Please reread: This is with fx and xf as operators but
>> not . as operator!
>
>Who cares about . not as an operator in this thread?

See http://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and_ISO#adding_conforming_dot

you cited above at the beginning of this thread so I assumed
you read it.

The point is that the particular meaning of . in SWI is not
conforming as long as . is declared as an infix operator.
But if it is not declared an operator the Prolog text
in question would be invalid. So there is a chance
to sneak in such behaviour as an extension.

(Of course this is quite independent of the choice in SWI to
use a new, incompatible, name for the list constructor.)

That is the same approach that SICStus 4.3 took to handle
the infix bar: If '|' is not declared as an infix, an
expression using it as infix is invalid, and thus it is
an extension that now a|b. is read as a;b.

Otherwise, if '|' is declared an infix, one gets standard
behavior.

https://sicstus.sics.se/sicstus/docs/latest4/html/relnotes.html/4_002e3_002e0-Standard-Conformance-Changes.html#4_002e3_002e0-Standard-Conformance-Changes

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

> But if it is not declared an operator the Prolog text
> in question would be invalid.

That is your problem Ulrich. You are always thinking
in terms of syntax and not in terms of semantic.

If SWI-7 accepts a Prolog text, it doesn't mean
it does the right thing.

If SWI-7 accepts [H|T], but represents it internally
as '[|]'(H,T) then this doesn't conform to

6.3.5 Compound terms - list notation
List notation can be used for inputting or outputting a
compound term with principal functor '.'/2 (dot).

> But if it is not declared an operator the Prolog text
> in question would be invalid. So there is a chance
> to sneak in such behaviour as an extension.

You see above. Wrong thinking. You think if
something doesn't exist ob the syntax level
it doesn't exist on the semantic level.

> (Of course this is quite independent of the choice in SWI to
> use a new, incompatible, name for the list constructor.)

Well that is the main issue of this thread, and
not only the syntax. The main issue is syntax AND
semantic of the SWI-7 release.

>> Who cares about . not as an operator in this thread?
>
> See http://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and_ISO#adding_conforming_dot
>
> you cited above at the beginning of this thread so I assumed
> you read it.

Yes I read it. And I gave already the response:

Jan Burse wrote 27.02.2015 02:45:
> Wouldn't another syntax also do, for example a :> f to access
> a field? The :> would be defined via function expansion.

And I also gave reasons:

Jan Burse wrote 28.02.2015 12:52:
> I think dot-syntax would require rewriting Prolog parser/unparser
> and operator handling. And this is probably not viable, a lot of
> overhead for a small thing.
>

> The cheapest is just using another operator :> which doesn't
> have some special meaning already.

BTW: I don't have to read #adding_conforming_dot . I came
up with this idea myself in a old thread on comp.lang.prolog.
But I am regretting the idea now.

It is an expensive semantic idea, not worth considering,
since the problems of the dot itself on the syntax
surface are more severe.

As long as Prolog is a language where a dot with a layout
character, a new line or a percent acts as a line terminator
the dot should not be used inside a line.

In other Languages there is no such problem. For example
in Java one can write the dot how ever one wants to, the
following is all valid Java texts:

foo.bar; /* form 1 */
foo.
bar; /* form 2 */
foo
.bar; /* form 3 */

Interestingly form 2 is seldom seen. On the other hand
form 3 is often seen. And it would also Work in Prolog.
But nevertheless I wouldn't recommend using a dot
on the surface.

I must admit, the dot is very nice and readable, and
probably better than the :> . But if one wants the
dot I guess one has to invent a new language. This
is what Picat did. And we have also semantic rewriting
for the dot, but more elaborate:

Chapter 3
http://picat-lang.org/download/picat_guide.pdf

The dot operator (.) is used in OOP notations for
accessing attributes and for calling predicates
and functions. It is also used to qualify calls
with a module name. The notation A1.f(A2,...,Ak)
is the same as f(A1,A2,...,Ak), unless A1 is
an atom, in which case A1 must be a module qualifier
for f. If an atom needs to be passed as the first
argument to a function or a predicate, then this
notation cannot be used. The notation A:Attr,
where Attr does not have the form f(...),
is the same as the function call get(A; Attr).
For example, the expression S.name returns the
name, and the expression S.arity returns the
arity of S if S is a structure. Note that
the dot operator is left-associative. For
example, the expression X.f().g() is the same
as g(f(X)).

But I don't understand whether Picat has abandoned
the idea of having user defined operators. At least
I find in the doc no more op/3 directive. It could
be that Picat uses a custom parser. Since it also
details an extensive syntax in Appendix G.

My own proposal #adding_conforming_dot would be
suited for such things as Picat, since with this
proposal one wouldn't need a special syntax in
Appendix G and disallow op/3. One could just
rewrite $dot/2 in a function expansion. Namely
the Chapter 3 cases of Picat can possibly all dealt
with in a function expansion. No need for an
extensive syntax and a specialized parser.

But I guess Picat has a specialized parser,
since with Prolog operators we cannot model
"begin ... end" like syntaxes. See another post
of mine on comp.lang.prolog. We can also not
do mixfix with the ordinary Prolog operators,
or fxx which is for example found in Eclipse(*).
That it must have a specialized parser is seen
in the following syntax production:

enclosed_goal ->
"if" goal "then" goal
{"elseif" goal "then" goal} "else" goal "end"
"foreach" "(" iterator {","
(iterator | condition)} ")" goal "end"
"while" "(" goal ")" ["loop"] goal "end"
"loop" goal "while" "(" goal ")"
"try" goal catch_clause {catch_clause} ["finally" goal] "end"
expression {bin_rel_op expression}

But when there is a specialized parser,
possibly interleave with semantic processing,
there is again no need for $dot/2, there is
possibly anyway an AST that is a little remote
from the surface syntax.

So I think Picat does the right thing. It
offers the end-user:
- A dot operator, with a varied semantic
added value
- "begin ... end" like syntax in various
places
- Unfortunately Picat may also be subject
to the Problem of form 2: (**)
foo.
bar; /* form 2 */

But I don't see that the SWI-7 approach makes
any sense at all, except that it breaks the
ISO standard and tries to dictate a new Prolog
to the world, invalidating a rich stock of
Prolog history. Experiment failed!

Sorry, if there is too much bias against SWI-7
at the moment. Nobody could convince me yet
that it is a good thing to imitate as is.

Bye

(*)
I am currently going with an operator based
alternative to fxx. I am using a Curry lambda
expression with a prefix operator. So for example
the following is Prolog:

∀ x\(x ∈ a <=> x ∈ b)

Or with Church lambda expressions:

∀ y:u\(y ∈ {z} <=> z(y))

Very nice.

(**)
In other languages such as Java, the dot is usually
extremly ubiquitous. Such a thing always needs more
semantic processing, up to type systems etc..

In Jekejeke Prolog I am currently following the
approach of different syntactic operators for
different things. Mainly because of backward
compability and operator level reasons.

So the structured module name separator is
(/)/2 and not (.)/2. And the predicate qualification
separator is (:)/2 and not (.)/2. So what
reads in Jekejeke:

foo:bar/2
baz/foo:bar/2
foo:bar(x,y)
baz/foo:bar(x,y)

Reads in Java:

N/A (No predicate indicators in Java)
N/A (No predicate indicators in Java)
foo.bar(x,y)
baz.foo.bar(x,y)

Reads in Picat:

foo.bar/2
N/A (The picat baz.foo would be a getter,
and not a module path)
foo.bar(x,y)
N/A (The picat baz.foo would be a getter,
and not a module path)

[Jan Burse]

Jan Burse schrieb:

> BTW: I don't have to read #adding_conforming_dot . I came
> up with this idea myself in a old thread on comp.lang.prolog.
> But I am regretting the idea now.
>
> It is an expensive semantic idea, not worth considering,
> since the problems of the dot itself on the syntax
> surface are more severe.

BTW: The original post on comp.lang.prolog was
mainly meant as a joke, since the dot surface
problems are not addressed by it.

Kind of an Aprils fool joke. Wasn't it April then.

Bye

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

> expression using it as infix is invalid, and thus it is
> an extension that now a|b. is read as a;b.

Mostlikely this extension is possible, since
the ISO standard doesn't say what should happen
to a|b.

On the otherhand the ISO standard says what
should happen to [a|b]:

6.3.5 Compound terms - list notation
List notation can be used for inputting or outputting a
compound term with principal functor '.'/2 (dot).

So I still think in this respect SWI-7 is
not an extension, it breaks the codex.

Bye

[Ulrich Neumerkel]

The current SWI-7 is not conforming in this respect, indeed. I
hope that

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and_ISO

made this clear. However, with effectively minimal adaptations
it could be conforming.