bs classic's compose operator.

[rossc719g]

(It's me again! Sorry!)

I was just trying to use the compose operator in bs classic.
I assumed it'd be period (.), but it appears to be the cdot (·), which is fine, though somewhat more awkward to type.
But it seems that it only works if you use one of the old-style 1-byte character encodings (like Latin-1).
Specifically, UTF-8 does not work, even if I try to define a new (·) myself (Unexpected "\183";)

Spelling it as `compose` is always an option, but I was curious if there were better options.

Before I go and enforce that all my code needs to be Latin-1 encoded, or use `compose`, I just wanted to check:
Is there a way to make bsc happy with UTF-8?
Or a way to use period (.) for compose? I expect not, because struct fields and such...
Or maybe there is some other "standardish" character for this sort of thing?
What do you all use for this?

[mieszko]

i use · but then i also have to make the editor save the thing as latin1, which is quite annoying. and less civilized editors will try to read it as utf8 no matter what, or, worse, read it as latin1 and then helpfully™ save as utf8. so let's banish this latin1 nonsense; i'll make a PR to make bsc use utf8 everywhere.

from a historical perspective, bsc was developed well before utf8 became commonplace, and as you can see it uses latin1. back then this made some sense b/c if you used a different encoding things would still work consistently, they might just look different — so if you used latin2 then you'd see ˇ instead of ·, et cetera.

a related issue is that · should really properly be ∘^* (which was not available in latin1), and i guess it would make sense to change it as well if one is going to make changes that break the old encoding of · in any case.

another possibility is to consider whether . (ASCII full stop) could be used; that, however would require some careful thinking. it's currently used as record selection syntax, wherein . can take a variety of things on the left and identifiers (or parenthesized op-identifiers) on the right — unlike in haskell where you can write foo.bar and it parses as composition. so if we also allowed . to be an operator we'd have a bit of a mess where operators don't need spaces around them except for .... perhaps a separate discussion.

^*then we can be more like APL, and there is so much potential for other APL-like syntax! :)

[rossc719g]

For now, I have switched to latin1 and am using ·.
I agree it would be nice to use utf8. It opens up a wide rage of possible custom operators too, which is nice.

The latin1 encoding of · (0xb7) is not valid in utf8, (IIUC).
So it might be possible to just handle it special case to keep existing latin1 code working.

Agree that . would be nice, not sure if it is worth the headache to disambiguate it from the record selection...
But assuming we can't have that, •, ·, and ∘ all "feel" like composition so seem like good candidates.

[mieszko]

indeed · is not valid in UTF-8, but I'm also not a fan of haxx to implement parse-UTF-8-except-for-legacy-non-ASCII-ops, or try-UTF-8-but-fall-back-to-other-encodings-on-error. it's easy enough to run iconv -f latin1 -t utf8 -o outfile.bs infile.bs, so personally i don't think it's worth the complexity.

i'll add a reasonable error message if the input can't be decoded (unlike GHC's mysterious "invalid argument" from the Show instance for IOErrorType).

[mieszko]

see PR #601