[erlang-questions] Reading (and ignoring) escape-sequences

[Richard O'Keefe]

On Mar 27, 2010, at 8:51 AM, Mazen Harake wrote:

> Ok fair enough I understand what you were aiming for but I certainly  
> don't agree. I believe your comparison to OOP in perl is not at all  
> the same. Just because Erlang has certain characteristics which it  
> is known for (which doesn't involve reading input data) it doesn't  
> mean that it shouldn't have a decent way of reading input data!? It  
> is like saying "Why do you want good wheels on an air plane when it  
> spends most of its time flying?"
>
> Erlang must be able to read input, so why not do that well?

I am more than a little puzzled here.
There is a problem which is not merely theoretically intractable,
but for which all purported practical solutions are unhappily
easy to break.
There is NO programming language which is good at this problem,
because it isn't the _kind_ of problem a language could be good
at:  it's an OS/interface issue.
And somehow Erlang is being slagged off for not making it easy,
when *no* language actually makes it easy?

If you want to distinguish
	- user pressed ESC key
from
	- user pressed some arrow key
*reliably*, then you *have* to work at the level of key codes.

At the level of "ASCII byte sequences" the situation is inherently
ambiguous, and NO, timeouts _usually_ work but are by no means
infallible.

Erlang doesn't have any way to work at the level of key codes in
the same way that C doesn't have any way to work at the level of
key codes.  You can search the ANSI/ISO C documentation and the
POSIX documentation to your heart's content, and you will not find
any portable way to read key codes in C.

If there were, Erlang could call it.

I know how to get key codes in MS-DOS without involving a GUI.
But everything else that I use, information about key codes is
only available through some sort of GUI library.  And it's not
just a matter of different systems using different key codes;
different keyboards may use different key codes.

If the terminal in question is a separate physical terminal,
perhaps connected through a serial port, then you are stuck
with the inherently unreliable dodge of educated guesswork,
just like ncurses.

It wouldn't surprise me if Joe Armstrong were to explain that
the right thing to do is to define a *protocol* between the
guts of your program and the user interface part, and then
make an informed decision about whether to implement the user
interface part all in Erlang, or some in a C node or a driver
or whatever.