Send Beginners mailing list submissions to
[email protected]
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
[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. Package access problem (Gregory Guthrie)
2. Re: Package access problem (Brandon Allbery)
3. Re: tower hanoi problem (Dudley Brooks)
4. Re: tower hanoi problem (Dudley Brooks)
----------------------------------------------------------------------
Message: 1
Date: Tue, 17 Feb 2015 20:13:47 -0600
From: Gregory Guthrie <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [Haskell-beginners] Package access problem
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I installed diagrams, and it seems to be there, but GHCi doesn't find it. I
tried adding the local sandbox to the command line (-package-db), but still no
luck
Any suggestions?
C:\Users\guthrie>
C:\Users\guthrie>cabal install diagrams
Resolving dependencies...
All the requested packages are already installed:
diagrams-1.2
Use --reinstall if you want to reinstall anyway.
I find it in:
C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d
(diagrams-1.2, diagrams-contrib, -core, -lib, -svg)
But running: "cabal repl" or using the GHC(i) flag "-package-db=..."
fail to find it:
C:\Users\guthrie>cabal repl
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m + Diagrams
<no location info>:
Could not find module `Diagrams'
It is not a module in the current program, or in any known package.
Prelude> :m + Diagrams.Prelude
<no location info>:
Could not find module `Diagrams.Prelude'
It is not a module in the current program, or in any known package.
Prelude>
----------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150217/b8523ed8/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 17 Feb 2015 21:15:05 -0500
From: Brandon Allbery <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Package access problem
Message-ID:
<CAKFCL4WLgEnRXk2ejOO+KRo9ZHaBCWvHHAVAcmnij9fpiv=q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, Feb 17, 2015 at 9:13 PM, Gregory Guthrie <[email protected]> wrote:
> <no location info>:
>
> Could not find module `Diagrams'
>
>
"Diagrams" is not a module in any of the packages; it's just a point in the
namespace under which the actual modules reside. I see for example at
http://hackage.haskell.org/package/diagrams-core
-
- Diagrams.Core
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core.html>
- Diagrams.Core.Compile
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Compile.html>
- Diagrams.Core.Envelope
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Envelope.html>
- Diagrams.Core.HasOrigin
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-HasOrigin.html>
- Diagrams.Core.Juxtapose
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Juxtapose.html>
- Diagrams.Core.Names
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Names.html>
- Diagrams.Core.Points
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Points.html>
- Diagrams.Core.Query
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Query.html>
- Diagrams.Core.Style
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Style.html>
- Diagrams.Core.Trace
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Trace.html>
- Diagrams.Core.Transform
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Transform.html>
- Diagrams.Core.Types
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-Types.html>
- Diagrams.Core.V
<http://hackage.haskell.org/package/diagrams-core-1.2.0.5/docs/Diagrams-Core-V.html>
-
(Note that the top level "Diagrams" name on that page is italicized and not
a link; this indicates that it's just a namespace.)
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150217/20d7bd70/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 17 Feb 2015 22:56:35 -0800
From: Dudley Brooks <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] tower hanoi problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 2/16/15 7:06 PM, Doug McIlroy wrote:
>> My way of working is one problem at the time.
>> So first solve the itterate one and after that I gonna try to solve the
>> recursion one.
>> Otherwise I get confused.
> This is the crux of the matter. You must strive to think those thoughts
> in the opposite order. Then you won't get confused.
>
> Recursion takes a grand simplifying view: "Are there smaller problems of
> the same kind, from the solution(s) of which we could build a solution of
> the problem at hand?" If so, let's just believe we have a solver for the
> smaller problems and build on them. This is the recursive step.
>
> Of course this can't be done when you are faced with the smallest
> possible problem. Then you have to tell directly how to solve
> it. This is the base case.
>
> [In Hanoi, the base case might be taken as how to move a pile
> of one disc to another post. Even more simply, it might be how
> to move a pile of zero discs--perhaps a curious idea, but no more
> curious than the idea of 0 as a counting number.]
>
> A trivial example: how to copy a list (x:xs) of arbitrary length.
> We could do that if we knew how to copy the smaller list tail, xs.
> All we have to do is tack x onto the head of the copy. Lo, the recipe
> copy (x:xs) = x : copy xs
> Final detail: when the list has no elements, there is no smaller
> list to copy. We need another rule for this base case. A copy
> of an empty list is empty:
> copy [] = []
>
> With those two rules, we're done. No iterative reasoning about
> copying all the elements of the list. We can see that afterward,
> but that is not how we got to the solution.
>
> [It has been suggested that you can understand recursion thus
> > Do the first step. Then (to put it very dramatically)
> > do *everything else* in *a single step*!
> This point of view works for copy, and more generally for
> "tail recursion", which is trivially transformable to iteration.
> It doesn't work for Hanoi, which involves a fancier recursion
> pattern. The "smaller problem(s)" formulation does work.]
I simplified it (or over-dramatized it) to the point of
not-quite-correctness. I was trying to dramatize the point of how
surprising the idea of recursion is, when you first encounter it
(because I suspected that the OP had not yet "grokked" the elegance of
recursion) -- and remembering my own Aha! moment at recursive
definitions and proofs by induction in high school algebra, back when
the only "high-level" programming language was assembly. I see that I
gave the mistaken impression that that's the *only* kind of recursive
structure. What I should have said, less dramatically, is
Do the base case(s)
Then do the recursion -- whatever steps that might involve,
including possibly several recursive steps and possibly even several
single steps, interweaved in various possible orders.
You can't *start* with the recursion, or you'll get either an infinite
loop or an error.
I wouldn't quite call the conversion of tail-recursion to iteration
trivial, exactly ... you still have to *do* it, after all! And when I
did CS in school (a long time ago), the equivalence had only fairly
recently been recognized. (By computer language designers, anyway.
Maybe lambda-calculus mathematicians knew it long before that.)
Certainly the idea that compilers could do it automatically was pretty
new. If it were *completely* trivial, it would have been recognized
long before! ;^)
If you're younger you probably grew up when this idea was already
commonplace. Yesterday's brilliant insight is today's trivia!
> In many harder problems a surefire way to get confused is to
> try to think about the sequence of elementary steps in the final
> solution. Hanoi is a good case in point.
>
> Eventually you will come to see recursion as a way to confidently
> obtain a solution, even though the progress of the computation is
> too complicated to visualize. It is not just a succinct way to
> express iteration!
>
> Doug McIlroy
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
Message: 4
Date: Tue, 17 Feb 2015 23:04:21 -0800
From: Dudley Brooks <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] tower hanoi problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 2/17/15 10:56 PM, Dudley Brooks wrote:
> On 2/16/15 7:06 PM, Doug McIlroy wrote:
>>> My way of working is one problem at the time.
>>> So first solve the itterate one and after that I gonna try to solve the
>>> recursion one.
>>> Otherwise I get confused.
>> This is the crux of the matter. You must strive to think those thoughts
>> in the opposite order. Then you won't get confused.
>>
>> Recursion takes a grand simplifying view: "Are there smaller problems of
>> the same kind, from the solution(s) of which we could build a
>> solution of
>> the problem at hand?" If so, let's just believe we have a solver for the
>> smaller problems and build on them. This is the recursive step.
>>
>> Of course this can't be done when you are faced with the smallest
>> possible problem. Then you have to tell directly how to solve
>> it. This is the base case.
>>
>> [In Hanoi, the base case might be taken as how to move a pile
>> of one disc to another post. Even more simply, it might be how
>> to move a pile of zero discs--perhaps a curious idea, but no more
>> curious than the idea of 0 as a counting number.]
>>
>> A trivial example: how to copy a list (x:xs) of arbitrary length.
>> We could do that if we knew how to copy the smaller list tail, xs.
>> All we have to do is tack x onto the head of the copy. Lo, the recipe
>> copy (x:xs) = x : copy xs
>> Final detail: when the list has no elements, there is no smaller
>> list to copy. We need another rule for this base case. A copy
>> of an empty list is empty:
>> copy [] = []
>>
>> With those two rules, we're done. No iterative reasoning about
>> copying all the elements of the list. We can see that afterward,
>> but that is not how we got to the solution.
>>
>> [It has been suggested that you can understand recursion thus
>> > Do the first step. Then (to put it very dramatically)
>> > do *everything else* in *a single step*!
>> This point of view works for copy, and more generally for
>> "tail recursion", which is trivially transformable to iteration.
>> It doesn't work for Hanoi, which involves a fancier recursion
>> pattern. The "smaller problem(s)" formulation does work.]
>
> I simplified it (or over-dramatized it) to the point of
> not-quite-correctness. I was trying to dramatize the point of how
> surprising the idea of recursion is, when you first encounter it
> (because I suspected that the OP had not yet "grokked" the elegance of
> recursion) -- and remembering my own Aha! moment at recursive
> definitions and proofs by induction in high school algebra, back when
> the only "high-level" programming language was assembly. I see that I
> gave the mistaken impression that that's the *only* kind of recursive
> structure. What I should have said, less dramatically, is
>
> Do the base case(s)
> Then do the recursion -- whatever steps that might involve,
> including possibly several recursive steps and possibly even several
> single steps, interweaved in various possible orders.
>
> You can't *start* with the recursion, or you'll get either an infinite
> loop or an error.
>
> I wouldn't quite call the conversion of tail-recursion to iteration
> trivial, exactly ... you still have to *do* it, after all! And when I
> did CS in school (a long time ago), the equivalence had only fairly
> recently been recognized. (By computer language designers, anyway.
> Maybe lambda-calculus mathematicians knew it long before that.)
> Certainly the idea that compilers could do it automatically was pretty
> new. If it were *completely* trivial, it would have been recognized
> long before! ;^)
>
> If you're younger you probably grew up when this idea was already
> commonplace. Yesterday's brilliant insight is today's trivia!
BTW, since, as you and several others point out, the recursive solution
of Towers of Hanoi does *not* involve tail recursion, that's why it's
all the more surprising that there actually is a very simple iterative
solution, almost as simple to state as the recursive solution, and
certainly easier to understand and follow by a novice or non-programmer,
who doesn't think recursively.
>
>> In many harder problems a surefire way to get confused is to
>> try to think about the sequence of elementary steps in the final
>> solution. Hanoi is a good case in point.
>>
>> Eventually you will come to see recursion as a way to confidently
>> obtain a solution, even though the progress of the computation is
>> too complicated to visualize. It is not just a succinct way to
>> express iteration!
>>
>> Doug McIlroy
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 80, Issue 39
*****************************************
