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

Richard O'Keefe ok@REDACTED
Mon Mar 29 02:16:54 CEST 2010


On Mar 28, 2010, at 10:31 PM, Mazen Harake wrote:

> I get your point but you don't get mine. I _know_ that there is no  
> way out of the unambiguity part of escape sequences but it can be  
> made a _little easier for me (the developer)_ by letting Erlang  
> guess for me.

>> And somehow Erlang is being slagged off for not making it easy,
>> when *no* language actually makes it easy?
> So in other words I should have said "easier".

No, you should not have said >>ERLANG<<.
It really really is not Erlang's job, any more than it's
Fortran's job or Ada's job or C's job or AWK's job or
Lisp's job or ...

>> I implemented it as a C driver using ncurses' educated guesswork  
>> instead of my own by creating some kind of sync-over-async-call to  
>> ncurses. Fair enough it isn't very difficult but if I could have  
>> called it in Erlang, e,g, io:getch() and Erlang would have returned  
>> "Ummm... I think it is UpArrow" it _still_ would have been easier  
>> wouldn't it?

Where is the C function that does this?
Why are you not criticising C for failing to give you such a function?
There isn't any getch() in C.
(In any case, what you want is not get _character_ but get _key_.)

The proper home for a function to fix an interface bug like
this is in the interface layer that *creates* the bug.
If not in that layer, then in the one immediately above.
That's the C library layer.

> That is my only point; it could have been made "easier" to reach an  
> educated guess by letting Erlang guess for me.

Well, now that you've done it, it _will_ be easier for the next
person with your problem, if there ever is one, provided you
release your code.




More information about the erlang-questions mailing list