[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