Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: general observation about programming (Jeffrey Brown)
2. Re: general observation about programming (Michael Orlitzky)
3. Re: general observation about programming (Dennis Raddle)
4. Re: Stack minimal dependency specification, or dependency
tree output (Lyndon Maydwell)
----------------------------------------------------------------------
Message: 1
Date: Fri, 26 Feb 2016 11:52:39 -0800
From: Jeffrey Brown <jeffbrown....@gmail.com>
To: mike.pent...@physics.org, The Haskell-Beginners Mailing List -
Discussion of primarily beginner-level topics related to Haskell
<beginners@haskell.org>
Subject: Re: [Haskell-beginners] general observation about programming
Message-ID:
<CAEc4Ma1HF1c3N5pTkxCW-JErt9KiS6rMorSdMPeGAbBVP8=9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
If you want to know how to pronounce an infix, GHCI and Hackage can very
often solve the problem for you. For instance:
> :i <$>
(<$>) :: Functor f => (a -> b) -> f a -> f b
-- Defined in ?Data.Functor?
infixl 4 <$>
>
If you then lookup Data.Functor on Hackage, you'll find in the description
of <$> "An infix synonym for fmap." Even if there's no comment provided,
you can from there view source; often you'll find a one-word definition
like "(>>=) = bind".
On Fri, Feb 26, 2016 at 1:55 AM, Mike Pentney <mike.pent...@physics.org>
wrote:
> As a newbie, something I dislike about Haskell is the use of infix
> operators like <||> which are unpronouncable and therefore (if you don't
> happen to know the notation the symbol is based on) are more or less
> meaningless.
>
> And Haskellers often seem to prefer 1 and 2 character variable names,
> which again convey little or no information.
>
> And don't get me started on point-free code...!
>
> N.B. I am not trying to start a flame war, these are just comments from my
> experience of trying to get beyond text-book examples and start using
> Haskell libraries and trying to learn from open source code. In general I
> find idiomatic Haskell hard to understand, and for me this is a barrier to
> using Haskell for real projects. Maybe someday I'll have learnt enough to
> get past this problem, but as the language and libraries seem to evolve
> quickly, I have my doubts...
>
>
> On 25/02/16 19:19, Jeffrey Brown wrote:
>
>> Something I like about functional programming is how it interfaces with
>> natural language.
>> Haskell, somehow to a greater extent than other languages, encourages me
>> to divide functions
>> into one or two-liners. Each has a type signature that means something in
>> English. Further, each
>> gives you the opportunity to choose a good name for the function and its
>> arguments. After doing
>> those things, the function is much easier to write, and much easier to
>> read -- so much so that
>> often you don't have to read the function body at all, just the type
>> signature, function name
>> and argument names.
>>
>> On Thu, Feb 25, 2016 at 8:17 AM, Dudley Brooks <
>> dbro...@runforyourlife.org
>> <mailto:dbro...@runforyourlife.org>> wrote:
>>
>> Ages and ages ago I saw this advice about programming:
>>
>> Q: "What's the best language for a programmer to know?"
>>
>> A: "English" (or whatever your native language is)
>>
>> -- Dudley
>>
>>
>> On 2/24/16 4:03 PM, Dennis Raddle wrote:
>>
>> This is more about programming in general than Haskell, although
>>> Haskellers probably know
>>> it well.
>>>
>>> I don't claim to have expert knowledge on this, but I'm gradually
>>> getting better at it.
>>>
>>> When I set out to write a program, or refactor a program, or modify
>>> a program, it helps to
>>> set out my thinking in a clear way. And how I make it clear is to
>>> document my thoughts.
>>>
>>> An outline is one good way to organize thoughts and is probably my
>>> main tool. But good
>>> English prose is also helpful.
>>>
>>> The key factor is "editing." In what sense do I mean that? Good
>>> writers do it, and the
>>> Haskell documentation does it. I mean (1) brevity and (2) good flow.
>>> To achieve brevity,
>>> you must think about the essence of each statement and trim away the
>>> unnecessary stuff.
>>> Good flow refers to how the document builds up and modifies your
>>> concepts as you read it.
>>> A document can actually mirror an effective learning process, or
>>> influence and change your
>>> process.
>>>
>>> I work with my documentation, making several editing passes. By the
>>> time I'm done, I am in
>>> a great position to write a concise and flexible program.
>>>
>>> It's interesting that not only is Haskell a concise language, but
>>> the Haskell library
>>> documentation is concise. Contrast that with the Python
>>> documentation which often wanders
>>> about into areas that are irrelevant--it could easily be cut into
>>> one third its present size.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> Beginners@haskell.org <mailto:Beginners@haskell.org>
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org <mailto:Beginners@haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>>
>>
>>
>> --
>> Jeffrey Benjamin Brown
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
--
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20160226/bf493d91/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 26 Feb 2016 17:08:06 -0500
From: Michael Orlitzky <mich...@orlitzky.com>
To: beginners@haskell.org
Subject: Re: [Haskell-beginners] general observation about programming
Message-ID: <56d0ccc6.5030...@orlitzky.com>
Content-Type: text/plain; charset=utf-8
On 02/26/2016 12:41 PM, Rein Henrichs wrote:
> Pointfree is good for reasoning about *composition*. It can often be
> more readable than pointful code when the focus of the function is on
> composition of other functions. For example, take this function from
> Bird's /Pearls of Functional Algorithm Design/:
>
> boxes = map ungroup . ungroup . map cols . group . map group
>
> Compare the pointful version:
>
> boxes matrix = map ungroup (ungroup (map cols (group (map group matrix))))
>
> Readibility is subjective, but I think many people will agree that the
> pointfree version is easier to read.
>
Sure, but does anyone have any idea what that first version is supposed
to do? It would be much better to write it out:
boxes matrix = one_big_list
where
-- The function (group . map group) produces a list of box
-- matrices, transposing each one in the process.
transposed_box_matrices = group (map group matrix)
-- The "cols" function performs a transpose, so mapping it over
-- transposed_matrices gives us the box matrices we want.
box_matrices = map cols transposed_box_matrices
-- Now we concat everything into one big matrix for some reason.
-- This is the inverse of the (group . map group) that we did
-- earlier.
one_big_list = map ungroup (ungroup box_matrices)
You don't even need to write a book to explain what it does =)
------------------------------
Message: 3
Date: Fri, 26 Feb 2016 16:53:48 -0800
From: Dennis Raddle <dennis.rad...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] general observation about programming
Message-ID:
<cakxlvoomed_dfayx-zqfhom+xuac_w-1uwmk+zout4gj8xa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, Feb 26, 2016 at 2:08 PM, Michael Orlitzky <mich...@orlitzky.com>
wrote:
> On 02/26/2016 12:41 PM, Rein Henrichs wrote:
> > Pointfree is good for reasoning about *composition*. It can often be
> > more readable than pointful code when the focus of the function is on
> > composition of other functions. For example, take this function from
> > Bird's /Pearls of Functional Algorithm Design/:
> >
> > boxes = map ungroup . ungroup . map cols . group . map group
> >
> > Compare the pointful version:
> >
> > boxes matrix = map ungroup (ungroup (map cols (group (map group
> matrix))))
> >
> > Readibility is subjective, but I think many people will agree that the
> > pointfree version is easier to read.
> >
>
> Sure, but does anyone have any idea what that first version is supposed
> to do? It would be much better to write it out:
>
>
On Haskell's readability, I am getting better at reading point-free and
idiomatic Haskell with practice, and I now think that a short Haskell
function with a meaningful type signature is much more readable that other
languages I've used.
On using short variable names, that plus point free style can make a lot of
expressions into one-liners, which I see as an advantage for comprehension
on the whole, even if you need to learn what the variables mean. Using 'm'
for a map, 'l' for a list, and other conventions helps.
Some styles make a program more readable when it is first encountered, but
my own pet project is something I've worked with for a long time, allowing
me to establish consistent and carefully thought-out naming schemes, not to
mention I'm familiar with the concepts, so I find it easier to read my own
code (say, written a long time ago) when it's concise (meaning point-free
in many cases).
One could argue that a public project needs to put greater focus on
readability to the uninitiated.
The Haskell hierarchical libraries are public, and their design seems, as
far as I can tell, intended to trade off toward the person who has become
expert in them rather than making everything obvious to the beginner. But
maybe I'm wrong about that.
D
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20160226/08444146/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 27 Feb 2016 14:21:47 +1100
From: Lyndon Maydwell <maydw...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Stack minimal dependency
specification, or dependency tree output
Message-ID:
<cam5qztyumn8jgq_kq69jgknvz1f0ar3rrc4a7kphrcood96...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi again Simon,
While `stack dot --external --depth 0` gets the job done, I had a little
play around with the idea of finding the initial nodes on the implicit
dependency graph, rather than a traversal from the initial dependency list,
and the results for this project are quite a bit shorter:
lyndon@endpin master ? ~/Silverpond/promise_backend stack dot --external |
grep -v PromiseBackend | stack-minimal-dependencies-exe
Right (fromList [Node "StringId \"errors\""
,Node "StringId \"snap\""
,Node "StringId \"wreq\""])
lyndon@endpin master ? ~/Silverpond/promise_backend stack dot --external
--depth=0
strict digraph deps {
"PromiseBackend" [style=dashed];
"PromiseBackend" -> "aeson";
"PromiseBackend" -> "base";
"PromiseBackend" -> "bytestring";
"PromiseBackend" -> "containers";
"PromiseBackend" -> "errors";
"PromiseBackend" -> "lens";
"PromiseBackend" -> "lens-aeson";
"PromiseBackend" -> "mtl";
"PromiseBackend" -> "snap";
"PromiseBackend" -> "text";
"PromiseBackend" -> "transformers";
"PromiseBackend" -> "unordered-containers";
"PromiseBackend" -> "wreq";
}
Not that it really matters, but thought it might be interesting for anyone
who was following this thread.
The code I used to compute this is awful, and lives here:
https://github.com/sordina/stack-minimal-dependencies/blob/master/app/Main.hs
:)
Later!
- Lyndon
On Thu, Feb 25, 2016 at 10:58 AM, Lyndon Maydwell <maydw...@gmail.com>
wrote:
> Hi Simon,
>
>
> > stack dot --external --depth 0
>
>
> That's exactly what I was first looking for!
>
> Cheers :)
>
>
> - Lyndon
>
> On Thu, Feb 25, 2016 at 9:55 AM, Simon Jakobi <simon.jak...@googlemail.com
> > wrote:
>
>> Hi Lyndon,
>>
>> I'd like to see some kind of tree instead, so that when I pre-install the
>>> dependencies, I can specify a minimal list, rather than a whole slew of
>>> dependencies that would be pulled in transitively anyway.
>>
>>
>> There's "stack list-dependencies" but that includes the transitive
>> dependencies.
>>
>> You can get the dependency tree (or rather dependency graph) with "stack
>> dot --external"
>>
>> "stack dot --external --depth 0" will show only the direct dependencies
>> of your project.
>>
>> More stack dot examples:
>> http://docs.haskellstack.org/en/stable/dependency_visualization/
>>
>> Cheers,
>> Simon
>>
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20160227/030fd2ba/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 92, Issue 36
*****************************************
