Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Avoid Case Analyses (Mike Meyer)
2. Re: Avoid Case Analyses (Patrick Redmond)
3. How Interactive can Haskell Ultimately be? (Michael Carpenter)
----------------------------------------------------------------------
Message: 1
Date: Mon, 8 Oct 2012 05:30:46 -0500
From: Mike Meyer <[email protected]>
Subject: Re: [Haskell-beginners] Avoid Case Analyses
To: "Costello, Roger L." <[email protected]>, "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
On Sun, 7 Oct 2012 09:47:32 +0000
"Costello, Roger L." <[email protected]> wrote:
> Hi Folks,
>
> "Programs that avoid case analyses are clearer and simpler than those that
> use case analyses."
I'm not convinced. Here's the critical bits:
> Let's take a less trivial example. We will implement the floor function.
> Although Haskell already has a built-in floor function, it will be
> instructive to see how floor :: Float -> Integer can be programmed. The
> program will be developed in a systematic manner, starting with a
> specification for floor.
>
> After implementing floor without case analyses, we will then compare it
> against an implementation that uses cases analyses.
A nice straw man implementation.
> It is tempting to plunge immediately into a case analysis, considering what
> to do if x is positive, what to do if x is negative, and, possibly, what to
> do if it is zero.
Right, this is the natural way to do it with case analysis.
> Add the definitions for decrease, upper, and lower:
>
> floor x = searchFrom 0
> where searchFrom = decrease . upper . lower
> lower = until (<=x) decrease
> upper = until (>x) increase
> decrease n = n - 1
> increase n = n + 1
>
> Notice that this implementation of function floor does not use case analyses.
> The program is surprisingly short, owing mainly to the absence of a case
> analysis on the sign of x.
>
> Compare that with a version that uses case analyses:
>
> floor x | x < 0 = lower 0
> | x > 0 = (decrease . upper) 0
> | x == 0 = 0
> where lower = until (<=x) decrease
> upper = until (>x) increase
> decrease n = n - 1
> increase n = n + 1
>[...]
> The case analysis version is longer and arguably more complex.
Let's see - you constructed a set of primitives specifically designed
to avoid case analysis, and when you use those to create a solution
that is only "arguably more complex". Would you let me get away with
arguing that an imperative solution was better if I forced you to use
imperative primitives in a functional version?
If you follow that original case analysis urge, you get this version:
floor x = truncate x - if x < 0 then 1 else 0
Clearly shorter and less complex than any either of your two
versions. Further, it actually, doesn't include any more case
analysis, as it has the same "if" that is hidden in the "until"
primitive in the version without case analysis.
<mike
--
Mike Meyer <[email protected]> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
------------------------------
Message: 2
Date: Mon, 8 Oct 2012 18:10:57 -0400
From: Patrick Redmond <[email protected]>
Subject: Re: [Haskell-beginners] Avoid Case Analyses
To: "[email protected]" <[email protected]>
Message-ID:
<cahuea4glrd9rsxu34ps+obrxyglzw-hd-5xrqb4d0aajmxh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Without speaking to the point of whether case analysis introduces
unnecessary complication, I think truncate is a poor choice of example to
demonstrate this idea. As Mike deftly demonstrated we can write a simple
constant-time function which implements floor, while Roger's final version
is a non-intuitive time-inefficient linear search over the integers.
Perhaps a more complicated problem would better demonstrate Richard Bird's
quotation, however, in general I think case analysis is a very useful tool
when it illuminates the problem (as in a function over a recursive data
structure (see treeInsert on
http://learnyouahaskell.com/making-our-own-types-and-typeclasses)).
-- Patrick
On Mon, Oct 8, 2012 at 6:30 AM, Mike Meyer <[email protected]> wrote:
> On Sun, 7 Oct 2012 09:47:32 +0000
> "Costello, Roger L." <[email protected]> wrote:
>
> > Hi Folks,
> >
> > "Programs that avoid case analyses are clearer and simpler than those
> that use case analyses."
>
> I'm not convinced. Here's the critical bits:
>
> > Let's take a less trivial example. We will implement the floor function.
> Although Haskell already has a built-in floor function, it will be
> instructive to see how floor :: Float -> Integer can be programmed. The
> program will be developed in a systematic manner, starting with a
> specification for floor.
> >
> > After implementing floor without case analyses, we will then compare it
> against an implementation that uses cases analyses.
>
> A nice straw man implementation.
>
> > It is tempting to plunge immediately into a case analysis, considering
> what to do if x is positive, what to do if x is negative, and, possibly,
> what to do if it is zero.
>
> Right, this is the natural way to do it with case analysis.
>
> > Add the definitions for decrease, upper, and lower:
> >
> > floor x = searchFrom 0
> > where searchFrom = decrease . upper . lower
> > lower = until (<=x)
> decrease
> > upper = until (>x)
> increase
> > decrease n = n - 1
> > increase n = n + 1
> >
> > Notice that this implementation of function floor does not use case
> analyses. The program is surprisingly short, owing mainly to the absence of
> a case analysis on the sign of x.
> >
> > Compare that with a version that uses case analyses:
> >
> > floor x | x < 0 = lower 0
> > | x > 0 = (decrease . upper) 0
> > | x == 0 = 0
> > where lower = until (<=x) decrease
> > upper = until (>x) increase
> > decrease n = n - 1
> > increase n = n + 1
> >[...]
> > The case analysis version is longer and arguably more complex.
>
> Let's see - you constructed a set of primitives specifically designed
> to avoid case analysis, and when you use those to create a solution
> that is only "arguably more complex". Would you let me get away with
> arguing that an imperative solution was better if I forced you to use
> imperative primitives in a functional version?
>
> If you follow that original case analysis urge, you get this version:
>
> floor x = truncate x - if x < 0 then 1 else 0
>
> Clearly shorter and less complex than any either of your two
> versions. Further, it actually, doesn't include any more case
> analysis, as it has the same "if" that is hidden in the "until"
> primitive in the version without case analysis.
>
> <mike
> --
> Mike Meyer <[email protected]> http://www.mired.org/
> Independent Software developer/SCM consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20121008/fa541134/attachment-0001.htm>
------------------------------
Message: 3
Date: Mon, 08 Oct 2012 18:53:55 -0400
From: Michael Carpenter <[email protected]>
Subject: [Haskell-beginners] How Interactive can Haskell Ultimately
be?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Yep, I'm verbose in my questions. I put the core question(s) in bold.
Everything else is elaboration for clarity.
*- How interactive and "live" can GHCI make Haskell? What are the
limits?**By "live", I mean on-the-fly coding.
**- Would it be possible to make a Haskell plugin for something like the
Light Table IDE even if it required some behind-the-scenes trickery?**
**- How dependent is Haskell's interactivity on it's structure as a
language and how much of it is dependent on the given compiler?**Is it
that GHC could never provide on-the-fly coding or is it that the idea of
highly interactive coding is completely incompatible with the core
principles that make Haskell work? (static type system vs. dynamic type
system)
**- Could GHC/GHCi be used or extended to provide a more functional
reactive Haskell similar to Elm such that you could play with your code
the same way you can with SuperCollider or Chuck?*
By interactive, I mean that the language allows for the programmer to
edit the program's source as it's running and see the results of the
edit play out in the current running session without having to restart
the program. A lot of languages use this for debugging (GHCi), but I
know that this feature is typically very limited unless you have a
dynamic, reactive, and/or interpreted language. There seems to be many
tricks out there for at least giving the illusion of "live coding" such
as interpreting the files being edited and leaving everything that's not
dependent on it compiled. I've also read about having the compiler and
interpreter actively dance around each other in the source, with the
interpreter managing the files that were recently edited, providing the
slow but interactive functionality with only the code local to the
programmer's current activity, and the compiler recompiling files after
they've been left alone for a while. I totally don't know what I'm
talking about here with regard to compiler behavior, but is this
interactive behavior even possible with GHC/GHCI given how much
optimization takes place at compile time? Can you cherry pick like that?
Can you even distinguish between files anymore once it's been melted
down into C--? I'm really taking to Haskell for general purpose
programming and I'm finding little to complain about, but there is one
thing that Haskell lacks in that other expressive high-level languages
like Lisp, Python, and Ruby seem to have. Interactivity. I like that
Haskell has both a good compiler and a nice interpreter, but I don't
know whether (in the future) the two could work together to provide
GHCI's human-centric interactivity with GHC's computer-centric
optimization. Can I have good performance and eat my cake too?
I was incredibly inspired by the prototype of the Light Table IDE
project that got funding recently. I, like many, really liked how it
gave very quick feedback in multiple ways to what you are doing. That
helps me tremendously and its probably the most powerful feature a
language could ever include imo. I have no doubt that such a project can
become a successful reality, but the language that Light Table was
performing this interactivity with was Clojure and it seems like only
dynamic interpreted languages will work. Is Haskell, despite its
differences from Lisp and the fact that it is a mostly compiled
language, disqualified from granting the coder a true interactive
environment? GHCi is REALLY powerful and helpful in this regard, but it
seems limited to a debugger and a useful tool for tutorials.
I'm asking this because Haskell seems to have everything I would want in
a language that is not C. The only competitor to it as a functional
language, in my opinion, is Lisp because of this interactivity. Haskell
seems to be doing everything right as a modern, high-level, functional
language, but it would be perfect (for me) if it further reduced the
barrier between the coder and the code by supporting this interactive
paradigm. Interactivity is a killer feature for me and I love things
like the friendly interactive shell for their focus on it.
I've used Vim plugins before for compiled languages where my changes
were automatically compiled as I made them and a live preview presented
after each compilation. In this sense, I know that virtually any
language can act like you are directly affecting your software during
run-time, but I'm talking about the sweet spot between that fake method
and something like SuperCollider where musicians can modify their code
in real-time as their code runs in real-time and not suffer from any
interruptions or sudden delays - the source language is the same
language that you use to interface with it. I think this is the ideal
way to program and I believe it is an important feature for any language
that aims to serve the human and not the machine.
I want to use Haskell's high-level, expressive, and modular language as
the way to play with the code I've written. Whether it's for debugging,
experimentation, scripting, or learning and exploring. If this is
possible (even if it's just theory and speculation for now), Haskell
will be that language that lets me code the way I want to.
Sorry for the long message, I didn't want any ambiguity to my question.
- Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20121008/3e056e08/attachment.htm>
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 52, Issue 11
*****************************************
