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

[Mazen Harake]

Actually you are right, for general input it is good enough (specially 
when reading from files) and what I am arguing is not the same you are 
correct. However, if you will do lower-level stuff you are a bit 
constrained. I guess I just meant that I would like to have:

a peak function,
a get_chars function that take in character by character instead of 
taking the N number of characters in the line. In other words: the 
ability to read in keystrokes and not just N chars from a line.
a get_char function which includes special keys (in some way)
a way of aborting a blocking get_char function without spawning it into 
a separate process and killing it when timing out
and a way to get events of when a terminal changes size (which I can 
simulate but still).

Currently you have to do all this in a driver. But there are many things 
I like to have :) I'm not too sad about it... I'm just saying it would 
be nice to see in the future (although I know it is not exactly priority).

On 26/03/2010 23:22, Hynek Vychodil wrote:
> On Fri, Mar 26, 2010 at 12:51 PM, Mazen Harake
> <mazen.harake@REDACTED>  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?
>>      
> Well, I think Erlang is able read input well. What are you arguing is
> distinguish escape codes from other input. Sorry, it is not same.
>    
>> On 26/03/2010 18:11, Hasan Alayli wrote:
>>      
>>> On Fri, Mar 26, 2010 at 4:27 AM, Mazen Harake
>>> <mazen.harake@REDACTED>    wrote:
>>>
>>>        
>>>> Well, I think you are wrong to be honest. It is probably more general
>>>> purpose than you might think. I have seen Erlang being used from
>>>> everything
>>>> from telecom-systems to sorting and processing files on local disk.
>>>>
>>>> It is exactly this that is my point that it needs better support for
>>>> these
>>>> things if it is to become more general purpose.
>>>>
>>>>
>>>>          
>>> I can see telecom-systems requiring fault tolerance, high availability
>>> and the ability to handle concurrent operations. So Erlang feels
>>> natural in this context because it solves such problems easier than
>>> other languages.
>>>
>>> Erlang wasn't designed to be used in the context you are using
>>> although it is possible. But you will hit many walls and blame the
>>> language, and that was my original point.
>>>
>>> It is like when a programmer attempts to implement object oriented
>>> patterns in Perl. It is possible, but it is not natural compared to
>>> Java/Python/Smalltalk for example. The programmer has to go out of his
>>> way to do that and this is when he should figure out that the language
>>> was not designed for this purpose.
>>>
>>> Just a thought.
>>>
>>>        
>> ---------------------------------------------------
>>
>> ---------------------------------------------------
>>
>> WE'VE CHANGED NAMES!
>>
>> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG
>> SOLUTIONS LTD.
>>
>> www.erlang-solutions.com
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>>      
>
>
>    

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com