Re: [Haskell-cafe] haskell platform broken in ubuntu

[Vagif Verdi]

Oops my bad. The script downloads and installs binary, already compiled 
ghc. 

So it certainly does not take 2 hours, i just did it on 2 computers and it 
takes less than a couple of minutes. I did not though install the entire 
haskell platform, only ghc itself.

On Friday, October 4, 2013 10:19:39 PM UTC-7, rusi wrote:
>
> On Sat, Oct 5, 2013 at 9:18 AM, Vagif Verdi 
> > wrote:
>
>> That will give you only ghc 7.6.2. If you want latest haskell-platform, 
>> source compile is the only option. And btw it is not THAT painful :)
>> You run the script, wait 2-3 minutes and tada!
>>
>>
> Ok so someone is very confused -- maybe me :-)
>
>
> http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04
>
> seems to say that compiling from source takes like two full nights!!
>  
> Am I missing something?
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell platform broken in ubuntu

[Shrivats]

Rustom,

I've not looked at your forums link, what Vagif might be referring to is,
since you've already got your compiler installed, installing the platform
is /just/ compiling the remaining modules that are part of the platform. Of
course, building the compiler from source would take a very long time. :-)

Shrivats
On Oct 5, 2013 10:50 AM, "Rustom Mody"  wrote:

> On Sat, Oct 5, 2013 at 9:18 AM, Vagif Verdi  wrote:
>
>> That will give you only ghc 7.6.2. If you want latest haskell-platform,
>> source compile is the only option. And btw it is not THAT painful :)
>> You run the script, wait 2-3 minutes and tada!
>>
>>
> Ok so someone is very confused -- maybe me :-)
>
>
> http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04
>
> seems to say that compiling from source takes like two full nights!!
>
> Am I missing something?
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Henk-Jan van Tuyl]

On Wed, 02 Oct 2013 12:24:25 +0200, Atze Dijkstra  wrote:


Hi,

as for wxHaskell, it is currently maintained at  
https://github.com/wxHaskell/wxHaskell, compilable with wxWidgets 2.9.5  
and GHC 7.6. Work is underway to fix various bugs introduced over time  
by changes in wxWidgets, but we (i.e.  
https://github.com/wxHaskell?tab=members) hope to release & announce in  
not too much time.


Not all members are publicly visible at the moment; the members must login  
and change visibility at this page.


Regards,
Henk-Jan van Tuyl


--
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell platform broken in ubuntu

[Rustom Mody]

On Sat, Oct 5, 2013 at 9:18 AM, Vagif Verdi  wrote:

> That will give you only ghc 7.6.2. If you want latest haskell-platform,
> source compile is the only option. And btw it is not THAT painful :)
> You run the script, wait 2-3 minutes and tada!
>
>
Ok so someone is very confused -- maybe me :-)

http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04

seems to say that compiling from source takes like two full nights!!

Am I missing something?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell platform broken in ubuntu

[Vagif Verdi]

That will give you only ghc 7.6.2. If you want latest haskell-platform, 
source compile is the only option. And btw it is not THAT painful :)
You run the script, wait 2-3 minutes and tada!

On Friday, October 4, 2013 8:44:29 PM UTC-7, rusi wrote:
>
>
>
> On Sat, Oct 5, 2013 at 9:05 AM, Vagif Verdi 
> > wrote:
>
>> 13.04 has packages for ghc 7.6.2
>>
>> It is easy to install latest haskell platform though.
>>
>> Just run this script: 
>> https://github.com/chrisprobst/ubuntu-raring-haskell
>>
>>
> I was hoping that something a little less painful than a full from-source 
> install is available/known.
>
> At  
> http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04
>  
> I find this -- basically the platform dependencies seem to have been made 
> explicit. 
>
> sudo apt-get install ghc alex cabal-install happy libghc-cgi-dev 
> libghc-fgl-dev libghc-glut-dev libghc-haskell-src-dev libghc-html-dev 
> libghc-http-dev libghc-hunit-dev libghc-mtl-dev libghc-network-dev 
> libghc-opengl-dev libghc-parallel-dev libghc-parsec3-dev 
>  libghc-quickcheck2-dev libghc-regex-base-dev libghc-regex-compat-dev 
>  libghc-regex-posix-dev libghc-stm-dev libghc-syb-dev  libghc-text-dev 
>  libghc-transformers-dev  libghc-xhtml-dev libghc-zlib-dev
>
> I was wondering if others know it as an ok approach or are there problems?
>
> Rusi
>
>  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell platform broken in ubuntu

[Rustom Mody]

On Sat, Oct 5, 2013 at 9:05 AM, Vagif Verdi  wrote:

> 13.04 has packages for ghc 7.6.2
>
> It is easy to install latest haskell platform though.
>
> Just run this script: https://github.com/chrisprobst/ubuntu-raring-haskell
>
>
I was hoping that something a little less painful than a full from-source
install is available/known.

At
http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04
I find this -- basically the platform dependencies seem to have been made
explicit.

sudo apt-get install ghc alex cabal-install happy libghc-cgi-dev
libghc-fgl-dev libghc-glut-dev libghc-haskell-src-dev libghc-html-dev
libghc-http-dev libghc-hunit-dev libghc-mtl-dev libghc-network-dev
libghc-opengl-dev libghc-parallel-dev libghc-parsec3-dev
 libghc-quickcheck2-dev libghc-regex-base-dev libghc-regex-compat-dev
 libghc-regex-posix-dev libghc-stm-dev libghc-syb-dev  libghc-text-dev
 libghc-transformers-dev  libghc-xhtml-dev libghc-zlib-dev

I was wondering if others know it as an ok approach or are there problems?

Rusi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell platform broken in ubuntu

[Vagif Verdi]

13.04 has packages for ghc 7.6.2

It is easy to install latest haskell platform though.

Just run this script: https://github.com/chrisprobst/ubuntu-raring-haskell


On Friday, October 4, 2013 8:11:46 PM UTC-7, rusi wrote:
>
> I just upgraded my ubuntu laptop to 13.04 and haskell platform is gone!!
>
>
> http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04
>
> What is the current status on this?
> Is 13.10 going to correct this?
>  
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] haskell platform broken in ubuntu

[Rustom Mody]

I just upgraded my ubuntu laptop to 13.04 and haskell platform is gone!!

http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04

What is the current status on this?
Is 13.10 going to correct this?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Alp Mestanogullari]

If these said libraries let us write a good API on top, then perfect! The
problem is to actually pick the ones fulfilling our needs I think, all the
major candidatures have pretty serious drawbacks, AFAIK.


On Sat, Oct 5, 2013 at 12:36 AM, Robin KAY  wrote:

> Dear Alp,
>
> Alp Mestanogullari wrote:
> [snip]
>
>  I have been willing to have a nice GUI DSEL with good aesthetics for a
>> while. I think the hardest part wouldn't be the API, but really what
>> library we use underneath so that it's cross-platform and easy to install
>> for everyone. But I would love for something like that to happen and am
>> very interested in this.
>>
> Herein lies, for my purposes, the downfall of attempts to build GUI
> tool-kits on top of a blank canvas. From the perspective of binding to the
> platform, getting the basic functionality of a cross-platform GLUT or SDL
> equivalent isn't terribly difficult. You can layer your own widget system
> on top but even if you don't care about native look and feel (and I don't
> particularly), there are still three big functionality hurdles in my mind
> to building serious applications:-
>
> i) Proper text rendering is more difficult than placing one glyph after
> another on a line. You need to bind to each platform's text rendering
> engine: Pango/others, Uniscribe, and Core Text.
> ii) Proper text input is more difficult than listening for key press and
> release events. You need to bind to the each platform's input method
> system: XIM/IBus/others, IMM, and NSTextInputClient.
> iii) Proper accessibility is just difficult.
>
> There are plenty of applications where that doesn't matter and there are
> lots of attractive things about a pure Haskell implementation with
> beautiful high-level API. However, from my perspective, there are also
> attractions to outsourcing as much of that work as possible to existing
> libraries on the other side of the FFI even though that seems to bring us
> down to lower-level.
>
> Regards,
>
> --
> Robin KAY
>
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>



-- 
Alp Mestanogullari
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Calling Python from Haskell

[Arjun Comar]

Manuel-
Try my fork of the MissingPy library, I've brought it up to date and it
seems to function ok with current ghc/python.

www.github.com/arjuncomar/missingpy.git

The standalone branch also removes a lot of the extra dependencies
MissingPy has for extra functionality you probably don't need.

Thanks,
Arjun


On Fri, Oct 4, 2013 at 7:08 PM, Manuel Gómez  wrote:

> Hi list,
>
> What’s the preferred way of calling into Python from Haskell?  I’ve
> found MissingPy[0], but it seems to be somewhat bitrotten and a couple
> of experiments yielded segfaults.  There’s also the cpython
> package[1], but that seems to require Python 3.3, and I’m trying to
> call into code written for 2.7.
>
> Are there any other alternatives, apart from direct execution of a
> Python interpreter with forkProcess and such?
>
> [0]: 
> [1]: 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Seeking Control.Lens Combinator

[Charlie Paul]

Hello,

I'm looking for a combinator along the lines of
(&&&) :: Lens' a b -> Lens' a b' -> Lens' a (b,b')
I can see how it could lead to lenses that don't follow the laws, but
for Lenses which are somehow independent (like _1 and _2), it works
perfectly well. Is there a way in lens to specify this "independence"?

Thank you,

Charles Paul
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Calling Python from Haskell

[Manuel Gómez]

Hi list,

What’s the preferred way of calling into Python from Haskell?  I’ve
found MissingPy[0], but it seems to be somewhat bitrotten and a couple
of experiments yielded segfaults.  There’s also the cpython
package[1], but that seems to require Python 3.3, and I’m trying to
call into code written for 2.7.

Are there any other alternatives, apart from direct execution of a
Python interpreter with forkProcess and such?

[0]: 
[1]: 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Robin KAY]

Dear Alp,

Alp Mestanogullari wrote:
[snip]
I have been willing to have a nice GUI DSEL with good aesthetics for a 
while. I think the hardest part wouldn't be the API, but really what 
library we use underneath so that it's cross-platform and easy to 
install for everyone. But I would love for something like that to 
happen and am very interested in this.
Herein lies, for my purposes, the downfall of attempts to build GUI 
tool-kits on top of a blank canvas. From the perspective of binding to 
the platform, getting the basic functionality of a cross-platform GLUT 
or SDL equivalent isn't terribly difficult. You can layer your own 
widget system on top but even if you don't care about native look and 
feel (and I don't particularly), there are still three big functionality 
hurdles in my mind to building serious applications:-


i) Proper text rendering is more difficult than placing one glyph after 
another on a line. You need to bind to each platform's text rendering 
engine: Pango/others, Uniscribe, and Core Text.
ii) Proper text input is more difficult than listening for key press and 
release events. You need to bind to the each platform's input method 
system: XIM/IBus/others, IMM, and NSTextInputClient.

iii) Proper accessibility is just difficult.

There are plenty of applications where that doesn't matter and there are 
lots of attractive things about a pure Haskell implementation with 
beautiful high-level API. However, from my perspective, there are also 
attractions to outsourcing as much of that work as possible to existing 
libraries on the other side of the FFI even though that seems to bring 
us down to lower-level.


Regards,

--
Robin KAY

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Newclasses

[Stijn van Drongelen]

On Fri, Oct 4, 2013 at 10:31 PM, Wvv  wrote:

> Newclasses are something like instances, but out of scope. In a baggage.
>

So under the hood of GHC, newclasses would be partially filled in
dictionaries.

We already have too many classes: (...)
>
> We can't divide all classes to atimic ones.
>

As you have seen, we can. As you also see, it is a little impractical.

Main purpose of newclasses is to make instances as minimal as possible. In
> many cases empty.
>
> About newclass and compose data, we can do next:
>
>newclass Foo [a] => FooList a where {containerMainipulation=...}
>
>newclass Foo (Set a) => FooSet a where {containerMainipulation=...}
>
>newclass Foo (Sequence a) => FooSeq a where {containerMainipulation=...}
>
> so now I can switch any container of my data, changing only name of
> newclass:
>
>   instance FooList MyData where {dataMainipulation=...}
>

You can already solve that in Haskell 98:

class Foo2 f where { containerManipulation = ... }
instance Foo2 [] where { ... }
instance Foo2 Set where { ... }
instance Foo2 Sequence where { ... }

class (Foo2 f) => Foo1 f a where { dataManipulation = ... }

Or even:

class Foo' a where { dataManipulation' = ... }
dataManipulation = dataManipulation' yourDefaultContainerManipulation

Remember: the only special things about type classes is that they are types
that can/must be implicit. You can (almost?) always replace them by
explicit parameters.

Or let I have an MyArrow data. And I need some semigroupoid manipulations.
> I just write
>
>   instance ArrSemigroupoid MyArrow --empty
>
> that's all, I plug-in, let's just use semigroupoids functions!
>
> Or I have MyMonad and I want some Functor, so I just plug-in:
>
>   instance MFunctor MyMonad   --empty
>
> that's all.
> I also need some Applicative! Easy:
>
>   instance MApplicative MyMonad   --empty again
>
> done!
>

Let's see how many lines of code this costs in Haskell 98:

instance Monad MyMonad where { ... }
instance Functor MyMonad where
fmap = liftM
instance Applicative MyMonad where
pure = return
(<*>) = ap

Only three lines more, and they're readable.

I think newclasses are not solving the existing problems, as you're only
removing three well-understood lines of code in the above example, while
people have to look up what you mean by MFunctor and MApplicative.

I think default superclass instances are a much better idea, or
alternatively, the ConstraintSynonymInstances I previously mentioned (but
not both -- they'll probably bite each other).

-Stijn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Newclasses

[Wvv]

Newclasses are something like instances, but out of scope. In a baggage.
We don't use them for interfere their functions.
This why newclasses never overlap each other and between them and any
instances.
We use newclasses to plug-in/connect to any related class or combine data


Replying to you question, yes, instance of newclass desugar to instance of
class:

  instance BMonad MyBind where {return= ...}

desugar into 

  instance Monad MyBind where {return= ...; (>>=) = (>>-)}

We already have too many classes: look at
Edward Kmett
http://hackage.haskell.org/package/semigroupoids
13 dependent classes (from Foldable to MonadPlus)
http://hackage.haskell.org/package/category-extras
30-60 dependent class
http://hackage.haskell.org/package/lens
11 dependent classes

We can't divide all classes to atimic ones. 
I do not want to implement all depended class instances, even of atomic, if
I want to work with hight class only.
But I want easy connection with any related class! And newclasses solve this
situation.

Also in reality we have several realizations of same class/compose data and
we want to mix them for better realizations. Newclasses allows switch them
as engines! Easy.


Main purpose of newclasses is to make instances as minimal as possible. In
many cases empty.

About newclass and compose data, we can do next:

   newclass Foo [a] => FooList a where {containerMainipulation=...}

   newclass Foo (Set a) => FooSet a where {containerMainipulation=...}

   newclass Foo (Sequence a) => FooSeq a where {containerMainipulation=...}

so now I can switch any container of my data, changing only name of
newclass:

  instance FooList MyData where {dataMainipulation=...}


Or let I have an MyArrow data. And I need some semigroupoid manipulations.
I just write

  instance ArrSemigroupoid MyArrow --empty

that's all, I plug-in, let's just use semigroupoids functions!

Or I have MyMonad and I want some Functor, so I just plug-in:

  instance MFunctor MyMonad   --empty

that's all.
I also need some Applicative! Easy:

  instance MApplicative MyMonad   --empty again

done!


About conflicts, I don't understand a bit. Which ones? We catch Overlapped
instances or even Incoherent instances at once we add both newclass
instances of the same class.



John Lato-2 wrote
> I meant to say, does it mean that by
> writing a BMonad instance a Monad instance would be automatically
> generated?  If so, that seems like it would cause conflicts in many cases.
> Regardless, I think "newclass" needs to be better specified if you want
> other people to be able to support it.
> 
> 
> On Thu, Oct 3, 2013 at 7:53 PM, John Lato <

> jwlato@

> > wrote:
> 
>> I don't really understand what a "newclass" is supposed to be.
>>
>>
>> On Thu, Oct 3, 2013 at 2:15 PM, Wvv <

> vitea3v@

> > wrote:
>>
>>>
>>> newclass Bind a => Monad a => BMonad a where { (>>=) = (>>-) }
>>
>>
>> I think this means that `BMonad` is supposed to be a new class that has
>> both Bind and Monad in scope, the same as
>>
>>   class (Bind a, Monad a) => BMonad a
>>
>> except that the Monad instance's (>>=) is replaced by (>>-).
>>
>> If that's what "newclass" means, it seems absolutely pointless.
>>
>> Does it instead mean that one could write
>>
>>   instance Bind MyType where
>>
>>   instance BMonad MyType
>>
> 
> ___
> Haskell-Cafe mailing list

> Haskell-Cafe@

> http://www.haskell.org/mailman/listinfo/haskell-cafe





--
View this message in context: 
http://haskell.1045720.n5.nabble.com/Newclasses-tp5737596p5737792.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] building a FFI library with cabal

[Tad Doxsee]

Hi,

I'm trying to create an FFI library to CHOLMOD (
http://www.cise.ufl.edu/research/sparse/cholmod/) but am having problems.

My project is here: github.com/tdox/hcholmod.  I can link an executable
with the build script in the examples directory (line 4).  But line 7 does
not work (I get undefineds for functions that are in cholmod.a. Also, I
can't build example1 with cabal.  (Uncommenting the -- lines in
hcholmod.cabal results is similar undefineds.)

I would appreciate any help or hints.

Thanks,

Tad
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Machine Learning Startup Seeks Software Architect

[Charles Weitzer]

My name is Charles Weitzer.  I have a client with a startup quantitative
hedge fund located in Northern California. The Fund currently manages a very
healthy amount of capital.  The founders have PhD's in Computer Science from
Stanford and in Statistics from Berkeley. They have made unpublished
discoveries in the field of Machine Learning and in other areas as well.
This is a small, nimble company that is going to be the next big thing in
terms of quantitative strategies and systems.  

 

The team is looking for an extremely talented software architect to design
and build a new trading system and to rebuild their current system.  The
position is very challenging intellectually and involves architecting and
implementing a diverse set of core infrastructures, including new production
systems, scientific-computing environments, and modern data stores. From the
company's point of view, this is a distributed computing problem. The
position is definitely high-impact and the scope of work mostly greenfield.
There is quite a bit of freedom in the choice of software tooling (e.g. it
doesn't have to be C++ or Java and they are very open to Erlang, Scala,
Haskell, and others).

 

Qualifications include a proven track record of writing correct,
well-designed software, solving hard problems and delivering complex
projects on time. You should preferably have experience with high assurance,
distributed, fault-tolerant systems. Experience with functional programming
as well as real-time, low-latency, cache-friendly systems is a very big
bonus. They are getting big fast, so a willingness to take initiative and a
gritty determination to produce is essential. The title, scope, and level of
seniority is very flexible. As well, given their returns, this is a chance
to become extremely wealthy.

  

Join a team that includes faculty at premier universities and PhD's from
top-tier schools, led by the founder and CEO of a successful Internet
infrastructure startup. You will have high-impact, and can expect frequent
interaction with the researchers, officers, and founders.

 

Compensation and benefits are highly competitive. 

 

If you are interested or just curious, let me know the best way to start a
dialog. 

 

If you know of someone who you would highly recommend, I would appreciate it
if you could forward this on to them.

 

Talk soon,

 

Charles Weitzer

 

CEO\Senior Recruiter

Charles Weitzer and Associates, Inc.

Global Financial Recruiting Services

  char...@charlesweitzer.com

Voice: USA (510) 558-9182

 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Alp Mestanogullari]

Yes, sorry, why I brought up haskell-game wasn't clear. I meant to say
there are already quite a few people willing to improve the situation of
graphics programming in Haskell (may it be GUI, games, visualization, ...).
And I think we should definitely talk to each other and try to come up with
something good and that we would be proud of using, and that fits with the
kind of composability and simplicity we can get with libraries from other
domains.

I just consider haskell-game a first step in that direction.


On Fri, Oct 4, 2013 at 5:23 PM, Jake McArthur wrote:

> I don't think I would quite say haskell-game is quite relevant. For that
> matter, the implementation on GitHub is not very good. It's too complicated
> to scale and too specialized. I've been starting a fresh implementation,
> since I learned a lot about what I really want to do writing that, but it
> is not public yet.
>
> That said, I think our efforts on haskell-game are definitely
> complementary with efforts to improve GUI programming with Haskell, and we
> should collaborate where it makes sense.
>
>
> On Fri, Oct 4, 2013 at 11:19 AM, Alp Mestanogullari 
> wrote:
>
>> Hi guys,
>>
>> I have been willing to have a nice GUI DSEL with good aesthetics for a
>> while. I think the hardest part wouldn't be the API, but really what
>> library we use underneath so that it's cross-platform and easy to install
>> for everyone. But I would love for something like that to happen and am
>> very interested in this.
>>
>> Note that people from #haskell-game are experimenting a bit (I think it's
>> mostly Jake McArthur's work for now), see the brainstorming (ideas) and
>> graphics (partial impl) repositories at [1].
>>
>> [1]: https://github.com/haskell-game
>>
>>
>> On Thu, Oct 3, 2013 at 12:28 AM, Conal Elliott  wrote:
>>
>>> Interesting. How are the aesthetics? Can you point me to screen shots?
>>>
>>> It'd be a lot of work, but one cool project would be to create
>>> *beautiful* GUI elements using OpenGL programmable shaders. Given the speed
>>> of GPUs, we could afford to put a lot into visual details.
>>>
>>> A complementary project is designing a semantically precise and elegant
>>> ("denotative"/"genuinely functional" to use Peter Landin's terms) GUI DSEL
>>> that would be simpler and more powerful than the conventional OO-inspired
>>> libraries we have so much trouble getting to work in Haskell. I've thought
>>> about this sort of thing on and off for a very long time and would be happy
>>> to be involved if others are interested also.
>>>
>>> Together, these two efforts would yield an approach to GUIs that is
>>> beautiful inside and out.
>>>
>>> -- Conal
>>>
>>>
>>>
>>> On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu  wrote:
>>>
 No. GLFW does not give you any UI elements, just basic windowing and
 input handling.

 Euterpea has a UI layer on top of GLFW that provides text boxes and
 sliders, etc, entirely written in Haskell.

 On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott  wrote:
 > Hi Paul. Is there a way to use GLFW with GUI elements other than
 OpenGL
 > display windows, e.g., text boxes and sliders?  -- Conal
 >
 >
 > On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu  wrote:
 >>
 >> Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by
 >> installing libraries with --enable-shared and loading a GLFW program
 >> into GHCi. Using ghci -fno-ghci-sandbox, everything works great
 >> including closing and restarting GL window multiple times. Can't wait
 >> for the  official release of GHC 7.8!
 >>
 >> On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald
 >>  wrote:
 >> > thats the linker bug.
 >> >
 >> > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on
 >> > #haskell-game
 >> > in recent memory. GHCI + foreign libs should work fine now (modulo
 >> > thread
 >> > local storage related thing).
 >> >
 >> > the historical element doesn't matter any more.
 >> >
 >> > To the best of my knowledge, all such issues should be gone.
 Anyone who
 >> > cares about making sure GHCI+ gui libs play nice, PLEASE test with
 HEAD.
 >> >
 >> > the better this issue is properly tested (which i believe it has
 been),
 >> > the
 >> > more we can actually prevent it from happening. This requires
 people to
 >> > test
 >> > with HEAD GHCi now, rather than doing archaeology.
 >> >
 >> > anyone who cares, please play with GHCI in HEAD. If your lib
 doesn't
 >> > work
 >> > with ghci, please report a bug. It would be a new bug because it
 wont'
 >> > be
 >> > the previous reasons it hasnt' worked.
 >> >
 >> >
 >> > tl;dr to the best of my knowledge this issue is resolved in HEAD.
 Test
 >> > HEAD.
 >> > Help us make sure it stays resolved by testing HEAD.
 >> >
 >> > thanks
 >> > -Carter
 >> >
 >> >
 >> >
 >

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Jake McArthur]

I don't think I would quite say haskell-game is quite relevant. For that
matter, the implementation on GitHub is not very good. It's too complicated
to scale and too specialized. I've been starting a fresh implementation,
since I learned a lot about what I really want to do writing that, but it
is not public yet.

That said, I think our efforts on haskell-game are definitely complementary
with efforts to improve GUI programming with Haskell, and we should
collaborate where it makes sense.


On Fri, Oct 4, 2013 at 11:19 AM, Alp Mestanogullari wrote:

> Hi guys,
>
> I have been willing to have a nice GUI DSEL with good aesthetics for a
> while. I think the hardest part wouldn't be the API, but really what
> library we use underneath so that it's cross-platform and easy to install
> for everyone. But I would love for something like that to happen and am
> very interested in this.
>
> Note that people from #haskell-game are experimenting a bit (I think it's
> mostly Jake McArthur's work for now), see the brainstorming (ideas) and
> graphics (partial impl) repositories at [1].
>
> [1]: https://github.com/haskell-game
>
>
> On Thu, Oct 3, 2013 at 12:28 AM, Conal Elliott  wrote:
>
>> Interesting. How are the aesthetics? Can you point me to screen shots?
>>
>> It'd be a lot of work, but one cool project would be to create
>> *beautiful* GUI elements using OpenGL programmable shaders. Given the speed
>> of GPUs, we could afford to put a lot into visual details.
>>
>> A complementary project is designing a semantically precise and elegant
>> ("denotative"/"genuinely functional" to use Peter Landin's terms) GUI DSEL
>> that would be simpler and more powerful than the conventional OO-inspired
>> libraries we have so much trouble getting to work in Haskell. I've thought
>> about this sort of thing on and off for a very long time and would be happy
>> to be involved if others are interested also.
>>
>> Together, these two efforts would yield an approach to GUIs that is
>> beautiful inside and out.
>>
>> -- Conal
>>
>>
>>
>> On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu  wrote:
>>
>>> No. GLFW does not give you any UI elements, just basic windowing and
>>> input handling.
>>>
>>> Euterpea has a UI layer on top of GLFW that provides text boxes and
>>> sliders, etc, entirely written in Haskell.
>>>
>>> On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott  wrote:
>>> > Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL
>>> > display windows, e.g., text boxes and sliders?  -- Conal
>>> >
>>> >
>>> > On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu  wrote:
>>> >>
>>> >> Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by
>>> >> installing libraries with --enable-shared and loading a GLFW program
>>> >> into GHCi. Using ghci -fno-ghci-sandbox, everything works great
>>> >> including closing and restarting GL window multiple times. Can't wait
>>> >> for the  official release of GHC 7.8!
>>> >>
>>> >> On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald
>>> >>  wrote:
>>> >> > thats the linker bug.
>>> >> >
>>> >> > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on
>>> >> > #haskell-game
>>> >> > in recent memory. GHCI + foreign libs should work fine now (modulo
>>> >> > thread
>>> >> > local storage related thing).
>>> >> >
>>> >> > the historical element doesn't matter any more.
>>> >> >
>>> >> > To the best of my knowledge, all such issues should be gone. Anyone
>>> who
>>> >> > cares about making sure GHCI+ gui libs play nice, PLEASE test with
>>> HEAD.
>>> >> >
>>> >> > the better this issue is properly tested (which i believe it has
>>> been),
>>> >> > the
>>> >> > more we can actually prevent it from happening. This requires
>>> people to
>>> >> > test
>>> >> > with HEAD GHCi now, rather than doing archaeology.
>>> >> >
>>> >> > anyone who cares, please play with GHCI in HEAD. If your lib doesn't
>>> >> > work
>>> >> > with ghci, please report a bug. It would be a new bug because it
>>> wont'
>>> >> > be
>>> >> > the previous reasons it hasnt' worked.
>>> >> >
>>> >> >
>>> >> > tl;dr to the best of my knowledge this issue is resolved in HEAD.
>>> Test
>>> >> > HEAD.
>>> >> > Help us make sure it stays resolved by testing HEAD.
>>> >> >
>>> >> > thanks
>>> >> > -Carter
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu  wrote:
>>> >> >>
>>> >> >> I reported a problem with statically linked GLFW library on Mac OS
>>> X
>>> >> >> Lion in this thread:
>>> >> >>
>>> >> >>
>>> http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html
>>> >> >>
>>> >> >> I do not know why this is broken on Mac OS X Lion, but not on
>>> Linux or
>>> >> >> Windows. There was an EnableGUI hack for GHC 7.2 (and previous
>>> >> >> versions) and OS X version before Lion, but it no longer works. So
>>> I'm
>>> >> >> not sure if it is OS X Lion, or GLFW, or GHC, or a combination of
>>> them
>>> >> >> that caused this problem.
>>> >> >>
>>> >> >> Regards,
>>> >> >> Paul Liu
>>> >>

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Alp Mestanogullari]

Hi guys,

I have been willing to have a nice GUI DSEL with good aesthetics for a
while. I think the hardest part wouldn't be the API, but really what
library we use underneath so that it's cross-platform and easy to install
for everyone. But I would love for something like that to happen and am
very interested in this.

Note that people from #haskell-game are experimenting a bit (I think it's
mostly Jake McArthur's work for now), see the brainstorming (ideas) and
graphics (partial impl) repositories at [1].

[1]: https://github.com/haskell-game


On Thu, Oct 3, 2013 at 12:28 AM, Conal Elliott  wrote:

> Interesting. How are the aesthetics? Can you point me to screen shots?
>
> It'd be a lot of work, but one cool project would be to create *beautiful*
> GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we
> could afford to put a lot into visual details.
>
> A complementary project is designing a semantically precise and elegant
> ("denotative"/"genuinely functional" to use Peter Landin's terms) GUI DSEL
> that would be simpler and more powerful than the conventional OO-inspired
> libraries we have so much trouble getting to work in Haskell. I've thought
> about this sort of thing on and off for a very long time and would be happy
> to be involved if others are interested also.
>
> Together, these two efforts would yield an approach to GUIs that is
> beautiful inside and out.
>
> -- Conal
>
>
>
> On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu  wrote:
>
>> No. GLFW does not give you any UI elements, just basic windowing and
>> input handling.
>>
>> Euterpea has a UI layer on top of GLFW that provides text boxes and
>> sliders, etc, entirely written in Haskell.
>>
>> On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott  wrote:
>> > Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL
>> > display windows, e.g., text boxes and sliders?  -- Conal
>> >
>> >
>> > On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu  wrote:
>> >>
>> >> Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by
>> >> installing libraries with --enable-shared and loading a GLFW program
>> >> into GHCi. Using ghci -fno-ghci-sandbox, everything works great
>> >> including closing and restarting GL window multiple times. Can't wait
>> >> for the  official release of GHC 7.8!
>> >>
>> >> On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald
>> >>  wrote:
>> >> > thats the linker bug.
>> >> >
>> >> > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on
>> >> > #haskell-game
>> >> > in recent memory. GHCI + foreign libs should work fine now (modulo
>> >> > thread
>> >> > local storage related thing).
>> >> >
>> >> > the historical element doesn't matter any more.
>> >> >
>> >> > To the best of my knowledge, all such issues should be gone. Anyone
>> who
>> >> > cares about making sure GHCI+ gui libs play nice, PLEASE test with
>> HEAD.
>> >> >
>> >> > the better this issue is properly tested (which i believe it has
>> been),
>> >> > the
>> >> > more we can actually prevent it from happening. This requires people
>> to
>> >> > test
>> >> > with HEAD GHCi now, rather than doing archaeology.
>> >> >
>> >> > anyone who cares, please play with GHCI in HEAD. If your lib doesn't
>> >> > work
>> >> > with ghci, please report a bug. It would be a new bug because it
>> wont'
>> >> > be
>> >> > the previous reasons it hasnt' worked.
>> >> >
>> >> >
>> >> > tl;dr to the best of my knowledge this issue is resolved in HEAD.
>> Test
>> >> > HEAD.
>> >> > Help us make sure it stays resolved by testing HEAD.
>> >> >
>> >> > thanks
>> >> > -Carter
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu  wrote:
>> >> >>
>> >> >> I reported a problem with statically linked GLFW library on Mac OS X
>> >> >> Lion in this thread:
>> >> >>
>> >> >>
>> http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html
>> >> >>
>> >> >> I do not know why this is broken on Mac OS X Lion, but not on Linux
>> or
>> >> >> Windows. There was an EnableGUI hack for GHC 7.2 (and previous
>> >> >> versions) and OS X version before Lion, but it no longer works. So
>> I'm
>> >> >> not sure if it is OS X Lion, or GLFW, or GHC, or a combination of
>> them
>> >> >> that caused this problem.
>> >> >>
>> >> >> Regards,
>> >> >> Paul Liu
>> >> >>
>> >> >> On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald
>> >> >>  wrote:
>> >> >> > Hey simon, the two issues that have recurrently bit ghci
>> interaction
>> >> >> > with
>> >> >> > foreign GUI libs are
>> >> >> > 1) the ghci linker.  This is fixed in head by now having ghci use
>> the
>> >> >> > system
>> >> >> > linker
>> >> >> > 2) some GUI libs require thread local state, and ghci has a flag
>> for
>> >> >> > that
>> >> >> > 3)  I'm not aware of anyone reporting newly broken libs wrt GUI
>> >> >> > bindings
>> >> >> > when 7.6 rolled out.  The only fix that's relevant to 7.8 is the
>> >> >> > dylinker
>> >> >> > bit, but that would have been a problem historically too.
>> >

Re: [Haskell-cafe] Store type-class polymorphic values generically

[Alp Mestanogullari]

Hi Chris,

Maybe this package (from Edward Kmett, surprisingly) could help:
http://hackage.haskell.org/package/constraints-0.3.3/docs/Data-Constraint.html?
Considering it kind of reifies the type class constraints, I'm wondering
whether you could use this to carry the constraints along the value you're
storing? I haven't given it a lot of thoughts for now, but maybe you can
get something decent working with this?


On Fri, Oct 4, 2013 at 12:41 PM, Heinrich Apfelmus <
apfel...@quantentunnel.de> wrote:

> Christopher Done wrote:
>
>> On 4 October 2013 10:56, Heinrich Apfelmus 
>> wrote:
>>
>>> In particular, the  Locker  stores arbitrary values like  Dynamic ,
>>> except
>>> that values are extracted and removed with the help of a  Key . This gets
>>> rid of the  Typeable  constraint.
>>>
>>
>> lock :: Key a -> a -> Locker
>>
>> I can't pass anything with class constraints to that.
>>
>
> I don't know what "something with a class constraint" means. But I guess
> you want to pass a value with a *polymorphic* type? This is no problem, but
> requires impredicative polymorphism:
>
> a = (forall b. Show b => b -> IO ())
>
> lock :: Key (forall b. Show b => b -> IO ())
>  -> (forall b. Show b => b -> IO ())
>  -> Locker
>
> Unfortunately, GHC's support for that is a little shaky, but a solution
> that always works is to put it in a new data type.
>
> data Dummy = Dummy { unDummy :: forall b. Show b => b -> IO () }
>
> lock :: Key Dummy -> Dummy -> Locker
>
>
> It seems to me that your problem decomposes into two problems:
>
> 1. A heterogenous store for values of different types.
> 2. Values with polymorphic instead of monomorphic types.
>
> Solution for problem 1 are usually restricted to monomorphic types, but
> you can work around it.
>
>
>
> Best regards,
> Heinrich Apfelmus
>
> --
> http://apfelmus.nfshost.com
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>



-- 
Alp Mestanogullari
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: E-book version of the Typeclassopedia

[Dag Odenhall]

That's great — thank you!


On Fri, Oct 4, 2013 at 3:13 PM, Erlend Hamberg  wrote:

> While re-reading Brent Yorgey's Excellent Typeclassopedia I converted it
> to Pandoc Markdown in order to be able to create an EPUB version. Having
> a “real” e-book meant that I could comfortably read it on my e-book
> reader and highlight text and take notes while reading. I also fixed
> some minor issues while reading it. (These fixes were of course
> backported to the official Typeclassopedia version on the Haskell Wiki.)
>
> The EPUB file can be downloaded from Github:
>
> https://github.com/ehamberg/typeclassopedia-md/releases
>
> The Markdown source is also available in that repo and you can of course
> use Pandoc to convert the Markdown file to all the other output formats
> Pandoc supports.
>
> By using a program like Calibre, the EPUB file can be converted to other
> e-book formats such as the Kindle format.
>
> I hope people find this useful. :-)
>
> --
> Erlend Hamberg
> ehamb...@gmail.com
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: E-book version of the Typeclassopedia

[Erlend Hamberg]

While re-reading Brent Yorgey's Excellent Typeclassopedia I converted it
to Pandoc Markdown in order to be able to create an EPUB version. Having
a “real” e-book meant that I could comfortably read it on my e-book
reader and highlight text and take notes while reading. I also fixed
some minor issues while reading it. (These fixes were of course
backported to the official Typeclassopedia version on the Haskell Wiki.)

The EPUB file can be downloaded from Github:

https://github.com/ehamberg/typeclassopedia-md/releases

The Markdown source is also available in that repo and you can of course
use Pandoc to convert the Markdown file to all the other output formats
Pandoc supports.

By using a program like Calibre, the EPUB file can be converted to other
e-book formats such as the Kindle format.

I hope people find this useful. :-)

-- 
Erlend Hamberg
ehamb...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Any precedent or plan for guaranteed-safe Eq and Ord instances?

[Heinrich Apfelmus]

Tom Ellis wrote:

On Wed, Oct 02, 2013 at 11:24:39AM +0200, Heinrich Apfelmus wrote:

I'm not sure whether the  Eq  instance you mention is actually
incorrect. I had always understood that  Eq  denotes an equivalence
relation, not necessarily equality on the constructor level.


There's a difference between implementors being able to distingush equals,
and application programmers.  Internal implementations are allowed to break
all sorts of invariants, but, by definition, APIs shouldn't.

Are there examples where application programmers would like there so be some
f, a and b such that a == b but f a /= f b (efficiency concerns aside)?  I
can't think of any obvious ones.


I think the trouble here is that the instance

data Foo = Bar | Baz
instance Eq Foo where _ == _ = True

is perfectly fine if the possibility to distinguish between  Foo  and 
Bar  is not exported, i.e. if this is precisely an implementation detail.


The LVish library sits between chairs. If you consider all Eq instances 
Safe in the sense of SafeHaskell, then LVish must be marked Unsafe -- it 
can return different results in a non-deterministic fashion. However, if 
only Eq instance that adhere to the "exported functions preserve 
equivalence" law are allowed, then LVish can be marked Safe or 
Trustworthy, but that assurance is precisely one we lack.



I think the generic form of the problem is this:

   module LVish where
   -- | 'foo' expects the invariant that the
   -- first argument must be 'True'.
   foo :: Bool -> String
   foo False = unsafeLaunchMissiles
   foo True  = "safe"

   module B where
   goo = foo False

What status should SafeHaskell assign to the modules LVish and B, 
respectively?


It looks like the right assignment is:

   LVish - Unsafe
   B - Trustworthy

If LVish cannot guarantee referential transparency without assumptions 
on external input, then it stands on a similar footing as  unsafePerformIO .



Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Store type-class polymorphic values generically

[Simon Peyton-Jones]

| However, I want to write this as a core-to-core
| translation as a ghc-plugin. I want the definition go = putStrLn "Hello
| World!" to be translated to what I wrote above. Core cannot generate new
| names to be exported from a module, so go_ is now gone.

Wait... what do you mean "Core cannot generate new names to be exported".  I 
think a core-to-core plugin can certainly generate new top-level function 
definitions.  

Maybe you mean that you want your plugin to transform

module M( f ) where
  f = e
into
module M( f_ ) where
  f_ = ...f...
  f = e

That seems pretty drastic, because now the programmer's API for the module has 
changed.  Are you sure you don't want to do this

module M( f ) wehre
  f_ = e
  f = ...f_...

by renaming the existing f with some local name.

I don't like all this unsafe hackery!

Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Store type-class polymorphic values generically

[Heinrich Apfelmus]

Christopher Done wrote:

On 4 October 2013 10:56, Heinrich Apfelmus  wrote:

In particular, the  Locker  stores arbitrary values like  Dynamic , except
that values are extracted and removed with the help of a  Key . This gets
rid of the  Typeable  constraint.


lock :: Key a -> a -> Locker

I can't pass anything with class constraints to that.


I don't know what "something with a class constraint" means. But I guess 
you want to pass a value with a *polymorphic* type? This is no problem, 
but requires impredicative polymorphism:


a = (forall b. Show b => b -> IO ())

lock :: Key (forall b. Show b => b -> IO ())
 -> (forall b. Show b => b -> IO ())
 -> Locker

Unfortunately, GHC's support for that is a little shaky, but a solution 
that always works is to put it in a new data type.


data Dummy = Dummy { unDummy :: forall b. Show b => b -> IO () }

lock :: Key Dummy -> Dummy -> Locker


It seems to me that your problem decomposes into two problems:

1. A heterogenous store for values of different types.
2. Values with polymorphic instead of monomorphic types.

Solution for problem 1 are usually restricted to monomorphic types, but 
you can work around it.



Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Store type-class polymorphic values generically

[Christopher Done]

On 4 October 2013 10:56, Heinrich Apfelmus  wrote:
> In particular, the  Locker  stores arbitrary values like  Dynamic , except
> that values are extracted and removed with the help of a  Key . This gets
> rid of the  Typeable  constraint.

lock :: Key a -> a -> Locker

I can't pass anything with class constraints to that.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Store type-class polymorphic values generically

[Heinrich Apfelmus]

Christopher Done wrote:

It's very easy to state this problem without enough details and mislead
people into providing a solution for a different problem, so I'll try to
include all the information and use-case. I need a function that can
store a value in a concrete opaque type. I know the type of the value
when I store it, and I know the type of the value when I extract it,
insofar as I know the type inclusive of a class constraint context. But
the container must store many different things at once. Given that I
know the type of the thing when I store it and when I extract it, there
ought to be a “safe’ way to do this, in the same way that Data.Dynamic
is “safe”.

[..]


I have to ashamedly admit that I didn't read your problem description in 
its entirety, but maybe my  vault  package can help?


   

In particular, the  Locker  stores arbitrary values like  Dynamic , 
except that values are extracted and removed with the help of a  Key . 
This gets rid of the  Typeable  constraint.



Note that there is a fundamental problem with storing polymorphic types, 
which is related to the "value restriction for reference types". One of 
the main points of the Typable class is actually that it enforces 
monomorphic types. Similarly, the  vault  library enforces monomorphic 
types by having  newKey  in the IO monad.




Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe