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: function application (mike h)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Apr 2016 08:36:28 +0000 (UTC)
From: mike h <mike_k_hough...@yahoo.co.uk>
To: Silent Leaf <silent.le...@gmail.com>, The Haskell-Beginners
Mailing List - Discussion of primarily beginner-level topics related
to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] function application
Message-ID:
<1000143001.2119445.1460450188744.javamail.ya...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"
I agree. I'm just seeing how far point free can be taken under different
circumstances.
Thanks for all your comments, much appreciated.
Mike
On Tuesday, 12 April 2016, 0:52, Silent Leaf <silent.le...@gmail.com> wrote:
true! no it's totally my fault, i forgot about that. I'm not exactly sure why
is that, it seems slightly absurd, limiting, to me but I guess it must be
something on the inside.
In that case, from what I know to this day, you'll have to choose either, and I
know no easy way to integrate a point-free conditional choice (in other terms,
to replace the guards in a pointfree manner) on one of the parameters, so I'd
go for the non-pointfree style, aka your original implementation, with the
guards.
of course we can merrily cheat:
test1arg :: (a -> b) -> (a -> b) -> (a -> Bool) -> a -> b
test1arg cond thenF elseF x
??? | cond x = thenF x
??? | otherwise = elseF x
then:
mc :: Integral a => a -> a
mc = test1arg (<100) (-10) (mc . mc . (+11))
it amounts to moving the guards into another function. the "if then else"
expression is very similar of course, but doesn't allow, as far as I know,
point-free style.
Anyway... all this becomes a pointless (pun unintended) search for the
point-free style at all costs. I'm not sure it's generally speaking, a very
good idea. Non-point-free style is perfectly good style in itself, and
pointfree should be in my opinion reserved to cases where it comes naturally,
where, when perhaps looking at one's definition for a function, one realizes
the presence of the argument is pointless; one very random last-minute example:
f xs = zip [0..] xs? ---> f = zip [0..]
also to the cases when the very definition of a function comes to one as
combination of other functions. beyond that, I'd say it's mostly wasted time.
I think the question is to balance the style, to always prefer clarity to
"coolness" at any rate. Sure, in many cases, a pointfree style is in my opinion
much quicker to understand, much clearer. Also, pointfree style is also a very
good exercise I think, that permits beginners (i put myself in it needless to
say) to get a better understanding of haskell's syntax, and of the whole
function paradigm in general.
As long as exercises in pointfree feats aren't hindering real programming, I'd
say there's no problem in trying to go for it whenever it's possible. Plus in
my opinion it can be fun.
2016-04-11 16:16 GMT+02:00 mike h <mike_k_hough...@yahoo.co.uk>:
Hi,
Thanks for the comprehensive and considered answers.?Maybe I'm missing
something but defining the original function to have two definitions with a
different number of args in each? causes a compiler error ie. doing
mc :: (Integral a) => a -> amc x | x < 100 = x - 10????? -- 1 arg
mc = mc . mc . (+ 11)?????? --? no args
Thanks
On Sunday, 10 April 2016, 22:29, Silent Leaf <silent.le...@gmail.com> wrote:
Mike: If you seek as I think you do, to write the function mc (partially) in
point-free style, you must know this style implies no arguments, or at least
not all arguments, mentioned, that is for example here:
mc x | x < 100 = x - 10
mc = mc . mc . (+ 11)
The second line will only be checked for pattern matching if the first one
fails, so it amounts to the "otherwise" guard as here there's no pattern, so
it's a bit like the pattern that always matches (mc _ = ...)
You'll remark I did write (mc =) and not (mc x =). Point free style amounts to
describing a function through a composition of other functions, in an
arguments-free way, here for example, (mc . mc . (+11)) being the composition
of mc twice, with the "partially-applied" function (+11) == (\x -> x + 11) ==
(11+). This partially applied notation works for all operators by the way.
And for the record, the whitespace operator is a pure myth. First you can
remove all whitespace, it still works. Second, try using the same
whitespace-induced universal right-associativity with (f a b): does it amount
to (f (a b))?
The reason for this right-associativity interpretation in (mc . mc (x + 11)) is
because (.) itself is right associative: right-directed greediness could we
say, in the vocabulary of regular expression. It's also the case of ($), and
that's why we use it to counter the natural left associativity of function
application:
f $ g a == f $ (g a) == ($) f (g a) == f (g a)?? -- (using the definition of
($) here)
instead of
f g a == (f g) a
without using ($).
The whitespace is just a meaningless character (I guess, a set of characters)
used to separate juxtaposed meaningful tokens of the language when we have
either (symbol,symbol) or (nonsymbol,nonsymbol), for example respectively (!! $
/= !!$) and (f g /= fg). whenever it's a nonsymbol and a symbol, whitespace is
not necessary (a+, +a).
Then there's the automatic, implicit function application between two
juxtaposed non-symbolic tokens. But the whitespace has never been an operator
of any kind, and is totally meaningless (and optional) in (mc . mc (x + 11)).
Especially too, it's clear no whitespace survives the tokenization during the
lexical phase of the (pre?) compilation, contrarily to all real operators like
(+).
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20160412/8fe5a1ae/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 94, Issue 10
*****************************************
