EAdd. Exp ::= Exp "⌽" Exp1 ;
-- syntax error at line 1, column 22 due to lexer error
The inability to lex simple unicode character declarations is a shortfall.
It may be there's some way of addressing this, but the documentation doesn't mention anything.

By simply allowing unicode in the generated Haskell lexer, I managed to enable this feature for LBNF and some backends, including Haskell and Java.
For some backends, the testsuite reports errors: C, C++, Ocaml.

Thanks for this Andreas. I will try again ;-D

To be precise, I only changed in the generated .x file for Alex the line

$u = [\0-\255]          -- universal: any character

to

$u = [. \n]          -- universal: any character

However, I did not do anything to extend the definitions of capital and lower-case letters to unicode.

Changing
$u = [\0-\255] -- universal: any character
to
$u = [\x00-\xffff] -- universal: any character
Seems to handle a lot more characters.
(Mind you, I've only tested on the unicode characters –, ” and “ )

Did you mean ?

Changing
$u = [. \n] -- universal: any character
to
$u = [\x00-\xffff] -- universal: any character
seems to handle a lot more characters.

Yes.

Strange, that seems to contradict the alex documentation at https://www.haskell.org/alex/doc/html/charsets.html :

.

    The built-in set ‘.’ matches all characters except newline (\n).

    Equivalent to the set [\x00-\x10ffff] # \n.

Or maybe I do not understand it. From my naive point of view \x10ffff is a bigger number than \xffff, thus, the currently implemented range should include your range.

Could you provide me with a minimal test case, please?

Andreas, you are correct.
Unicode extends beyond 0xffff As I understand it, Unicode enabled regular expressions treat ‘.’ as any character other than newline and null, bearing in mind that the Unicode character type can be represented with variable number of bytes. Another feature of multi-byte encodings (such as the pretty normative UTF-8) the null character is not found in a legal character string (but, depending on implementation, may be used to mark the end of string - however that’s beyond the scope of regular expressions, which are only interested in the strings themselves). It should be clear already that regular expressions are only useful for string-like types, and are not suitable for raw streams. All of this is better expressed elsewhere.

TL;DR

[. \n] is a good pattern for ‘any character’

@sillydan1: I am closing this, but you are welcome reopen it with a MWE.

Fixed printer for C.
C++ seems to work already.
b8701c3 broke #249 for Java/ANTLR in the lexer,
c49d1fd for Java/CUP.