[Haskell-cafe] To [] Or Not To []

[Olaf Klinke]

And I was merely pointing that out: That there are recommended use cases in the article, while the abstract given by the author on this list was quite negative. (Possibly it had to be, in order to gain the necessary attention.) I was not arguing against the syntactic preference Haskell gives to singly linked lists over other data structures. If Haskell was designed from scratch, what would take the place of []? Possibly Data.Sequence? 

Mildly complex data processing programs are somewhat special: You read in and parse one or more input files, do some transformation on the parsed data and write some results back to disk. As the article explained, the Haskell compiler will be able to optimise away the intermediate list structure (at least in simple cases). If data dependency is local, you'll be fine with data input to String rather than Text or ByteString, with map rather than fmap or foldl', and you'll be fine to use a mapM_ on a list for output. 

Olaf
> I think you are missing the point of the article, as that is pretty much
> exactly the type of situation where it recommends lists be used.
> 
> On Mar 10, 2017 7:45 PM, "JK" <jerzy.karczmarczuk at unicaen.fr> wrote:
> 
>> Hi.
>> Le 11/03/2017 à 00:28, Olaf Klinke a écrit :
>> 
>> Actually, your negative abstract turns out to be for a quite positive article. List are like iterators, that's the essence, and as long as you are iterating, it's fine to use []. The prominence of singly linked lists in Haskell has tought me to write my data processing programs in a streaming style.
>> 
>> *Yes.* I've been teaching not just "data processing" - after all almost
>> everything we program is "data processing", no?... but such concrete stuff
>> as physics simulation (diff. eqs.), some other numerics (asymptotic
>> expansions, etc.) signal processing (including sound generation), and I
>> liked to present several examples in a *dataflow style* with plenty of
>> co-recursive contraptions. Haskell lazy lists were natural, concise, and
>> easy to manipulate.  We enjoyed it, wrong or not.
>> 
>> Nothing is perfect, not only  mister Nobody; calling ANY approach to
>> programming "wrong" is sectarian. A professional coder working on a
>> concrete project may say bad words about anything he wishes, but for a
>> teacher this is a pedagogical sin, and inefficient programs can be more
>> inspiring than some "correct" doctrines.
>> 
>> Jerzy Karczmarczuk