My goal is to encourage all implementors to provide Prolog systems that adhere to the Prolog ISO standard and also feature the latest declarative constructs. In these respects, GNU Prolog, Scryer and SICStus are great choices at the moment, and Tau and Trealla Prolog are also progressing very nicely in this direction. In GNU Prolog and SICStus, you need to set the Prolog flag double_quotes to the value chars to obtain readable strings, as is already the default in the other systems.
Setting double_quotes to chars in SWI-Prolog seems to break the predicates provided by the dcg/basics library. I don’t see a why to make chars be the default and still use that library.
This indicates a design mistake in the library: It means that you cannot benefit from this compact string representation when using this library, so you incur a 24-fold (!) performance penalty in space, and corresponding penalty in time since much more memory needs to be processed. Setting the flag to codes is not recommended, since it makes your code depend on the encoding of the strings you reason about. In contrast, setting the flag to chars lets you use atoms directly in your programs to reason about individual elements of strings. This is much more readable, and independent of the encoding of strings and files you process in this way. My recommendation is to change the library to correctly handle this setting of double_quotes to chars, which is already the default in the four newest Prolog systems: Scryer, Tau, Trealla and ichiban/prolog. All future Prolog systems will also need to use this default, anything else would be an unacceptable regression in terms of convenience and also efficiency. In a sense, Prolog is coming home: The original Prolog, Marseille Prolog, also treated strings as lists of characters.
Can I please ask you another question? I'm stuck. I'm writing a routine toupper with ASCII codes which is easy : toupper ([],[]). %not sure if I need this toupper ([X],[X]) :- X < 97. toupper ([X],[X]) :- X > 122. toupper([X],[Y]) :- Y is X - 32. This works with simple letters but it doesn't work with maplist. L = "hello" ,maplist(toupper ,L ,R). %FALSE% Help please.. :)
Good to hear! One additional point: Lists of characters are usually a better representation for strings than lists of codes, because characters are more readable. You can use the standard predicate char_code/2 to relate a character to its code, as in: char_code(a, Code), and also: char_code(Char, 97). You can conveniently write a list of characters using double quotes by setting the Prolog flag double_quotes to the value chars with: :- set_prolog_flag(double_quotes, chars). In this way, [a,b,c] can be equivalently written as "abc" for convenience. This is already the default in the newest Prolog systems, Scryer, Tau and Trealla Prolog.
What Prolog implementation do you recommend or use yourself?
My goal is to encourage all implementors to provide Prolog systems that adhere to the Prolog ISO standard and also feature the latest declarative constructs. In these respects, GNU Prolog, Scryer and SICStus are great choices at the moment, and Tau and Trealla Prolog are also progressing very nicely in this direction.
In GNU Prolog and SICStus, you need to set the Prolog flag double_quotes to the value chars to obtain readable strings, as is already the default in the other systems.
Setting double_quotes to chars in SWI-Prolog seems to break the predicates provided by the dcg/basics library. I don’t see a why to make chars be the default and still use that library.
This indicates a design mistake in the library: It means that you cannot benefit from this compact string representation when using this library, so you incur a 24-fold (!) performance penalty in space, and corresponding penalty in time since much more memory needs to be processed. Setting the flag to codes is not recommended, since it makes your code depend on the encoding of the strings you reason about. In contrast, setting the flag to chars lets you use atoms directly in your programs to reason about individual elements of strings. This is much more readable, and independent of the encoding of strings and files you process in this way.
My recommendation is to change the library to correctly handle this setting of double_quotes to chars, which is already the default in the four newest Prolog systems: Scryer, Tau, Trealla and ichiban/prolog. All future Prolog systems will also need to use this default, anything else would be an unacceptable regression in terms of convenience and also efficiency. In a sense, Prolog is coming home: The original Prolog, Marseille Prolog, also treated strings as lists of characters.
Can I please ask you another question? I'm stuck. I'm writing a routine toupper with ASCII codes which is easy :
toupper ([],[]). %not sure if I need this
toupper ([X],[X]) :- X < 97.
toupper ([X],[X]) :- X > 122.
toupper([X],[Y]) :- Y is X - 32.
This works with simple letters but it doesn't work with maplist.
L = "hello" ,maplist(toupper ,L ,R). %FALSE%
Help please.. :)
It's ok now, I solved it.. :)
Good to hear! One additional point: Lists of characters are usually a better representation for strings than lists of codes, because characters are more readable. You can use the standard predicate char_code/2 to relate a character to its code, as in: char_code(a, Code), and also: char_code(Char, 97).
You can conveniently write a list of characters using double quotes by setting the Prolog flag double_quotes to the value chars with: :- set_prolog_flag(double_quotes, chars). In this way, [a,b,c] can be equivalently written as "abc" for convenience. This is already the default in the newest Prolog systems, Scryer, Tau and Trealla Prolog.
@@ThePowerOfProlog in Bprolog I just use write_string().. :)