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: Comfortable handling of module hierarchies (damodar kulkarni)
2. Re: FRP (Henk-Jan van Tuyl)
3. Re: FRP (Ertugrul S?ylemez)
4. Re: Comfortable handling of module hierarchies (Edward Z. Yang)
5. Re: Comfortable handling of module hierarchies (damodar kulkarni)
6. Re: Comfortable handling of module hierarchies (Brandon Allbery)
7. Re: FRP (Heinrich Apfelmus)
----------------------------------------------------------------------
Message: 1
Date: Sun, 16 Sep 2012 16:07:41 +0530
From: damodar kulkarni <[email protected]>
Subject: Re: [Haskell-beginners] Comfortable handling of module
hierarchies
To: Karl Voelker <[email protected]>
Cc: Haskell Beginners <[email protected]>
Message-ID:
<CAD5HsyoeY0_RSGYC7SzTB=R=onngrerw+wc3vdnpmeskwvo...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Do you know any document pointing out the rationale behind this decision
about modules taken by the Haskell designers?
Thanks.
-Damodar
On Sat, Sep 15, 2012 at 9:30 PM, Karl Voelker <[email protected]> wrote:
> On Fri, Sep 14, 2012 at 6:23 PM, Christopher Howard
> <[email protected]> wrote:
> >
> > import qualified Plant as P
> >
> > P.Fruit.Raspberry.jam
>
> Short answer: P.Fruit.Raspberry.jam would work if you said:
>
> import qualified Plant.Fruit.Raspberry as P.Fruit.Raspberry
>
> Long answer:
>
> You can't have exactly what you want because the Haskell module
> namespace isn't exactly heirarchical. Here's an excerpt from the
> Haskell 98 report [1]:
>
> "The name-space for modules themselves is flat, with each module being
> associated with a unique module name (which are Haskell identifiers
> beginning with a capital letter; i.e. modid)."
>
> Notice that this doesn't allow for dots in module names. A
> commonly-provided language extension allowed dots in module names, and
> compilers took these dots as a signal to look for a module's source at
> a particular place in the directory tree, but the semantics of the
> language didn't have a heirarchy of modules.
>
> Things haven't changed much in Haskell 2010, other than the existing
> use of dots being formalized [2]:
>
> "Module names can be thought of as being arranged in a hierarchy in
> which appending a new component creates a child of the original module
> name. For example, the module Control.Monad.ST is a child of the
> Control.Monad sub-hierarchy. This is purely a convention, however, and
> not part of the language definition; in this report a modid is treated
> as a single identifier occupying a flat namespace."
>
> In your code snippet, P.Fruit.Raspberry doesn't work because although
> P refers to the same module as Plant, there isn't anything "inside" P
> (or Plant) called Fruit.Raspberry.
>
> -Karl
>
> [1] http://www.haskell.org/onlinereport/modules.html
> [2]
> http://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-980005
>
> _______________________________________________
> 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/20120916/bb143a37/attachment-0001.htm>
------------------------------
Message: 2
Date: Sun, 16 Sep 2012 13:05:23 +0200
From: "Henk-Jan van Tuyl" <[email protected]>
Subject: Re: [Haskell-beginners] FRP
To: [email protected], Ertugrul S?ylemez <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-15; format=flowed;
delsp=yes
Hello Ertugrul,
Can I use your explanation for the HaskellWiki FRP page[0]?
Regards,
Henk-Jan van Tuyl
[0] http://www.haskell.org/haskellwiki/Functional_Reactive_Programming
--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
------------------------------
Message: 3
Date: Sun, 16 Sep 2012 13:21:57 +0200
From: Ertugrul S?ylemez <[email protected]>
Subject: Re: [Haskell-beginners] FRP
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
"Henk-Jan van Tuyl" <[email protected]> wrote:
> Can I use your explanation for the HaskellWiki FRP page[0]?
Sure.
Greets,
Ertugrul
--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120916/9a551716/attachment-0001.pgp>
------------------------------
Message: 4
Date: Sun, 16 Sep 2012 14:20:23 +0200
From: "Edward Z. Yang" <[email protected]>
Subject: Re: [Haskell-beginners] Comfortable handling of module
hierarchies
To: damodar kulkarni <[email protected]>
Cc: Haskell Beginners <[email protected]>
Message-ID: <1347797972-sup-126@javelin>
Content-Type: text/plain; charset=UTF-8
Excerpts from damodar kulkarni's message of Sun Sep 16 12:37:41 +0200 2012:
> Do you know any document pointing out the rationale behind this decision
> about modules taken by the Haskell designers?
While I don't know about the rationale behind this particular decision,
Haskell's module system is purposely quite simple. Languages like ML
have more complicated module systems which allow the sort of things that
you mentioned (and more!) but while they are more expressive they are also
more complicated.
Edward
------------------------------
Message: 5
Date: Sun, 16 Sep 2012 20:34:56 +0530
From: damodar kulkarni <[email protected]>
Subject: Re: [Haskell-beginners] Comfortable handling of module
hierarchies
To: "Edward Z. Yang" <[email protected]>
Cc: Haskell Beginners <[email protected]>
Message-ID:
<cad5hsyrku_xkm3fxb0mjij+mfbhur8605d5q05qxuj-in4b...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
A feature being "more complicated" for the users to use or for the
implementers to implement cannot be the SOLE reason for that feature to be
discarded. If we consider implementation concerns, then we can see that the
Haskell designers have included many features that are certainly candidates
deserving the title: "very much complicated";
e.g. various constructs from category theory, or
support for lazy evaluation, or
features being targeted for the "Data Parallel Haskell"
and so on
In particular, I am interested in knowing whether this feature is in direct
conflict with any other features the Haskell has.
- Damodar
On Sun, Sep 16, 2012 at 5:50 PM, Edward Z. Yang <[email protected]> wrote:
> Excerpts from damodar kulkarni's message of Sun Sep 16 12:37:41 +0200 2012:
> > Do you know any document pointing out the rationale behind this decision
> > about modules taken by the Haskell designers?
>
> While I don't know about the rationale behind this particular decision,
> Haskell's module system is purposely quite simple. Languages like ML
> have more complicated module systems which allow the sort of things that
> you mentioned (and more!) but while they are more expressive they are also
> more complicated.
>
> Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120916/7d78d7ab/attachment-0001.htm>
------------------------------
Message: 6
Date: Sun, 16 Sep 2012 11:37:35 -0400
From: Brandon Allbery <[email protected]>
Subject: Re: [Haskell-beginners] Comfortable handling of module
hierarchies
To: damodar kulkarni <[email protected]>
Cc: Haskell Beginners <[email protected]>
Message-ID:
<cakfcl4xvzww95x0xlqfn-kmmaldzn8bz14lbntpszmaqcba...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Sep 16, 2012 at 11:04 AM, damodar kulkarni
<[email protected]>wrote:
> A feature being "more complicated" for the users to use or for the
> implementers to implement cannot be the SOLE reason
Haskell started out with a completely flat namespace; a minimal and
minimally disruptive "hierarchical" namespace was added, without any
special semantics and without any intent to define such semantics.
Haskell does not have the concept of modules as containers that you seem to
have; it never has had them; and there are ongoing and unresolved arguments
over whether some ML-like module system should be adopted, so it's unlikely
that they would be added in the absence of such resolution.
You apparently believe such a thing is implicitly part of namespaces and
that we need some reason to not have automatically created them to your
specifications. Could you explain where you got this notion?
--
brandon s allbery [email protected]
wandering unix systems administrator (available) (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120916/71bc8c06/attachment-0001.htm>
------------------------------
Message: 7
Date: Sun, 16 Sep 2012 18:24:41 +0200
From: Heinrich Apfelmus <[email protected]>
Subject: Re: [Haskell-beginners] FRP
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Christopher Howard wrote:
> On 09/15/2012 11:16 PM, Ertugrul S?ylemez wrote:
>> Summary: FRP is about handling time-varying values like they were
>> regular values.
>>
>
> Ouch!... Ouch!... My head is beginning to explode!
>
> So, I think I understand the main idea you just explained, but now I am
> curious about how this black magic is possible. Presumably, these
> mystical "time-varying values" would actually have to be some kind of
> partially applied function that receives a time parameter. But how do
> we, as in your example, add a literal number to a function?
As Ertugrul indicated, you first turn the literal number into a function
(namely the constant function) and then perform arithmetic with that
function.
I have a few slides that may useful in understanding the "time-varying
values as ordinary values" point better
http://apfelmus.nfshost.com/blog/2012/07/15-frp-tutorial-slides.html
Of course, keep in mind that at the end of the day, the Behavior and
Event types are going to be opaque. This is because the literal
Behavior a = Time -> a implementation would be very inefficient.
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 51, Issue 24
*****************************************
