From Newsgroup: comp.lang.prolog

Hi,

Can ISO 13211-1 (1996) adress the significat problem?
Might it be able to cater for the Unicode solution,
basically the Python universal newlines solution:

"Newline Functions are defined in the Unicode
Standard as providing additional mandatory breaks.
They are not individual characters, but are encoded
as sequences of the control characters NEL, LF,
and CR. If a character sequence for a Newline
Function contains more than one character, it
is kept together."

Most likely not. And the problem is not only
morons like @jp-diegidio and EricGT. The
problem is rooted in ignoring the possibility

of plural Newline Functions in a Prolog
processor environment. Which result in this
cludge in the ISO 13211-1 (1996):

- *Single Newline Char*
Cannot recognize newline functions. The ISO 13211-1
(1996) basically hypothesized a single newline
character. As found in section 7.10.2.6:

A text stream is a sequence of characters where each
character is a member of C (7.1.4.1). A text stream is
also regarded as a sequence of lines where each line is
a possibly empty sequence of characters followed by an
implementation dependent new line character (6.5, 6.5.4).

- *End Line Trimming*
Cannot preserve newline functions. As a cludge to
recognize Windows CR LF, some Prolog systems fall back
to this advice, simply dropping the CR, again
found in section 7.10.2.6:

Processor may add or remove space characters at the
ends of lines in order to conform to the conventions for
representing text streams in the operating system. Any
such alterations to the stream shall be implementation
defined.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

One easily finds Traces of section 7.10.2.6 among
Prolog systems. The problem is the model from section
7.10.2.6 which conflicts with the Unicode proposal,

as layed down in UAX#14 already for a while, left
also its traces in string/atom functions. Because
strings/atoms are viewed as following section 7.10.2.6

as well. The nonsense is found for example here:

read_string(+Stream, +SepChars, +PadChars, -Sep, -String)
provided that SepChars and PadChars are not partially overlapping http://eclipseclp.org/wiki/Prolog/Strings

The idea was that SepChar = LF and PadChar = CR,
to cover Windows platform. But the Unicode standard
warns that we might not have homogenous platforms.

In inhomogenous platforms SepChars and PadChars would
be overlapping so to speak, as the CR, CR LF and LF
example shows. What was layed down in ECLiPSe Prolog,

with reference to YAP and SWI as Agreed Common
Functionality in 2013-11-28 ff. Made it into SWI-
Prolog. It has the same annoying approach in its

string/atoms built-ins.

Bye

Disclaimer: I didn't check whether Richard O'Keefe or
Quintus had a better proposal. This page is not
annoymore existent:

http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm

And Quintus does not seem to have anything Python
universal newlines, at least this hear again
assumes only a single newline SepChar:

Quintus Prolog UserrCOs Manual (1991 ff)
is_endfile(-Char)
Char is the end-of-file character.
There is only one such character https://quintus.sics.se/isl/quintus/pdf/quintus.pdf

Mild Shock schrieb:

Hi,

Can ISO 13211-1 (1996) adress the significat problem?
Might it be able to cater for the Unicode solution,
basically the Python universal newlines solution:

"Newline Functions are defined in the Unicode
Standard as providing additional mandatory breaks.
They are not individual characters, but are encoded
as sequences of the control characters NEL, LF,
and CR. If a character sequence for a Newline
Function contains more than one character, it
is kept together."

Most likely not. And the problem is not only
morons like @jp-diegidio and EricGT. The
problem is rooted in ignoring the possibility

of plural Newline Functions in a Prolog
processor environment. Which result in this
cludge in the ISO 13211-1 (1996):

- *Single Newline Char*
-a Cannot recognize newline functions. The ISO 13211-1
-a (1996) basically hypothesized a single newline
-a character. As found in section 7.10.2.6:

A text stream is a sequence of characters where each
character is a member of C (7.1.4.1). A text stream is
also regarded as a sequence of lines where each line is
a possibly empty sequence of characters followed by an
implementation dependent new line character (6.5, 6.5.4).

- *End Line Trimming*
-a Cannot preserve newline functions. As a cludge to
-a recognize Windows CR LF, some Prolog systems fall back
-a to this advice, simply dropping the CR, again
-a found in section 7.10.2.6:

Processor may add or remove space characters at the
ends of lines in order to conform to the conventions for
representing text streams in the operating system. Any
such alterations to the stream shall be implementation
defined.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Is it lawful to call @jp-diegidio and EricGT morons?
In my opinion its lawful Tit-for-Tat to call any
Nazi-retards morons that behave as follows:

- Obstructing my Posts in SWI-Prolog discouse.

- When I protest, calling me aggressive and
deleting my posts.

- When I protest, calling me not listening to
staff and blocking my account.

The only result of such Nazi-retard behaviour
that supresses a scientific discussion, is of
course FAFO as can be seen now with the SWI-Prolog

editor mess. Choose your FAFO meme for SWIPL:

https://giphy.com/explore/fafo

SWIPL as advanced as it is backwards.

Bye

Mild Shock schrieb:

Hi,

One easily finds Traces of section 7.10.2.6 among
Prolog systems. The problem is the model from section
7.10.2.6 which conflicts with the Unicode proposal,

as layed down in UAX#14 already for a while, left
also its traces in string/atom functions. Because
strings/atoms are viewed as following section 7.10.2.6

as well. The nonsense is found for example here:

read_string(+Stream, +SepChars, +PadChars, -Sep, -String)
provided that SepChars and PadChars are not partially overlapping http://eclipseclp.org/wiki/Prolog/Strings

The idea was that SepChar = LF and PadChar = CR,
to cover Windows platform. But the Unicode standard
warns that we might not have homogenous platforms.

In inhomogenous platforms SepChars and PadChars would
be overlapping so to speak, as the CR, CR LF and LF
example shows. What was layed down in ECLiPSe Prolog,

with reference to YAP and SWI as Agreed Common
Functionality in 2013-11-28 ff. Made it into SWI-
Prolog. It has the same annoying approach in its

string/atoms built-ins.

Bye

Disclaimer: I didn't check whether Richard O'Keefe or
Quintus had a better proposal. This page is not
annoymore existent:

http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm

And Quintus does not seem to have anything Python
universal newlines, at least this hear again
assumes only a single newline SepChar:

Quintus Prolog UserrCOs Manual (1991 ff)
is_endfile(-Char)
Char is the end-of-file character.
There is only one such character https://quintus.sics.se/isl/quintus/pdf/quintus.pdf

Mild Shock schrieb:

Hi,

Can ISO 13211-1 (1996) adress the significat problem?
Might it be able to cater for the Unicode solution,
basically the Python universal newlines solution:

"Newline Functions are defined in the Unicode
Standard as providing additional mandatory breaks.
They are not individual characters, but are encoded
as sequences of the control characters NEL, LF,
and CR. If a character sequence for a Newline
Function contains more than one character, it
is kept together."

Most likely not. And the problem is not only
morons like @jp-diegidio and EricGT. The
problem is rooted in ignoring the possibility

of plural Newline Functions in a Prolog
processor environment. Which result in this
cludge in the ISO 13211-1 (1996):

- *Single Newline Char*
-a-a Cannot recognize newline functions. The ISO 13211-1
-a-a (1996) basically hypothesized a single newline
-a-a character. As found in section 7.10.2.6:

A text stream is a sequence of characters where each
character is a member of C (7.1.4.1). A text stream is
also regarded as a sequence of lines where each line is
a possibly empty sequence of characters followed by an
implementation dependent new line character (6.5, 6.5.4).

- *End Line Trimming*
-a-a Cannot preserve newline functions. As a cludge to
-a-a recognize Windows CR LF, some Prolog systems fall back
-a-a to this advice, simply dropping the CR, again
-a-a found in section 7.10.2.6:

Processor may add or remove space characters at the
ends of lines in order to conform to the conventions for
representing text streams in the operating system. Any
such alterations to the stream shall be implementation
defined.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

No wonder Python is called the data science language,
they are just an itch smarter than toothless:

SWIPL as advanced as it is backwards.

But I have to double check. Maybe they still use
a Timer deep in their universal newline mode?

I still could not yet figure out why Python is so
slow in some of my file processing. So the best

of both worlds would be:

- comfort: Have the convenience of
Python universal newlines

- speed: Do it as speedy as Java LineReader
state machine

- What else?

Dogelog Player currently implements best of both
worls, it has a simpe state machine in the low
level native implemented streams.

It offers a lot of comfort in the pure Prolog
implemented routines like get_atom/2. One can
opt-in to newline compression, i.e. mapping

all of CR, CR LF and LF to LF, otherwise its
fully preserved. There are no other string/atoms
operations. But applying get_atom/2 to a memory
stream derived from an atom has the exact

same behaviour as hooked on a file or socket.
The Prolog scanner to yield Prolog tokens handles
CR, CR LF and LF efficiently without any timer.

Bye

Mild Shock schrieb:

Hi,

Is it lawful to call @jp-diegidio and EricGT morons?
In my opinion its lawful Tit-for-Tat to call any
Nazi-retards morons that behave as follows:

- Obstructing my Posts in SWI-Prolog discouse.

- When I protest, calling me aggressive and
-a deleting my posts.

- When I protest, calling me not listening to
-a staff and blocking my account.

The only result of such Nazi-retard behaviour
that supresses a scientific discussion, is of
course FAFO as can be seen now with the SWI-Prolog

editor mess. Choose your FAFO meme for SWIPL:

https://giphy.com/explore/fafo

SWIPL as advanced as it is backwards.

Bye

Mild Shock schrieb:

Hi,

One easily finds Traces of section 7.10.2.6 among
Prolog systems. The problem is the model from section
7.10.2.6 which conflicts with the Unicode proposal,

as layed down in UAX#14 already for a while, left
also its traces in string/atom functions. Because
strings/atoms are viewed as following section 7.10.2.6

as well. The nonsense is found for example here:

read_string(+Stream, +SepChars, +PadChars, -Sep, -String)
provided that SepChars and PadChars are not partially overlapping
http://eclipseclp.org/wiki/Prolog/Strings

The idea was that SepChar = LF and PadChar = CR,
to cover Windows platform. But the Unicode standard
warns that we might not have homogenous platforms.

In inhomogenous platforms SepChars and PadChars would
be overlapping so to speak, as the CR, CR LF and LF
example shows. What was layed down in ECLiPSe Prolog,

with reference to YAP and SWI as Agreed Common
Functionality in 2013-11-28 ff. Made it into SWI-
Prolog. It has the same annoying approach in its

string/atoms built-ins.

Bye

Disclaimer: I didn't check whether Richard O'Keefe or
Quintus had a better proposal. This page is not
annoymore existent:

http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm

And Quintus does not seem to have anything Python
universal newlines, at least this hear again
assumes only a single newline SepChar:

Quintus Prolog UserrCOs Manual (1991 ff)
is_endfile(-Char)
Char is the end-of-file character.
There is only one such character
https://quintus.sics.se/isl/quintus/pdf/quintus.pdf

Mild Shock schrieb:

Hi,

Can ISO 13211-1 (1996) adress the significat problem?
Might it be able to cater for the Unicode solution,
basically the Python universal newlines solution:

"Newline Functions are defined in the Unicode
Standard as providing additional mandatory breaks.
They are not individual characters, but are encoded
as sequences of the control characters NEL, LF,
and CR. If a character sequence for a Newline
Function contains more than one character, it
is kept together."

Most likely not. And the problem is not only
morons like @jp-diegidio and EricGT. The
problem is rooted in ignoring the possibility

of plural Newline Functions in a Prolog
processor environment. Which result in this
cludge in the ISO 13211-1 (1996):

- *Single Newline Char*
-a-a Cannot recognize newline functions. The ISO 13211-1
-a-a (1996) basically hypothesized a single newline
-a-a character. As found in section 7.10.2.6:

A text stream is a sequence of characters where each
character is a member of C (7.1.4.1). A text stream is
also regarded as a sequence of lines where each line is
a possibly empty sequence of characters followed by an
implementation dependent new line character (6.5, 6.5.4).

- *End Line Trimming*
-a-a Cannot preserve newline functions. As a cludge to
-a-a recognize Windows CR LF, some Prolog systems fall back
-a-a to this advice, simply dropping the CR, again
-a-a found in section 7.10.2.6:

Processor may add or remove space characters at the
ends of lines in order to conform to the conventions for
representing text streams in the operating system. Any
such alterations to the stream shall be implementation
defined.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

No wonder Python is called the data science language,
they are just an itch smarter than toothless:

SWIPL as advanced as it is backwards.

But I have to double check. Maybe they still use
a Timer deep in their universal newline mode?
I still could not yet figure out why Python is so

slow in some of my file processing. So the best
of both worlds would be:

- comfort: Have the convenience of
Python universal newlines

- speed: Do it as speedy as Java LineReader
state machine

- What else?

Dogelog Player currently implements best of both
worls, it has a simpe state machine in the low
level native implemented streams.

It offers a lot of comfort in the pure Prolog
implemented routines like get_atom/2. One can
opt-in to newline compression, i.e. mapping

all of CR, CR LF and LF to LF, otherwise its
fully preserved. There are no other string/atoms
operations. But applying get_atom/2 to a memory

stream derived from an atom has the exact
same behaviour as hooked on a file or socket.
The Prolog scanner to yield Prolog tokens handles

CR, CR LF and LF efficiently without any timer.
The statemachine could be ignored and other newline
conventions can be realized, using the stream

rather binary than text. Currently I don't have
a flag for that, but one could do that. Its like
a flag that would switch on / off piggy backing

LineReader on a Reader, but more lightweight,
not really implementing the Java Filter pattern.

Bye

Mild Shock schrieb:

Hi,

Is it lawful to call @jp-diegidio and EricGT morons?
In my opinion its lawful Tit-for-Tat to call any
Nazi-retards morons that behave as follows:

- Obstructing my Posts in SWI-Prolog discouse.

- When I protest, calling me aggressive and
-a deleting my posts.

- When I protest, calling me not listening to
-a staff and blocking my account.

The only result of such Nazi-retard behaviour
that supresses a scientific discussion, is of
course FAFO as can be seen now with the SWI-Prolog

editor mess. Choose your FAFO meme for SWIPL:

https://giphy.com/explore/fafo

SWIPL as advanced as it is backwards.

Bye

Mild Shock schrieb:

Hi,

One easily finds Traces of section 7.10.2.6 among
Prolog systems. The problem is the model from section
7.10.2.6 which conflicts with the Unicode proposal,

as layed down in UAX#14 already for a while, left
also its traces in string/atom functions. Because
strings/atoms are viewed as following section 7.10.2.6

as well. The nonsense is found for example here:

read_string(+Stream, +SepChars, +PadChars, -Sep, -String)
provided that SepChars and PadChars are not partially overlapping
http://eclipseclp.org/wiki/Prolog/Strings

The idea was that SepChar = LF and PadChar = CR,
to cover Windows platform. But the Unicode standard
warns that we might not have homogenous platforms.

In inhomogenous platforms SepChars and PadChars would
be overlapping so to speak, as the CR, CR LF and LF
example shows. What was layed down in ECLiPSe Prolog,

with reference to YAP and SWI as Agreed Common
Functionality in 2013-11-28 ff. Made it into SWI-
Prolog. It has the same annoying approach in its

string/atoms built-ins.

Bye

Disclaimer: I didn't check whether Richard O'Keefe or
Quintus had a better proposal. This page is not
annoymore existent:

http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm

And Quintus does not seem to have anything Python
universal newlines, at least this hear again
assumes only a single newline SepChar:

Quintus Prolog UserrCOs Manual (1991 ff)
is_endfile(-Char)
Char is the end-of-file character.
There is only one such character
https://quintus.sics.se/isl/quintus/pdf/quintus.pdf

Mild Shock schrieb:

Hi,

Can ISO 13211-1 (1996) adress the significat problem?
Might it be able to cater for the Unicode solution,
basically the Python universal newlines solution:

"Newline Functions are defined in the Unicode
Standard as providing additional mandatory breaks.
They are not individual characters, but are encoded
as sequences of the control characters NEL, LF,
and CR. If a character sequence for a Newline
Function contains more than one character, it
is kept together."

Most likely not. And the problem is not only
morons like @jp-diegidio and EricGT. The
problem is rooted in ignoring the possibility

of plural Newline Functions in a Prolog
processor environment. Which result in this
cludge in the ISO 13211-1 (1996):

- *Single Newline Char*
-a-a Cannot recognize newline functions. The ISO 13211-1
-a-a (1996) basically hypothesized a single newline
-a-a character. As found in section 7.10.2.6:

A text stream is a sequence of characters where each
character is a member of C (7.1.4.1). A text stream is
also regarded as a sequence of lines where each line is
a possibly empty sequence of characters followed by an
implementation dependent new line character (6.5, 6.5.4).

- *End Line Trimming*
-a-a Cannot preserve newline functions. As a cludge to
-a-a recognize Windows CR LF, some Prolog systems fall back
-a-a to this advice, simply dropping the CR, again
-a-a found in section 7.10.2.6:

Processor may add or remove space characters at the
ends of lines in order to conform to the conventions for
representing text streams in the operating system. Any
such alterations to the stream shall be implementation
defined.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2