Sequences of ASCII values render differently in book and REPL

[bboston7]

Section 1.8 presents the following example (compressed a bit here to show just the relevant portion):

Cryptol> :set base=10
Cryptol> :set ascii=on
Cryptol> ['A' .. 'Z']
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"

However, in the REPL:

Cryptol> :set base=10
Cryptol> :set ascii=on
Cryptol> ['A'..'Z']
Showing a specific instance of polymorphic result:
  * Using 'Integer' for type argument 'a' of 'Cryptol::fromTo'
[65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80,
 81, 82, 83, 84, 85, 86, 87, 88, 89, 90]

It appears that :set ascii=on doesn't change the behavior of the pretty printer on sequences of ASCII values. It does, however, work as expected on single characters.

[weaversa]

This is happening because the defaulter is assigning the characters values the type of Integer.

Providing a bitvector type such as ['A'..'Z'] : [26][8] solves the problem. The manual should be updated accordingly. You know, there might be a few more of these defaulting issues in the manual.

[robdockins]

Oh, interesting. That enumeration defaulted to a sequence of Integer instead of [8], which I think it used to do. If you instead

Cryptol> ['A'..'Z':[8]]
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"

I think this is yet more evidence that we need to rethink defaulting.

[yav]

This is an interesting interaction indeed. Notice that A and Z are types there, so it's actually even more confusing (the type signature would have to be on the outside)

[yav]

Actually, I guess we added a special case, so the inner signature also works :-) Sigh.

[brianhuffman]

The [a..b:[n]] syntax (with the type annotation inside) was added by #628 to address #625. In a comment there (#625 (comment)) I suggested that using character literals for enumeration bounds should constrain the element type to [8]. Due to lack of response, I left that feature out of the PR; but maybe we should go back and add it to address this ticket?

[yav]

Yeah, the character notation is only really there for the book, so I guess we could make it more user friendly, although it really is promoting a view of how things work, which is not quite right..

I wonder, if it might not be better to simply remove characters literals from the types, as we've discussed before.

[robdockins]

CF #864