info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
A proposal for resolving the ambiguity involving `ht sep` and `bar` in ISO/IEC 13211-1
82 views
Skip to first unread message
Michael Ben Yosef
May 22, 2018, 9:16:44 AM5/22/18
to
_ISO/IEC 13211-1:1995/Cor.2:2012_ added a new token called `bar` to the syntax.
This was to allow/clarify the possible usage of the symbol `|` as an operator,
whereas previously it was only defined as the token `ht sep`, the head tail
separator for list syntax. The Technical Corrigendum document is freely
viewable here, with the changes I'm referring to appearing near the beginning:
https://www.iso.org/obp/ui/#iso:std:iso-iec:13211:-1:ed-1:v1:cor:2:v1:en
Two years ago, I noticed that `bar` was not added to the `token (* 6.4 *)`
rule and asked a question on Stack Overflow about this:
https://stackoverflow.com/questions/36970473/why-did-technical-corrigendum-2-to-iso-iec-13211-11995-omit-bar-from-the-tok
User `false` answered and the issue was added to the _Draft for further
corrigenda_ - currently item 36:
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/stc
Quoting from that item:
"Solution: Add `bar` to `token (* 6.4 *)`. However, this leads to ambiguity,
since `ht sep (* 6.4 *)` describes the very same text as `bar (* 6.4 *)` So
further clarification would be required."
In other words whether `|` is `bar` or `ht sep` can only be determined by the
definition of terms (6.3), so that the definition of tokens (6.4) is
insufficient on its own, which is undesirable.
This is a simple proposal to address the ambiguity described.
Basically, I think TC2 need not have introduced a new token `bar`, but could
have explained the operator rules for `|` in terms of `ht sep`. The exemplar
is `comma`: The `comma (* 6.4 *)` token is interpreted either as an operator
(6.3.4.3) or as an argument separator in `arg list` (6.3.3) or `items` (6.3.5);
The rules of (6.3) make this unambiguous.
This proposal modifies TC2 as follows:
Replace the word "bar" in
A bar (6.4) shall be equivalent to the atom '|' when '|' is an operator.
and in the head of the syntax rule
op = bar ;
by "ht sep".
In note 1, instead of adding
Bar is also a solo character (6.5.3), and a token (6.4) but not an atom.
Add
Head tail separator is also a solo character (6.5.3), and, as `ht sep`, a
token (6.4) but not an atom.
Undo the additions of `bar`, `bar token` and `bar char` to 6.4, 6.4.8 and
6.5.3, respectively.
This proposal modifies TC3 as follows:
In the new clause 7.10.5 h) 1) replace
Operators ',' and '|' are output as , (comma char) and | (bar char)
respectively.
with
Operators ',' and '|' are output as , (comma char) and | (head tail
separator char) respectively.
I believe this proposal does not change the intended meaning of the syntax of
ISO/IEC 13211-1 (6.3 and 6.4). Moreover, I believe it does not introduce any
ambiguity, because the requirements that `ht sep` is not an atom and must have
priority greater than or equal to 1001 when used as an operator ensure that
`|` cannot occur in an `arg` (6.3.3.1) in such a way as to be confused with a
head tail speartor in the `items` of the list notation (6.3.5). (In much the
same way that `,` is also always unambiguous.)
This was to allow/clarify the possible usage of the symbol `|` as an operator,
whereas previously it was only defined as the token `ht sep`, the head tail
separator for list syntax. The Technical Corrigendum document is freely
viewable here, with the changes I'm referring to appearing near the beginning:
https://www.iso.org/obp/ui/#iso:std:iso-iec:13211:-1:ed-1:v1:cor:2:v1:en
Two years ago, I noticed that `bar` was not added to the `token (* 6.4 *)`
rule and asked a question on Stack Overflow about this:
https://stackoverflow.com/questions/36970473/why-did-technical-corrigendum-2-to-iso-iec-13211-11995-omit-bar-from-the-tok
User `false` answered and the issue was added to the _Draft for further
corrigenda_ - currently item 36:
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/stc
Quoting from that item:
"Solution: Add `bar` to `token (* 6.4 *)`. However, this leads to ambiguity,
since `ht sep (* 6.4 *)` describes the very same text as `bar (* 6.4 *)` So
further clarification would be required."
In other words whether `|` is `bar` or `ht sep` can only be determined by the
definition of terms (6.3), so that the definition of tokens (6.4) is
insufficient on its own, which is undesirable.
This is a simple proposal to address the ambiguity described.
Basically, I think TC2 need not have introduced a new token `bar`, but could
have explained the operator rules for `|` in terms of `ht sep`. The exemplar
is `comma`: The `comma (* 6.4 *)` token is interpreted either as an operator
(6.3.4.3) or as an argument separator in `arg list` (6.3.3) or `items` (6.3.5);
The rules of (6.3) make this unambiguous.
This proposal modifies TC2 as follows:
Replace the word "bar" in
A bar (6.4) shall be equivalent to the atom '|' when '|' is an operator.
and in the head of the syntax rule
op = bar ;
by "ht sep".
In note 1, instead of adding
Bar is also a solo character (6.5.3), and a token (6.4) but not an atom.
Add
Head tail separator is also a solo character (6.5.3), and, as `ht sep`, a
token (6.4) but not an atom.
Undo the additions of `bar`, `bar token` and `bar char` to 6.4, 6.4.8 and
6.5.3, respectively.
This proposal modifies TC3 as follows:
In the new clause 7.10.5 h) 1) replace
Operators ',' and '|' are output as , (comma char) and | (bar char)
respectively.
with
Operators ',' and '|' are output as , (comma char) and | (head tail
separator char) respectively.
I believe this proposal does not change the intended meaning of the syntax of
ISO/IEC 13211-1 (6.3 and 6.4). Moreover, I believe it does not introduce any
ambiguity, because the requirements that `ht sep` is not an atom and must have
priority greater than or equal to 1001 when used as an operator ensure that
`|` cannot occur in an `arg` (6.3.3.1) in such a way as to be confused with a
head tail speartor in the `items` of the list notation (6.3.5). (In much the
same way that `,` is also always unambiguous.)
burs...@gmail.com
May 22, 2018, 11:59:02 AM5/22/18
to
Well (|)/2 is an operator similar to (,)/2. But you can
easily get confused. The main point is in the production
rules for infix operator and postfix operator.
Where you would allow more atoms than in the rules for
compound functor. So that (|)/2 and (,)/2 can act as
deleminter in argument lists and normal lists.
The characters of (|)/2 and (,)/2 have double role,
namely they can be operators and they can be delemiters,
namely they their second role besides operator is:
- (|)/2 as delemiter:
in normal lists,
examples [a,b,c|d], [X|Y]
- (,)/2 as delemiter:
in argument lists and normal lists,
examples f(1,2), [a,b,c|d], [1,2]
But you don't need to touch any token rules. Especially
not any quoted token rules. You only need to touch the
heigher level production rules for infix, postfix,
and for the lists. This can be admitedly a challenge
to get the grammar right. But you can check implementations
for how they are doing it. Or their documentation.
So the following new production is already step forward:
op = bar ;
For example one might think this is the correct production
for expressions, thats actually the simple view:
expression(M) --> "(" term(1200) ")" { M=0 }
| op(M,fx) term(M-1)
| op(M,fy) term(M)
| term(M-1) op(M,xfx) term(M-1)
| term(M-1) op(M,xfy) term(M)
| term(M) op(M,yfx) term(M-1)
| term(M-1) op(M,xf)
| term(M) op(M,yf).
op(M,I) --> atom(O) { current_op(M,I,O) }.
Unfortunately this is also more or less the syntax
found in the good old DEC-10 Prolog manual. Just check
page 78 here:
Naive Syntax, already purported by DEC-10 Prolog
https://www.cs.cmu.edu/Groups/AI/lang/prolog/doc/intro/prolog.doc
But in my opinion, the more elaborate syntax reads
as follows, and gives better results. Namely there
are two types of operators:
expression(M) --> "(" term(1200) ")" { M=0 }
| op1(M,fx) term(M-1)
| op1(M,fy) term(M)
| term(M-1) op2(M,xfx) term(M-1)
| term(M-1) op2(M,xfy) term(M)
| term(M) op2(M,yfx) term(M-1)
| term(M-1) op2(M,xf)
| term(M) op2(M,yf).
op1(M,I) --> atom(O) { current_op(M,I,O) }.
op2(M,I) --> operator(O) { current_op(M,I,O) }.
operator --> atom
| "|" | "," | ".".
You can also add features. Like for example the array
index notation, which is available in a few Prolog
systems, like SWI-Prolog, Jekejeke Prolog, just use:
operator --> atom
| "[" arguments "]"
| "|" | "," | ".".
http://www.jekejeke.ch/idatab/doclet/prod/en/docs/05_run/10_docu/02_reference/06_syntax/02_term/04_expressions.html
But I guess the ISO standard is not up to adding
array index notation. But array index notation is
cute, you find it also in Picat, here is a SWI-Prolog
documentation about it:
Block operators
http://www.swi-prolog.org/pldoc/man?section=ext-blockop
So what is the bottomline of this post? Well I
say op = bar is a good idea. But upon reflection,
its also a bad idea. A much better idea would have
to have two ops, op1 for prefix and op2 for
infix and postfix, you can then do the following,
only add bar to op2:
op1 = ... ; /* as before */
op2 = ... /* as before */
| bar ; /* new addition, maybe */
Disclaimer: I didn't check the ISO/IEC document,
and gave a ready to use fix of the ISO/IEC document.
I only wanted to communicate that there are op1 and op2,
that this is one solution to fix the syntax problem.
Of course one can then redefine the syntax on paper,
but one can also directly implement it then as such.
easily get confused. The main point is in the production
rules for infix operator and postfix operator.
Where you would allow more atoms than in the rules for
compound functor. So that (|)/2 and (,)/2 can act as
deleminter in argument lists and normal lists.
The characters of (|)/2 and (,)/2 have double role,
namely they can be operators and they can be delemiters,
namely they their second role besides operator is:
- (|)/2 as delemiter:
in normal lists,
examples [a,b,c|d], [X|Y]
- (,)/2 as delemiter:
in argument lists and normal lists,
examples f(1,2), [a,b,c|d], [1,2]
But you don't need to touch any token rules. Especially
not any quoted token rules. You only need to touch the
heigher level production rules for infix, postfix,
and for the lists. This can be admitedly a challenge
to get the grammar right. But you can check implementations
for how they are doing it. Or their documentation.
So the following new production is already step forward:
op = bar ;
For example one might think this is the correct production
for expressions, thats actually the simple view:
expression(M) --> "(" term(1200) ")" { M=0 }
| op(M,fx) term(M-1)
| op(M,fy) term(M)
| term(M-1) op(M,xfx) term(M-1)
| term(M-1) op(M,xfy) term(M)
| term(M) op(M,yfx) term(M-1)
| term(M-1) op(M,xf)
| term(M) op(M,yf).
op(M,I) --> atom(O) { current_op(M,I,O) }.
Unfortunately this is also more or less the syntax
found in the good old DEC-10 Prolog manual. Just check
page 78 here:
Naive Syntax, already purported by DEC-10 Prolog
https://www.cs.cmu.edu/Groups/AI/lang/prolog/doc/intro/prolog.doc
But in my opinion, the more elaborate syntax reads
as follows, and gives better results. Namely there
are two types of operators:
expression(M) --> "(" term(1200) ")" { M=0 }
| op1(M,fx) term(M-1)
| op1(M,fy) term(M)
| term(M-1) op2(M,xfx) term(M-1)
| term(M-1) op2(M,xfy) term(M)
| term(M) op2(M,yfx) term(M-1)
| term(M-1) op2(M,xf)
| term(M) op2(M,yf).
op1(M,I) --> atom(O) { current_op(M,I,O) }.
op2(M,I) --> operator(O) { current_op(M,I,O) }.
operator --> atom
| "|" | "," | ".".
You can also add features. Like for example the array
index notation, which is available in a few Prolog
systems, like SWI-Prolog, Jekejeke Prolog, just use:
operator --> atom
| "[" arguments "]"
| "|" | "," | ".".
http://www.jekejeke.ch/idatab/doclet/prod/en/docs/05_run/10_docu/02_reference/06_syntax/02_term/04_expressions.html
But I guess the ISO standard is not up to adding
array index notation. But array index notation is
cute, you find it also in Picat, here is a SWI-Prolog
documentation about it:
Block operators
http://www.swi-prolog.org/pldoc/man?section=ext-blockop
So what is the bottomline of this post? Well I
say op = bar is a good idea. But upon reflection,
its also a bad idea. A much better idea would have
to have two ops, op1 for prefix and op2 for
infix and postfix, you can then do the following,
only add bar to op2:
op1 = ... ; /* as before */
op2 = ... /* as before */
| bar ; /* new addition, maybe */
Disclaimer: I didn't check the ISO/IEC document,
and gave a ready to use fix of the ISO/IEC document.
I only wanted to communicate that there are op1 and op2,
that this is one solution to fix the syntax problem.
Of course one can then redefine the syntax on paper,
but one can also directly implement it then as such.
Ulrich Neumerkel
May 22, 2018, 1:28:09 PM5/22/18
to
Michael Ben Yosef <mby...@gmail.com> writes:
>_ISO/IEC 13211-1:1995/Cor.2:2012_ added a new token called `bar` to the syntax.
...
>_ISO/IEC 13211-1:1995/Cor.2:2012_ added a new token called `bar` to the syntax.
>Basically, I think TC2 need not have introduced a new token `bar`, but could
>have explained the operator rules for `|` in terms of `ht sep`. The exemplar
>is `comma`: The `comma (* 6.4 *)` token is interpreted either as an operator
>(6.3.4.3) or as an argument separator in `arg list` (6.3.3) or `items` (6.3.5);
>The rules of (6.3) make this unambiguous.
...
>have explained the operator rules for `|` in terms of `ht sep`. The exemplar
>is `comma`: The `comma (* 6.4 *)` token is interpreted either as an operator
>(6.3.4.3) or as an argument separator in `arg list` (6.3.3) or `items` (6.3.5);
>The rules of (6.3) make this unambiguous.
The option to "reuse" `ht sep` was certainly discussed, but quite clearly
dismissed. Nobody calls | a `ht sep`. A head tail separator serves only
to separate head and tail. So it is not a name for the character itself, but
a name for the character used in a very limited context, namely in the context
of list notation (6.3.5).
Contrast this to comma, which has a lot of different uses prior to Prolog and
within Prolog syntax.
In any case, neither the change sketched in stc nor your suggested change
would change anything observable. So this appears to be of rather
minor importance. IF (repeat: if) this should be handled more uniformly,
`ht sep` should rather be renamed to `bar`, as `bar` is a name that does
not imply a specific usage ; or at least does not imply one of both
usages in Prolog syntax.
burs...@gmail.com
May 22, 2018, 4:28:43 PM5/22/18
to
Ulrich Neumerkel wrote:
"You are suggesting using Prolog to store the data. That means,
that a conforming system is needed to read such facts. One more
link in the chain to break."
To the best of my knowledge, this is not a great
obstacle. For example if you test reading, you can
place your test case into Prolog atom:
Here is a test case for with the vertical bar in it:
runner:case(read, 1, stream_read, 'ISO 6.3.3.1, XLOG 4') :-
catch(with_input_from(atom('X = |.'), read(_)), error(E,_), true),
E == syntax_error(cannot_start_term).
https://github.com/jburse/jekejeke-samples/blob/master/jekdev/compliance/stream/read.p#L153
"You are suggesting using Prolog to store the data. That means,
that a conforming system is needed to read such facts. One more
link in the chain to break."
To the best of my knowledge, this is not a great
obstacle. For example if you test reading, you can
place your test case into Prolog atom:
Here is a test case for with the vertical bar in it:
runner:case(read, 1, stream_read, 'ISO 6.3.3.1, XLOG 4') :-
catch(with_input_from(atom('X = |.'), read(_)), error(E,_), true),
E == syntax_error(cannot_start_term).
https://github.com/jburse/jekejeke-samples/blob/master/jekdev/compliance/stream/read.p#L153
burs...@gmail.com
May 22, 2018, 4:36:21 PM5/22/18
to
For the harness, the with_input_from/2 predicate,
using memory files was suggested by cc.car...@gmail.com
in 2014, see this thread here:
What about a with_input_from/2 predicate?
https://groups.google.com/d/msg/comp.lang.prolog/ex6NocEqoC0/nJqOCN7pC84J
The Java solution doesn't need free_memory_file(Handle),
the blob goes away by the usual Java Garbage collection.
But how with_input_from/2 is
implememted is anyway a black box. This can change
from Prolog system to Prolog system, and from
platform to platform.
using memory files was suggested by cc.car...@gmail.com
in 2014, see this thread here:
What about a with_input_from/2 predicate?
https://groups.google.com/d/msg/comp.lang.prolog/ex6NocEqoC0/nJqOCN7pC84J
The Java solution doesn't need free_memory_file(Handle),
the blob goes away by the usual Java Garbage collection.
But how with_input_from/2 is
implememted is anyway a black box. This can change
from Prolog system to Prolog system, and from
platform to platform.
Michael Ben Yosef
May 23, 2018, 2:09:23 AM5/23/18
to
On Tuesday, 22 May 2018 19:28:09 UTC+2, Ulrich Neumerkel wrote:
> [...]
> [...]
>
> In any case, neither the change sketched in stc nor your suggested change
> would change anything observable. So this appears to be of rather
> minor importance. IF (repeat: if) this should be handled more uniformly,
> `ht sep` should rather be renamed to `bar`, as `bar` is a name that does
> not imply a specific usage ; or at least does not imply one of both
> usages in Prolog syntax.
Fair enough.
> In any case, neither the change sketched in stc nor your suggested change
> would change anything observable. So this appears to be of rather
> minor importance. IF (repeat: if) this should be handled more uniformly,
> `ht sep` should rather be renamed to `bar`, as `bar` is a name that does
> not imply a specific usage ; or at least does not imply one of both
> usages in Prolog syntax.
burs...@gmail.com
May 23, 2018, 4:22:39 AM5/23/18
to
If you use Ulrichs notion of observable, you will
have to test whether some top-level waits. Ha Ha
You will never manage to make a grammar.
have to test whether some top-level waits. Ha Ha
You will never manage to make a grammar.
burs...@gmail.com
May 23, 2018, 4:18:30 PM5/23/18
to
Tau Prolog has also done it "wrongly", lets say they
have copied the DEC-10 syntax in some way, and ivented
a comma handling. See also here:
Tau Prolog, Grammar specification
Jose A. Riaza Miguel Riaza - March 30, 2018
http://tau-prolog.org/files/doc/grammar-specification.pdf
But their grammar is interesting, maybe this is
another candidate. Instead of op1 and op2, they
have a comma parameter somewhere. Their Grammar
reads roughly, not showing the comma parameter:
(Exprn) --> op(fx,n) (Exprn-1)
op(fy,n) (Exprn)
(Exprn-1) op(xf,n)
(Exprn) op(yf,n)
(Exprn-1) op(xfx,n) (Exprn-1)
(Exprn-1) op(xfy,n) (Exprn)
(Exprn) op(yfx,n) (Exprn-1)
(Exprn-1)
But op1 and op2 is much simpler than a comma
operator that modifies the atom syntax. Instead
of restricting the atom syntax, op2 enlarges the
atom syntax for operators.
For Tau Prolog, '|' is neither predefined as
an operator, nor can it be defined as an operator.
The predefined operator is needed, for example
there is a SICStus Syntax and for DCG.
This all doesn't work as of yet, here is a
sample sandbox session:
http://tau-prolog.org/sandbox/
:-op(400,xfx,foo).
:-op(400,xfx,'|').
?- X = (1 | 2).
error parsing query: error(syntax_error(line(1), column(8), found('|'), cause(', or ) expected')))
?- X = 1 | 2.
error parsing query: error(syntax_error(line(1), column(7), found('|'), cause('. or expression expected')))
?- X = 1 foo 2.
X = foo(1, 2) ;
In most Prolog systems the operator '|' is predefined,
and can be readily used. Namely we find:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- X = (1 | 2).
X = (1| 2).
?- current_op(X,Y,'|').
X = 1105,
Y = xfy.
Or here:
Jekejeke Prolog 2, Runtime Library 1.2.3
(c) 1985-2018, XLOG Technologies GmbH, Switzerland
?- X = (1 | 2).
X = (1|2)
?- current_op(X,Y,'|').
X = 1105,
Y = xfy
have copied the DEC-10 syntax in some way, and ivented
a comma handling. See also here:
Tau Prolog, Grammar specification
Jose A. Riaza Miguel Riaza - March 30, 2018
http://tau-prolog.org/files/doc/grammar-specification.pdf
But their grammar is interesting, maybe this is
another candidate. Instead of op1 and op2, they
have a comma parameter somewhere. Their Grammar
reads roughly, not showing the comma parameter:
(Exprn) --> op(fx,n) (Exprn-1)
op(fy,n) (Exprn)
(Exprn-1) op(xf,n)
(Exprn) op(yf,n)
(Exprn-1) op(xfx,n) (Exprn-1)
(Exprn-1) op(xfy,n) (Exprn)
(Exprn) op(yfx,n) (Exprn-1)
(Exprn-1)
But op1 and op2 is much simpler than a comma
operator that modifies the atom syntax. Instead
of restricting the atom syntax, op2 enlarges the
atom syntax for operators.
For Tau Prolog, '|' is neither predefined as
an operator, nor can it be defined as an operator.
The predefined operator is needed, for example
there is a SICStus Syntax and for DCG.
This all doesn't work as of yet, here is a
sample sandbox session:
http://tau-prolog.org/sandbox/
:-op(400,xfx,foo).
:-op(400,xfx,'|').
?- X = (1 | 2).
error parsing query: error(syntax_error(line(1), column(8), found('|'), cause(', or ) expected')))
?- X = 1 | 2.
error parsing query: error(syntax_error(line(1), column(7), found('|'), cause('. or expression expected')))
?- X = 1 foo 2.
X = foo(1, 2) ;
In most Prolog systems the operator '|' is predefined,
and can be readily used. Namely we find:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- X = (1 | 2).
X = (1| 2).
?- current_op(X,Y,'|').
X = 1105,
Y = xfy.
Or here:
Jekejeke Prolog 2, Runtime Library 1.2.3
(c) 1985-2018, XLOG Technologies GmbH, Switzerland
?- X = (1 | 2).
X = (1|2)
?- current_op(X,Y,'|').
X = 1105,
Y = xfy
burs...@gmail.com
May 23, 2018, 4:25:50 PM5/23/18
to
Well I think some system helped themselves in the
past by just mapping '|' to ';'. One could even
enter open lists as [A;B] instead of [A|B]. Not
sure whether this was or is still the case in
SICStus Prolog, but there is a mention of
the vertical bar here:
https://sicstus.sics.se/sicstus/docs/4.3.1/html/sicstus/mpg_002dref_002dor.html
BTW, in both systems, the '|' operator is not
simply mapped to ';'. Check for yourself:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- X = (1|2), write_canonical(X), nl.
'|'(1,2)
X = (1| 2).
And also:
Jekejeke Prolog 2, Runtime Library 1.2.6
'|'(1,2)
X = (1|2)
past by just mapping '|' to ';'. One could even
enter open lists as [A;B] instead of [A|B]. Not
sure whether this was or is still the case in
SICStus Prolog, but there is a mention of
the vertical bar here:
https://sicstus.sics.se/sicstus/docs/4.3.1/html/sicstus/mpg_002dref_002dor.html
BTW, in both systems, the '|' operator is not
simply mapped to ';'. Check for yourself:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
'|'(1,2)
X = (1| 2).
And also:
Jekejeke Prolog 2, Runtime Library 1.2.6
(c) 1985-2018, XLOG Technologies GmbH, Switzerland
?- X = (1|2), write_canonical(X), nl.
'|'(1,2)
X = (1|2)
burs...@gmail.com
May 23, 2018, 5:15:52 PM5/23/18
to
With the comma parameter in the production as Tau
Prolog does it, or with some other method. You can
implement a more lax handling of the vertical bar.
My proposal op1 and op2 does not include this
more lax handling of the vertical bar. This more
lax handling of the vertical bar, is for example
seen in ECLiPSe Prolog:
ECLiPSe Constraint Logic Programming System [kernel threads]
Version 7.0 #36 (x86_64_nt), Sun Jan 28 10:18 2018
[eclipse 1]: X = (1|2).
X = (1 | 2)
Yes (0.00s cpu)
[eclipse 2]: X = (1|2), write_canonical(X).
|(1, 2)
X = (1 | 2)
Yes (0.00s cpu)
[eclipse 3]: X = |(1,2).
X = (1 | 2)
Yes (0.00s cpu)
So basically ECLiPSe tolerates the vertical
bar as a functor. This is a little dangerous,
tolerating a delemiter as a functor. So SWI-Prolog
forbids it:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- X = (1|2).
X = (1| 2).
?- X = (1|2), write_canonical(X).
ERROR: Syntax error: Operand expected, unquoted comma or bar found
ERROR: X =
ERROR: ** here **
ERROR: |(1,2) .
I do also not tolerate it, according to my
op1 and op2 syntax, as can be seen here:
?- X = (1|2).
X = (1|2)
Error: Term missing.
X = |(1,2).
^
Actually the op1 and op2 syntax depends on
an atom syntax. Which in turn depends on a
name syntax. And this is all on another page
in the docu. But you see here how these
delemiters are forbidden in names:
name --> delimiter except "(", "{", "[",
"]", "}", ")", ",", "|"
| lower { alpha | digit }
| graphic { graphic } except "."
| str_single.
http://www.jekejeke.ch/idatab/doclet/prod/en/docs/05_run/10_docu/02_reference/06_syntax/01_token/03_words.html
The "except" in the is a new EBNF constructor. I
don't know whether this is in comment use. Its like
a not DCG condition. The ISO core standard defines
also its own EBNF (Extended Backus Naur Form),
you find this in Table 3 - BS6154 syntactic metalanguage
of the ISO core standard. In the above I use
an execpt in the syntactic metalanguage.
BS6154 seems now to be ISO/IEC 14977:
https://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf
This is just a speculation, I have no idea what
BS6154 is and what ISO/IEC 14977 is. At least the
authors of the ISO core standard must have
have had an idea of BS6154, since they mentioned it.
Am Mittwoch, 23. Mai 2018 22:25:50 UTC+2 schrieb burs...@gmail.com:
> Well I think some system helped themselves in the
> past by just mapping '|' to ';'. One could even
> enter open lists as [A;B] instead of [A|B]. Not
>
> sure whether this was or is still the case in
> SICStus Prolog, but there is a mention of
> the vertical bar here:
> https://sicstus.sics.se/sicstus/docs/4.3.1/html/sicstu/mpg_002dref_002dor.html
Prolog does it, or with some other method. You can
implement a more lax handling of the vertical bar.
My proposal op1 and op2 does not include this
more lax handling of the vertical bar. This more
lax handling of the vertical bar, is for example
seen in ECLiPSe Prolog:
ECLiPSe Constraint Logic Programming System [kernel threads]
Version 7.0 #36 (x86_64_nt), Sun Jan 28 10:18 2018
[eclipse 1]: X = (1|2).
X = (1 | 2)
Yes (0.00s cpu)
[eclipse 2]: X = (1|2), write_canonical(X).
|(1, 2)
X = (1 | 2)
Yes (0.00s cpu)
[eclipse 3]: X = |(1,2).
X = (1 | 2)
Yes (0.00s cpu)
So basically ECLiPSe tolerates the vertical
bar as a functor. This is a little dangerous,
tolerating a delemiter as a functor. So SWI-Prolog
forbids it:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- X = (1|2).
X = (1| 2).
'|'(1,2)
X = (1| 2).
?- X = |(1,2).
X = (1| 2).
ERROR: Syntax error: Operand expected, unquoted comma or bar found
ERROR: X =
ERROR: ** here **
ERROR: |(1,2) .
I do also not tolerate it, according to my
op1 and op2 syntax, as can be seen here:
?- X = (1|2).
X = (1|2)
?- X = (1|2), write_canonical(X), nl.
'|'(1,2)
X = (1|2)
?- X = |(1,2).
'|'(1,2)
X = (1|2)
Error: Term missing.
X = |(1,2).
^
Actually the op1 and op2 syntax depends on
an atom syntax. Which in turn depends on a
name syntax. And this is all on another page
in the docu. But you see here how these
delemiters are forbidden in names:
name --> delimiter except "(", "{", "[",
"]", "}", ")", ",", "|"
| lower { alpha | digit }
| graphic { graphic } except "."
| str_single.
http://www.jekejeke.ch/idatab/doclet/prod/en/docs/05_run/10_docu/02_reference/06_syntax/01_token/03_words.html
The "except" in the is a new EBNF constructor. I
don't know whether this is in comment use. Its like
a not DCG condition. The ISO core standard defines
also its own EBNF (Extended Backus Naur Form),
you find this in Table 3 - BS6154 syntactic metalanguage
of the ISO core standard. In the above I use
an execpt in the syntactic metalanguage.
BS6154 seems now to be ISO/IEC 14977:
https://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf
This is just a speculation, I have no idea what
BS6154 is and what ISO/IEC 14977 is. At least the
authors of the ISO core standard must have
have had an idea of BS6154, since they mentioned it.
Am Mittwoch, 23. Mai 2018 22:25:50 UTC+2 schrieb burs...@gmail.com:
> Well I think some system helped themselves in the
> past by just mapping '|' to ';'. One could even
> enter open lists as [A;B] instead of [A|B]. Not
>
> sure whether this was or is still the case in
> SICStus Prolog, but there is a mention of
> the vertical bar here:
burs...@gmail.com
May 23, 2018, 5:20:46 PM5/23/18
to
Ok, interesting, my bad, the standard ISO/IEC 14977
defines an "except" construct. Namely you simply find:
- except-symbol
4.7 Syntactic exception
So one would possibly write:
name --> delimiter - ("(" | "{" | "[" |
"]" | "}" | ")" | "," | "|")
| lower { alpha | digit }
| graphic { graphic } - "."
| str_single.
Just check page 1 and page 2 of the standard here:
https://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf
But the above standard is from 1996. This was
one year after the Prolog ISO core standard, so
it was possibly not yet available. Oki Doki
defines an "except" construct. Namely you simply find:
- except-symbol
4.7 Syntactic exception
So one would possibly write:
name --> delimiter - ("(" | "{" | "[" |
"]" | "}" | ")" | "," | "|")
| lower { alpha | digit }
| graphic { graphic } - "."
| str_single.
Just check page 1 and page 2 of the standard here:
https://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf
But the above standard is from 1996. This was
one year after the Prolog ISO core standard, so
it was possibly not yet available. Oki Doki
burs...@gmail.com
May 23, 2018, 5:22:07 PM5/23/18
to
The standard is even still alive:
ISO/IEC 14977:1996
This standard was last reviewed and confirmed
in 2018. Therefore this version remains current.
https://www.iso.org/standard/26153.html
So guys, use it, if you want to exclude
something. Ha Ha
ISO/IEC 14977:1996
This standard was last reviewed and confirmed
in 2018. Therefore this version remains current.
https://www.iso.org/standard/26153.html
So guys, use it, if you want to exclude
something. Ha Ha
ken...@gmail.com
May 24, 2018, 4:38:14 AM5/24/18
to
How do I purchase the latest ISO-Prolog standards? How do I pay 58 CHF?
Ulrich Neumerkel
May 24, 2018, 5:20:33 AM5/24/18
to
ken...@gmail.com
May 24, 2018, 5:41:46 AM5/24/18
to
Thank you.
I would like to read the full documents.
How should I do?
Kenichi Sasagawa
I would like to read the full documents.
How should I do?
Kenichi Sasagawa
Ulrich Neumerkel
May 24, 2018, 6:12:21 AM5/24/18
to
Go to some standardization body webstore. Maybe your national
member body is the best to start with. It might be cheapest for
you. For many, even non-US individuals,
https://webstore.ansi.org/ is a good start.
There, search for 13211-1:1995 - currently the part 1 of the
standard is:
ISO/IEC 13211-1:1995 USD 232
BS ISO/IEC 13211-1:1995 USD 503
INCITS/ISO/IEC 13211-1:1995 USD 116
They are all the same document, with a different cover sheet.
The INCITS document is cheapest, but it used to be USD 60, and
before that USD 30 and even cheaper before that ...
Then, you need the corrigenda. They are free (see SO-link). You may
be interested in the drafts for those (as they are linkable):
http://www.complang.tuwien.ac.at/ulrich/iso-prolog/#Cor.2
http://www.complang.tuwien.ac.at/ulrich/iso-prolog/#Cor.3
More information is on above page.
ken...@gmail.com
May 24, 2018, 7:09:28 AM5/24/18
to
Thank you very much.
Kenichi Sasagawa
Kenichi Sasagawa
burs...@gmail.com
May 24, 2018, 8:22:09 AM5/24/18
to
The operating result of ISO for 2016 was
5'868'000.- CHF. See here:
https://www.iso.org/files/live/sites/isoorg/files/about%20ISO/annual_reports/en/annual_report_2016_en.pdf
So I guess they could lower their prices.
Ha Ha. Or not? A little reserve funds
is never a bad idea...
5'868'000.- CHF. See here:
https://www.iso.org/files/live/sites/isoorg/files/about%20ISO/annual_reports/en/annual_report_2016_en.pdf
So I guess they could lower their prices.
Ha Ha. Or not? A little reserve funds
is never a bad idea...
Ulrich Neumerkel
May 24, 2018, 9:51:48 AM5/24/18
to
burs...@gmail.com writes:
>Tau Prolog has also done it "wrongly", lets say they
>have copied the DEC-10 syntax in some way, and ivented
>a comma handling. See also here:
>
>Tau Prolog, Grammar specification
>Jose A. Riaza Miguel Riaza - March 30, 2018
>http://tau-prolog.org/files/doc/grammar-specification.pdf
>
>But their grammar is interesting, maybe this is
>another candidate.
Note that Tau Prolog does not support canonical syntax. You cannot
>Tau Prolog has also done it "wrongly", lets say they
>have copied the DEC-10 syntax in some way, and ivented
>a comma handling. See also here:
>
>Tau Prolog, Grammar specification
>Jose A. Riaza Miguel Riaza - March 30, 2018
>http://tau-prolog.org/files/doc/grammar-specification.pdf
>
>But their grammar is interesting, maybe this is
>another candidate.
write the atom of a prefix and infix operator just as an atom.
That is, with "priority 1201 rather than the normal 0. (6.3.1.3 Atoms)".
?- - .
Answer: error parsing query: error(syntax_error(line(1), column(3), found('.'), cause(unexpected token)))
?- X = (:-).
Answer: error parsing query: error(syntax_error(line(1), column(8), found(')'), cause(unexpected token)))
?- var(\+).
Answer: error parsing query: error(syntax_error(line(1), column(7), found(')'), cause(unexpected token)))
?- sort([?-],L).
error parsing query: error(syntax_error(line(1), column(7), found('?-'), cause('] expected')))
burs...@gmail.com
May 24, 2018, 10:02:51 AM5/24/18
to
Ok, yes, this can be tricky to implement. But is of
great benefit for the end user. Not only can
the end user do your example here:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- X = (:-)
X = (:-).
Which I have already named "Operator Escaping",
but which is not named like that in the ISO
core standard. Whats also very hand:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- op(600, fx, *).
true.
?- X = *A.
X = *A.
So you do not need to do operator escaping all
the time, and write op(600, fx, (*)), if the
context allows you can write op(600, fx, (*)).
Did you test operator escapting writing in Tau Prolog?
Like this test case?
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.
?- atom_codes(X, [58, 45]).
X = (:-).
I get the following in Tau Prolog:
?- atom_codes(X, [58, 45]).
X = ':-' ;
?- X = ':-'
So I guess putting quotes around the atom doesn't
work as an alternative solution to operator escaping
in Tau Prolog. It can happen that you write some term,
but you cannot re-read it.
great benefit for the end user. Not only can
the end user do your example here:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
X = (:-).
Which I have already named "Operator Escaping",
but which is not named like that in the ISO
core standard. Whats also very hand:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.14)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
true.
?- X = *A.
X = *A.
So you do not need to do operator escaping all
the time, and write op(600, fx, (*)), if the
context allows you can write op(600, fx, (*)).
Did you test operator escapting writing in Tau Prolog?
Like this test case?
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
?- atom_codes(X, [58, 45]).
X = (:-).
I get the following in Tau Prolog:
?- atom_codes(X, [58, 45]).
X = ':-' ;
?- X = ':-'
error parsing query: error(syntax_error(line(1), column(7),
token_not_found, cause('. or expression expected')))
So I guess putting quotes around the atom doesn't
work as an alternative solution to operator escaping
in Tau Prolog. It can happen that you write some term,
but you cannot re-read it.
burs...@gmail.com
May 24, 2018, 10:07:43 AM5/24/18
to
Corr.:
context allows you can write op(600, fx, *).
context allows you can write op(600, fx, *).
Ulrich Neumerkel
May 24, 2018, 10:33:50 AM5/24/18
to
There are several situations where an operator atom can be written
as a regular atom. Namely:
On the top as Prolog clause (6.2.1.2) or Prolog data (6.2.2).
Example: - .
As an argument of a compound term (6.3.3.1)
Example: f(-).
When overriding the priority of operators with round brackets (6.3.4.1)
Example: X = (-).
As an element using list notation, and as the rest of such (6.3.5)
Example: L = [-].
L = [_|-].
As the argument of a curly bracketed term (6.3.6).
Example: {-}.
All of the above examples produce roughly the same syntax error in
Tau Prolog. And yes, taking your example, you can get locked in by
a further operator declaration
:- op(600,fx,*). % first works
:- op(600,fx,(*)).
:- op(600,fx,[*]).
:- op(600,fx,*).
They all should work, but they all don't work. This means, that you
cannot switch off the operator either.
burs...@gmail.com writes:
> ?- op(600, fx, *).
> true.
>
> ?- X = *A.
> X = *A.
>
>So you do not need to do operator escaping all
>the time, and write op(600, fx, (*)), if the
>context allows you can write op(600, fx, (*)).
Adding round brackets does not make a difference in ISO - both
work. And it does not make a difference in Tau - both do not work.
as a regular atom. Namely:
On the top as Prolog clause (6.2.1.2) or Prolog data (6.2.2).
Example: - .
As an argument of a compound term (6.3.3.1)
Example: f(-).
When overriding the priority of operators with round brackets (6.3.4.1)
Example: X = (-).
As an element using list notation, and as the rest of such (6.3.5)
Example: L = [-].
L = [_|-].
As the argument of a curly bracketed term (6.3.6).
Example: {-}.
All of the above examples produce roughly the same syntax error in
Tau Prolog. And yes, taking your example, you can get locked in by
a further operator declaration
:- op(600,fx,*). % first works
:- op(600,fx,(*)).
:- op(600,fx,[*]).
:- op(600,fx,*).
They all should work, but they all don't work. This means, that you
cannot switch off the operator either.
burs...@gmail.com writes:
> ?- op(600, fx, *).
> true.
>
> ?- X = *A.
> X = *A.
>
>So you do not need to do operator escaping all
>the time, and write op(600, fx, (*)), if the
>context allows you can write op(600, fx, (*)).
work. And it does not make a difference in Tau - both do not work.
burs...@gmail.com
May 24, 2018, 2:32:34 PM5/24/18
to
The op/3 directive should work, if you place it
in the Prolog text. It doesn't work in the REPL
of Tau Prolog.
In the REPL you get:
?- op(400,fx,'*').
uncaught exception: error(existence_error(procedure, op/3), top_level/0)
But if you place it into the Prolog text you get:
Program
:-op(400,fx,'*').
Query
?- X = *A.
X = '*'(A) ;
?- X = /A.
error parsing query: error(syntax_error(line(1), column(6), found('A'), cause('. or expression expected')))
But again the output is a little strange.
It should output *A and not '*'(A). After
all it has prefix operator info for '*',
and it was even able to parse as such.
in the Prolog text. It doesn't work in the REPL
of Tau Prolog.
In the REPL you get:
?- op(400,fx,'*').
uncaught exception: error(existence_error(procedure, op/3), top_level/0)
But if you place it into the Prolog text you get:
Program
:-op(400,fx,'*').
Query
?- X = *A.
X = '*'(A) ;
?- X = /A.
error parsing query: error(syntax_error(line(1), column(6), found('A'), cause('. or expression expected')))
But again the output is a little strange.
It should output *A and not '*'(A). After
all it has prefix operator info for '*',
and it was even able to parse as such.
burs...@gmail.com
May 24, 2018, 3:01:09 PM5/24/18
to
BTW I made my parser and unparser open source a few
days ago, since I didn't have bug fixes over the last
12 months. Some remarks:
- In principle both the parser and the unparser
are darn simple, since they are both recursive
decent. But one might run into stack problems,
for very large terms, since the native Java
stack is used.
- The parser and unparser implement the SWI-Prolog
logic of negative sign for numbers (token level),
and not the GNU Prolog logic of negative sign of
numbers (operator level). They might therefore be
considered to be non ISO core standard compliant,
as long as the ISO core standard doesn't allow
this variation.
- There are a lot of complications, like module
names, array index syntax which were mastered. Also
the unparser does at the same time pretty printing
and variable names. A lot of stuff is also missing,
like portray hook or some term or max term depth
parameter.
Anyway, have fun!
See also:
The good, the bad and the ugly Prolog syntax. (Jekejeke)
https://plus.google.com/+JekejekeCh/posts/i54seSknyBX
Open Source: Parser&Unparser
https://github.com/jburse/jekejeke-devel/tree/master/jekrun/headless/jekpro/model/pretty
There is also a published Grammar on our website.
Disclaimer there is no guarantee that this grammer
is the same as our code.
days ago, since I didn't have bug fixes over the last
12 months. Some remarks:
- In principle both the parser and the unparser
are darn simple, since they are both recursive
decent. But one might run into stack problems,
for very large terms, since the native Java
stack is used.
- The parser and unparser implement the SWI-Prolog
logic of negative sign for numbers (token level),
and not the GNU Prolog logic of negative sign of
numbers (operator level). They might therefore be
considered to be non ISO core standard compliant,
as long as the ISO core standard doesn't allow
this variation.
- There are a lot of complications, like module
names, array index syntax which were mastered. Also
the unparser does at the same time pretty printing
and variable names. A lot of stuff is also missing,
like portray hook or some term or max term depth
parameter.
Anyway, have fun!
See also:
The good, the bad and the ugly Prolog syntax. (Jekejeke)
https://plus.google.com/+JekejekeCh/posts/i54seSknyBX
Open Source: Parser&Unparser
https://github.com/jburse/jekejeke-devel/tree/master/jekrun/headless/jekpro/model/pretty
There is also a published Grammar on our website.
Disclaimer there is no guarantee that this grammer
is the same as our code.
burs...@gmail.com
May 24, 2018, 4:01:11 PM5/24/18
to
Disclaimer, no affiliation with this MOOC:
Agile! The Good, the Hype and the Ugly
https://www.youtube.com/watch?v=uQrS4Byo-VU
We were already agile before the word was even
invented, especially by our lasagna(TM) method.
Just joking.
Agile! The Good, the Hype and the Ugly
https://www.youtube.com/watch?v=uQrS4Byo-VU
We were already agile before the word was even
invented, especially by our lasagna(TM) method.
Just joking.
0 new messages