Send Beginners mailing list submissions to
beginners@haskell.org
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: Module import problem (Casey Rodarmor)
2. Re: Module import problem (Brandon S. Allbery KF8NH)
3. Re: Module import problem ( Chadda? Fouch? )
4. Re: Module import problem (Casey Rodarmor)
5. Exposing Ratio data constructor in prelude (Casey Rodarmor)
6. Exposing Ratio data constructor (Casey Rodarmor)
7. Re: Exposing Ratio data constructor in prelude (Brent Yorgey)
----------------------------------------------------------------------
Message: 1
Date: Sun, 28 Sep 2008 20:17:06 +0200
From: "Casey Rodarmor" <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Module import problem
To: "Christian Cheng" <[EMAIL PROTECTED]>
Cc: beginners@haskell.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Sep 28, 2008 at 7:33 PM, Christian Cheng <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 12:20 AM, Casey Rodarmor
> <[EMAIL PROTECTED]> wrote:
>>
>> On Sun, Sep 28, 2008 at 6:08 PM, Chry Cheng <[EMAIL PROTECTED]> wrote:
>> > "Casey Rodarmor" <[EMAIL PROTECTED]> writes:
>> >
>> >> Hi there!
>> >>
>> >> I have a problem with importing a module I'd like to use.
>> >>
>> >> My working directory, ~/proj, contains:
>> >> ./Haskore -- a folder containing a version of haskore, this music
>> >> thingy
>> >> ./test.hs -- random stuff using haskore
>> >>
>> >> The main file in ~/proj/Haskore is ~/proj/Haskore/Haskore.hs, which
>> >> contains the following module declaration:
>> >>> module Haskore(module HaskoreLoader) where
>> >>> import HaskoreLoader
>> >>
>> >> I've tried to put all the following in ~/proj/test.hs, with no luck:
>> >>> import Haskore -- Could not find module `Haskore':
>> >>> import Haskore.Haskore -- file name does not match module name `Haskore'
>> >>
>> >> Am I doing something wrong? Is there a way to place a module in an
>> >> arbitrary directory, without having to modify it?
>> >>
>> >> Thanks so much for your help!
>> >>
>> >> Best,
>> >> Casey Rodarmor
>> >> _______________________________________________
>> >> Beginners mailing list
>> >> Beginners@haskell.org
>> >> http://www.haskell.org/mailman/listinfo/beginners
>> >
>> > You have to tell GHC where to find Haskore. To do this, call ghc with the
>> > i option:
>> >
>> > ghc -iHaskore/
>> >
>> > then, import using:
>> >
>> > import Haskore
>> >
>>
>> Hi Chry,
>>
>> Thanks for the answer, everything works now :-)
>>
>> I must admit, I'm a little disappointed if that's the only way to get
>> it to work. On the surface of things, I don't see why one can't just
>> put a Module in some/arbitrary/directory, and then import it as
>> some.arbitrary.directory.Module. The need to use a flag on the command
>> line seems a little unnecessary.
>>
>
> I beg to differ. I don't think it's reasonable to expect the compiler
> to figure out on its own where we have stashed additional classes.
> Other programming languages have a similar requirement. For Java,
> it's the class path (e.g., javac -classpath Haskore); C/C++, the
> include directories (IIRC, gcc -I Haskore), etc.
I was fooling around with Java, and you're totally right, the module
itself must know about its full name, so you can't have a java file
which declares itself as "package Foo.Thingy;" in Bar/Foo/Thingy.java,
and then do an "import Bar.Foo.Thingy".
It is worth noting that in C and C++, a double-quoted #include will
search relative to the current source file. Even though that doesn't
have anything to do with locating the object file that you'll probably
want to link in later...
The comparison I was thinking of was with python, where a module can
be placed in an arbitrary directory, and then accessed using a
relative path. If I have 'stuff.py' that contains class 'Foo', I can
move it to 'hello/module/stuff.py', and then import it is
hello.module.stuff. A python module doesn't need to know where it
lives.
I often find myself working on computers where I don't have
administrative privileges, which means I might not be able to install
libraries in the 'right' places. This approach also makes it simple to
create self-contained projects that can easily be moved from machine
to machine, where only the local directory structure is important.
Would there be any downside to this in haskell?
>
>> Can anyone give a little insight into why this decision was made?
>>
>> Best,
>> Casey
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners
>
------------------------------
Message: 2
Date: Sun, 28 Sep 2008 14:51:25 -0400
From: "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Module import problem
To: "Casey Rodarmor" <[EMAIL PROTECTED]>
Cc: beginners@haskell.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On 2008 Sep 28, at 14:17, Casey Rodarmor wrote:
> I often find myself working on computers where I don't have
> administrative privileges, which means I might not be able to install
> libraries in the 'right' places. This approach also makes it simple to
> create self-contained projects that can easily be moved from machine
> to machine, where only the local directory structure is important.
> Would there be any downside to this in haskell?
Take a look at "ghc-pkg --user".
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon university KF8NH
------------------------------
Message: 3
Date: Sun, 28 Sep 2008 21:09:45 +0200
From: " Chadda? Fouch? " <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Module import problem
To: "Casey Rodarmor" <[EMAIL PROTECTED]>
Cc: beginners@haskell.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
2008/9/28 Casey Rodarmor <[EMAIL PROTECTED]>:
> The comparison I was thinking of was with python, where a module can
> be placed in an arbitrary directory, and then accessed using a
> relative path. If I have 'stuff.py' that contains class 'Foo', I can
> move it to 'hello/module/stuff.py', and then import it is
> hello.module.stuff.
And if you have something in hello/ it must refer to the same module
by module.stuff instead. I'm not sure it's clearer...
Anyway the hierarchical modules in Haskell means that every code must
import the same module with the same name which I find saner (though I
could wish the import/export syntax would be more advanced to allow
for shorter imports when I have a lot of imports in the same hierarchy
part).
> A python module doesn't need to know where it
> lives.
Well, it doesn't need to, but everyone else needs to, in Haskell, the
module need to know where it lives, but everyone else don't care.
>
> I often find myself working on computers where I don't have
> administrative privileges, which means I might not be able to install
> libraries in the 'right' places. This approach also makes it simple to
> create self-contained projects that can easily be moved from machine
> to machine, where only the local directory structure is important.
> Would there be any downside to this in haskell?
Note that if the modules are in the same project, they're all in the
same hierarchy (at least that's how I see a project) and so their
names are coherent with each other and with the relative directory
hierarchy, there is no problem there.
Now, I think your preoccupation has more to do with packaging several
libraries you're not sure will be available on the final machine with
your project, and reasonably, you don't want to put them all in the
same base directory (yeah, it would be a mess). I would argue that
Haskell being a compiled language, its distribution problematics
aren't exactly the same as Python... If you're just distributing an
application you presumably would just compile it on your development
setup and then distribute the executable.
But if you really want to distribute the code source in a self
sufficient package (assuming GHC on the final machine I guess ?), you
should use Cabal : it automates dependency checking, compilation and
installation with several source directory and configurable target
installation directory. It's pretty easy to use too (mainly I suggest
you do copy/paste of a good project file on Hackage).
--
Jedaï
------------------------------
Message: 4
Date: Mon, 29 Sep 2008 18:08:03 +0200
From: "Casey Rodarmor" <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Module import problem
To: beginners@haskell.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Sep 28, 2008 at 9:09 PM, Chaddaï Fouché
<[EMAIL PROTECTED]> wrote:
> 2008/9/28 Casey Rodarmor <[EMAIL PROTECTED]>:
>> The comparison I was thinking of was with python, where a module can
>> be placed in an arbitrary directory, and then accessed using a
>> relative path. If I have 'stuff.py' that contains class 'Foo', I can
>> move it to 'hello/module/stuff.py', and then import it is
>> hello.module.stuff.
>
> And if you have something in hello/ it must refer to the same module
> by module.stuff instead. I'm not sure it's clearer...
Yeah, I can see where you're coming from.
> Anyway the hierarchical modules in Haskell means that every code must
> import the same module with the same name which I find saner (though I
> could wish the import/export syntax would be more advanced to allow
> for shorter imports when I have a lot of imports in the same hierarchy
> part).
>
>> A python module doesn't need to know where it
>> lives.
>
> Well, it doesn't need to, but everyone else needs to, in Haskell, the
> module need to know where it lives, but everyone else don't care.
>
>>
>> I often find myself working on computers where I don't have
>> administrative privileges, which means I might not be able to install
>> libraries in the 'right' places. This approach also makes it simple to
>> create self-contained projects that can easily be moved from machine
>> to machine, where only the local directory structure is important.
>> Would there be any downside to this in haskell?
>
> Note that if the modules are in the same project, they're all in the
> same hierarchy (at least that's how I see a project) and so their
> names are coherent with each other and with the relative directory
> hierarchy, there is no problem there.
> Now, I think your preoccupation has more to do with packaging several
> libraries you're not sure will be available on the final machine with
> your project, and reasonably, you don't want to put them all in the
> same base directory (yeah, it would be a mess). I would argue that
> Haskell being a compiled language, its distribution problematics
> aren't exactly the same as Python... If you're just distributing an
> application you presumably would just compile it on your development
> setup and then distribute the executable.
Very true, but I still really like source distributions, even for
compiled languages. Even though it can mean headaches, a source
distribution is sometimes more portable than a binary distribution.
(Usually because a clever end user can fiddle a little bit and get it
working, whereas an incompatible binary is a useless blob.)
> But if you really want to distribute the code source in a self
> sufficient package (assuming GHC on the final machine I guess ?), you
> should use Cabal : it automates dependency checking, compilation and
> installation with several source directory and configurable target
> installation directory. It's pretty easy to use too (mainly I suggest
> you do copy/paste of a good project file on Hackage).
I'll definitely check out Cabal.
I'm a student, and so I'm always developing on personal and school
computers, as well coding with random project partners (who always
seem to be running equally random OSs). And then, to top it off, I've
got to turn in assignments without being exactly sure where the grader
is going to run them. I'm *always* wanting to use some library in a
project, and (apt-get|port|emerge) my_sweet_library is never an option
:-(
Thus my concern with portable source packages. :-)
These days I usually write crazy makefiles that try to do their best
to compile and link in all the libraries needed, wherever they might
find themselves.
>
> --
> Jedaï
>
------------------------------
Message: 5
Date: Mon, 29 Sep 2008 18:16:24 +0200
From: "Casey Rodarmor" <[EMAIL PROTECTED]>
Subject: [Haskell-beginners] Exposing Ratio data constructor in
prelude
To: beginners@haskell.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
Hej hej!
I was writing some code using Ratio, and even though I know it's
tucked behind an abstraction barrier, I really wanted access to the
Ratio data constructor ':%'. I wrote invertRatio like such:
invertRatio r = denominator r % numerator
But I really wanted to write it like this:
invertRatio (n :% d) = d % n
I understand that exposing ':%' causes problems, since it allows us
not only to pick apart ratios, but to construct bad ones that would
normally be caught when constructed with '%'. (Such as '1:%0'.)
Is there any way to avoid this, while still letting the user benefit
from the nice pattern matching syntax that exposing the data
constructor allows?
Kram,
Casey
------------------------------
Message: 6
Date: Mon, 29 Sep 2008 18:17:44 +0200
From: "Casey Rodarmor" <[EMAIL PROTECTED]>
Subject: [Haskell-beginners] Exposing Ratio data constructor
To: beginners@haskell.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
Hej hej!
I was writing some code using Ratio, and even though I know it's
tucked behind an abstraction barrier, I really wanted access to the
Ratio data constructor ':%'. I wrote invertRatio like such:
invertRatio r = denominator r % numerator
But I really wanted to write it like this:
invertRatio (n :% d) = d % n
I understand that exposing ':%' causes problems, since it allows us
not only to pick apart ratios, but to construct bad ones that would
normally be caught when constructed with '%'. (Such as '1:%0'.)
Is there any way to avoid this, while still letting the user benefit
from the nice pattern matching syntax that exposing the data
constructor allows?
Kram,
Casey Rodarmor
------------------------------
Message: 7
Date: Mon, 29 Sep 2008 12:28:47 -0400
From: Brent Yorgey <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Exposing Ratio data constructor in
prelude
To: beginners@haskell.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On Mon, Sep 29, 2008 at 06:16:24PM +0200, Casey Rodarmor wrote:
> Hej hej!
>
> I was writing some code using Ratio, and even though I know it's
> tucked behind an abstraction barrier, I really wanted access to the
> Ratio data constructor ':%'. I wrote invertRatio like such:
>
> invertRatio r = denominator r % numerator
>
> But I really wanted to write it like this:
>
> invertRatio (n :% d) = d % n
>
> I understand that exposing ':%' causes problems, since it allows us
> not only to pick apart ratios, but to construct bad ones that would
> normally be caught when constructed with '%'. (Such as '1:%0'.)
>
> Is there any way to avoid this, while still letting the user benefit
> from the nice pattern matching syntax that exposing the data
> constructor allows?
Well, one way to do it would be to write your own destructor function, like so:
nd :: Ratio a -> (a,a)
nd r = (numerator r, denominator r)
Then you could use it with a pattern guard:
invertRatio r | (n,d) <- nd r = d % n
But that's still a bit more syntactically heavyweight than what you'd
really like. The real answer to your question is views, as proposed
by Wadler in 1987 [1]. Views allow pattern matching to be abstracted
away from the actual representation of a type. Unfortunately, GHC
6.8.3 does not include views... but GHC 6.10 will! [2] Using GHC 6.10
with the -XViewPatterns extension, you could rewrite invertRatio like
this:
invertRatio (nd -> (n,d)) = d % n
Hope that answers your question!
-Brent
1. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.3532
2.
http://www.haskell.org/ghc/dist/stable/docs/users_guide/syntax-extns.html#view-patterns
>
> Kram,
> Casey
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 3, Issue 13
****************************************
