Alternatives to . for composition
jupdike at gmail.com
Sat Mar 25 14:26:53 EST 2006
> For emacs, just bind a key (C-. say) to (ucs-insert
> #X2218). ucs-insert comes from ucs-tables.
Sounds easy enough. I'll test emacs and my terminal and see about it.
> > 2) Will it show up in PuTTY (and everyone else's terminals/IDEs)?
> > in everyone's mail readers (including Gmail)?
> Eventually, I should think. I'm using nmh, which has to be
> one of the least trendy MUAs about, and that can do it. What
> does this: ∘ look like in your email reader?
Looks great in Gmail.
> It's far worse than that. We are stuck in an idiotic land
> where the meaning of a file depends on the meaning of a user
> settable variable in the OS. This is one of the many
> unpleasant consequences of untyped filesystems¹.
That's a bad situation (i.e. idiotic).
>> Does Haskell even support everything related to Unicode
>> that we'd need?
> Not now, but Haskell' jolly well ought to.
> Oh, and Haskell claims already to have unicode source files, but the
> compilers can't handle it.
I agree this ought to be rectified, but since I'm not volunteering to
do it, I personally can't ensure its adoption. But I'll be cheerleader
> If the answers are satisfactory to all these questions,
> then Unicode is a good idea (and that's the ideal
Your answers seem very satisfactory to me. I guess it's a question of
support / using Unicode in practice.
>> P.S. Plus that opens a lot of cans of worms for writing programs with
>> all those fancy symbols! APL here we come!
> It's a question of good style, isn't it? Using → instead of
> -> might be nice
This seems reasonable. Haskell already has a lot of carefully chosen
graphical notation that actually aids in readability. As long as the
old version of "→" i.e. "->" works, I don't see this as a problem.
Although all the lexers for all tools and compilers would have to be
updated. If it's a new backwards-incompatible standard (like Haskell
2), then this isn't a problem. For Haskell', since the compilers don't
already support things well enough it sounds like, (i.e. Unicode
everywhere with all its complexities, plus "->" + "→", etc.) then
maybe this is beyond the scope of Haskell'. But I hope these sorts of
important improvements occur sooner than later. (Once again I'm only
> but stringing together lots of arcane
> symbols like ₀∘°⁰ wouldn't be.
And that's where APL breaks down. I don't see Unicode allowing for any
more abuse than the current DIY infix operator already does.
> For Haskell 98 I argued
> against unicode, preferring that we should stick with ASCII,
> but nowadays a language that doesn't handle unicode properly
> is going to look shabby in a few years.
Thanks for the enlightenment.
More information about the Haskell-prime