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: Heterogeneous Lists (harry)
2. Re: Cabal Dependency Hell (Brandon Allbery)
3. Re: Heterogeneous Lists (Frerich Raabe)
4. Re: Heterogeneous Lists (Ertugrul S?ylemez)
5. Re: Heterogeneous Lists (Ozgur Akgun)
6. Re: cabal -j (harry)
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 May 2013 14:47:20 +0000 (UTC)
From: harry <[email protected]>
Subject: Re: [Haskell-beginners] Heterogeneous Lists
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> writes:
> Yes, it is in fact busy work and yes, it could probably be done for
> you by the compiler. I imagine the reason it isn't is simply because
> forcing heterogeneous collections where only homogeneous ones were
> intended is usually a sign of the fact that you are doing it wrong and
> usually there's a better solution. Putting in direct support for it in
> the compiler would just make the compiler more complex and effectively
> encourage bad programming. It's just not something that comes up often
> enough to warrant a compiler extension.
Several people have implied that wanting to do this suggests that I'm doing
something wrong. I can't find the code where I did this, but is there a
general anti-pattern here?
------------------------------
Message: 2
Date: Tue, 28 May 2013 10:58:51 -0400
From: Brandon Allbery <[email protected]>
Subject: Re: [Haskell-beginners] Cabal Dependency Hell
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID:
<CAKFCL4UssrC6M91osCcC1sXz_gTFKeSo=i1nu2xjum5vsxn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, May 28, 2013 at 3:37 AM, harry <[email protected]> wrote:
> Brandon Allbery <allbery.b <at> gmail.com> writes:
> > Why isn't this avoided by installing packages without inlining? Packages
> ...
> >
> > Because the performance is somewhere between horrible and abysmal.
>
> Thank you, does this mean that dynamic linking wouldn't work either?
Dynamic linking is an even bigger ball of snakes, yes. :/ A better solution
would be nice, but I'm not aware of any magic that can be applied to it.
(The GHC devs know a better solution is needed; unfortunately, the best
they've come up with is a proposal to build everything against everything
else in every possible combination....) Not that there are any better ideas
sitting around. Maybe whole program compilation, which would require all
libraries to be available in source form (and would make dynamic linking
meaningless since every compiled library would be a one-off).
--
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://www.haskell.org/pipermail/beginners/attachments/20130528/d3baf0f0/attachment-0001.htm>
------------------------------
Message: 3
Date: Tue, 28 May 2013 10:07:06 -0700
From: Frerich Raabe <[email protected]>
Subject: Re: [Haskell-beginners] Heterogeneous Lists
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On May 28, 2013, at 12:36 AM, harry <[email protected]> wrote:
> Every OO language which supports generics allows a declaration such as
> List<Show> alist, where Show is an interface. Any type implementing Show can
> be put in alist, and any Show operation can be performed on the alist's
> members. No casts, wrappers, or other special types and plumbing are needed.
>
> Why isn't it possible to do this directly in Haskell?
My impression is that you often don't have this requirement, since functions
are first-class values and you can treat them as closures. Consider this
(silly) C++:
struct Iface {
// Yields the length of the printable representation of some object, plus
some custom value.
virtual int lengthPlus( int i ) = 0;
};
struct MyString : Iface {
MyString( const std::string &s ) : m_s( s ) { }
virtual int lengthPlus( int i ) {
return m_s.size() + i;
}
std::string m_s;
};
struct MyBoolean : Iface {
MyBoolean( bool b ) : m_b( b ) { }
virtual int lengthPlus( int i ) {
return m_b ? strlen( "True" ) + i
: strlen( "False" ) + i;
}
bool m_b;
};
You could now have code like:
std::list<Iface *> l;
l.push_back( new MyString( "Sample" ) );
l.push_back( new MyBoolean( true ) );
std::list<Iface *>::const_iterator it, end = l.end();
for ( it = l.begin(); it != end; ++it ) {
std::cout << (*it)->lengthPlus( 4 );
}
Now, in Haskell you wouldn't need the interface in the first place. You could
use plain functions (I'm using slightly ugly naming here to show the parallels
to the C++ code):
MyString_lengthPlus :: String -> Int -> Int
MyString_lengthPlus s i = length s + i
MyBoolean_lengthPlus :: Bool -> Int -> Int
MyBoolean_lengthPlus True i = 4 + i
MyBoolean_lengthPlus False i = 5 + i
l :: [Int -> Int]
l = [MyString_lengthPlus "Sample", MyBoolean True]
print $ map ($ 4) l
Note how, just like in C++, the type of the actual value on which the 'map' in
the last line works on is hidden at the moment the list 'l' is populated with
values.
--
Frerich Raabe - [email protected]
www.froglogic.com - Multi-Platform GUI Testing
------------------------------
Message: 4
Date: Tue, 28 May 2013 19:08:10 +0200
From: Ertugrul S?ylemez <[email protected]>
Subject: Re: [Haskell-beginners] Heterogeneous Lists
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
harry <[email protected]> wrote:
> > (2) A type class cannot be used as a type.
>
> Yes, (2) is what I don't understand.
The question can be generalized: What is the difference between
Haskell's type classes and OOP interfaces? The main difference is that
type class instances are type-bound, while interfaces are value-bound.
That's why you can't encode the Monoid pattern as a type class, but not
as an interface.
You /can/ think of type classes as types, but not the way you do it for
OOP interfaces or base classes. A type class is a separate type that
encodes values of the type it is bound to:
data Monoid a =
Monoid {
mempty :: a,
mappend :: a -> a -> a
}
If you would store a list of monoids [Monoid X], you would store a list
of identity/addition laws for the same type X, not a list of values of
type X. This is probably not what you want.
> I recently ran into this with a GUI application, where I needed to
> process a list of widgets that were members of the same typeclass, but
> I had to wrap them all because they were different types.
Your misconception is likely that you need to /store/ widgets, because
you think in terms of memory. What you really need is /definitions/ of
widgets, which can very well have different types. Then you can combine
them using the usual monadic or applicative interface.
> So so rephrase my question, why can't type classes be used as a type?
> Is this an implementation issues, or is there a semantic problem with
> this? Creating an existential type and packing all the values seems
> like busy work which shouldn't be necessary, or at least something
> that the compiler should be doing for me.
It is necessary. Haskell's type system is simply not the same as C#'s
type system. As pointed out a number of times we don't have subtyping.
Subtyping lets you treat different types like they were the same.
Haskell simply doesn't follow this philosophy and gives us enough type
system power to encode proper abstractions instead of the catch-all
"everything is an object" approach.
This is a benefit, but it takes some time to get used to it, and usually
you see the value only /after/ that time.
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/20130528/f29e42c3/attachment-0001.pgp>
------------------------------
Message: 5
Date: Tue, 28 May 2013 18:28:06 +0100
From: Ozgur Akgun <[email protected]>
Subject: Re: [Haskell-beginners] Heterogeneous Lists
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID:
<CALzazPCQ7=q26iGGCP2j_jgC_xrqyMOfc8eaDhcPK5=twgj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi.
On 28 May 2013 18:07, Frerich Raabe <[email protected]> wrote:
>
> On May 28, 2013, at 12:36 AM, harry <[email protected]> wrote:
>
> > Every OO language which supports generics allows a declaration such as
> > List<Show> alist, where Show is an interface. Any type implementing Show
> can
> > be put in alist, and any Show operation can be performed on the alist's
> > members. No casts, wrappers, or other special types and plumbing are
> needed.
> >
> > Why isn't it possible to do this directly in Haskell?
>
> My impression is that you often don't have this requirement, since
> functions are first-class values and you can treat them as closures.
>
This might also be relevant:
http://okmij.org/ftp/Computation/Existentials.html
Hope this helps,
Ozgur.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130528/75a8ef2e/attachment-0001.htm>
------------------------------
Message: 6
Date: Wed, 29 May 2013 09:01:45 +0000 (UTC)
From: harry <[email protected]>
Subject: Re: [Haskell-beginners] cabal -j
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Brent Yorgey <byorgey <at> seas.upenn.edu> writes:
> Yes, edit your ~/.cabal/config and add/uncomment the line
>
> jobs: 12
I just tried that with the new HP, and got
cabal: Command.optionToFieldDescr: feature not implemented
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 59, Issue 38
*****************************************
