Hi Thank you, this explains a lot. So we have here a feature (atom_no_escape) and a bug (X = `\` not accepted).
Bye Daniel Diaz schrieb:
Hello Jan, sorry for the late reply... There is a flag to control the meaning of backquoted strings. By default it is an atom without interpreting escape sequences. But this can be changed (for more info see http://gprolog.org/manual/html_node/gprolog045.html#toc178). Here is an example: | ?- current_prolog_flag(back_quotes,X). X = atom_no_escape yes | ?- X=`\x61\`. X = '\\x61\\' yes | ?- set_prolog_flag(back_quotes,atom). yes | ?- X=`\x61\`. X = a Hope this helps Daniel Le 19/03/2011 18:32, Jan Burse a écrit :Dear All I am working with GNU Prolog 1.3.1 By Daniel Diaz Copyright (C) 1999-2009 Daniel Diaz It seems that escapes in backquoted strings are detected, but not converted. Normal single quotes: ?- X = 'abc'. X = abc | ?- X = '\''. X = '''' ?- X = '\x61\'. X = a Back quotes: ?- X = `abc`. X = abc ?- X = `\'`. X = '\\''' ?- X = `\x61\`. X = '\\x61\\' It seems that the escapes are not converted. But they are detected during parsing of backquoted strings, at least the first escaped character is always expected: ?- X = `\`. . uncaught exception: error(syntax_error('user_input:10 (char:8) expression expected or previous operator needs brackets'),read_term/3) But the closing escape character of a noctal or hexadecimal constant seems not to be not expected: ?- X = `\x61`. X = '\\x61'. ?- X = `\0`. X = '\\0' From my understanding of ISO standard for back quoted strings, the same escaping rules should hold as for single quoted strings. I am referening to non quote char (* 6.4.2.1 *). Is this a bug or a feature? Bye _______________________________________________ Bug-prolog mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-prolog -- Ce message a ete verifie par MailScanner pour des virus ou des polluriels et rien de suspect n'a ete trouve.-- Ce message a été vérifié par MailScanner <http://www.mailscanner.info/> pour des virus ou des polluriels et rien de suspect n'a été trouvé. _______________________________________________ Bug-prolog mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-prolog
_______________________________________________ Bug-prolog mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-prolog
