2

In using SWI Prolog DCGs I noticed some people note

:- set_prolog_flag(double_quotes, codes).

Jan

while others note

:- set_prolog_flag(double_quotes, chars).

false, Markus, mat

What is the difference if any when using with DCG and phrase?

References

The string type and its double quoted syntax
DCG
DCG Grammar rules
double_quotes
set_prolog_flag

Guy Coder
  • 24,501
  • 8
  • 71
  • 136
  • 1
    Where did I **ever** endorse `codes`? I said: *This is frequently the default, but it leads to very unreadable answers*. By what collusion can this be seen as a preference/recommendation let alone endorsement? – false Jul 26 '17 at 17:29
  • 2
    @false I changed it. As I often note, this is all CC so feel free to change it. – Guy Coder Jul 26 '17 at 17:34
  • Of interest: SWI-Prolog [5.6 Remaining issues](http://www.swi-prolog.org/pldoc/man?section=ext-issues) - Codes can be used in arithmetic expressions, while chars are more readable. – Guy Coder Jul 26 '17 at 17:36

1 Answers1

3

As the name double_quotes implies, this flag affects how double quotes (i.e.: ") are treated.

This holds whether or not such quotes are used in connection with DCGs. However, it is especially useful in connection with DCGs because you can for example use:

?- phrase(nt(NT), "test").

and thus automatically treat the phrase to be parsed as a list of characters (in this case: [t,e,s,t]). That's nice for interactive test cases.

The answer by false that you linked to explains it nicely. Note also the following quote from the answer:

This notation [using chars!] gives more readable answers. It can be even more compactly displayed since the double quote notation can be used for printing any list of one-char atoms.

It is clear that chars yields more readable answers than codes. For example:

?- Xs = "hello".
Xs = [h, e, l, l, o].

vs., with codes:

?- Xs = "hello".
Xs = [104, 101, 108, 108, 111].

(Ahem.)

Historically, Han shot first chars came first! Only later, this was changed to using codes by default. A quite unfortunate choice, in my view. Other languages like Haskell work like Prolog originally did:

Hugs> :t last
last :: [a] -> a
Hugs> :t "test"
"test" :: String
Hugs> last "test"
't'
false
  • 10,264
  • 13
  • 101
  • 209
mat
  • 40,498
  • 3
  • 51
  • 78
  • I'm sure you know this, but it is considered one of the most glaring blemishes on Haskell though since strings in Haskell actually _are_ linked lists of characters (unless you use ByteStrings or Text). – Daniel Lyons Jul 26 '17 at 19:47
  • This only means that someone will have to implement an optimization that increases the efficiency of the *internal* representation of strings in the Haskell runtime. Surely it cannot be considered a blemish that strings can be so naturally reasoned about at the *application* level, no? – mat Jul 26 '17 at 19:55
  • I don't know the internals well enough to comment, but I wouldn't assume that it would be easy to make your suggested change. – Daniel Lyons Jul 26 '17 at 20:02
  • 1
    I'm sure it's either not easy or not *that* much of a problem. Still, I think the Haskell approach is much nicer than what other systems have done, such as: *That's hard, so let's break something else instead of getting this right.* I think it's not a blemish to stay true to elegant principles, even if they come at a price for the moment. I do not think that this particular issue is holding Haskell back very much by itself, although I can of course imagine use cases where it could be a problem. – mat Jul 26 '17 at 20:12