Re: [Haskell-cafe] Poll: Do you want a mascot?

[Wolfgang Jeltsch]

No.

Am Mittwoch, den 23.11.2011, 13:11 -0600 schrieb heathmatlock:
> Question: Do you want a mascot? 
> 
> 
> Answers:
> Yes
> No
> 
> 
> 
> 
> --
> This is an attempt to figure out if this idea is going anywhere.
> ___
> 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] A Mascot

[Wolfgang Jeltsch]

Am Mittwoch, den 16.11.2011, 10:46 +0100 schrieb Bas van Dijk:
> Is ⊥ the right symbol to express the non-strict evaluation of the
> language? Is it true that non-strict evaluation requires that ⊥
> inhabits every type?

In typical strict languages, ⊥ also inhabits every type. The difference
is that the domains of all types except function types are flat. That
is, they don’t contain any partially defined values like ⊥ : ⊥, but
only ⊥ and completely defined values.

Where a Haskell expression would result in a partially defined value,
the same expression in a corresponding strict language would result
in ⊥. So strict languages are “more ⊥” than Haskell. Thus I cannot see
why ⊥ should be used as a symbol for non-strictness at all.

Best wishes,
Wolfgang


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

[Haskell-cafe] package cache being out of date

[Wolfgang Jeltsch]

Hi,

I have a freshly installed Haskell Platform 2010.2.0.0 on Windows 7.
When I run ghc-pkg list, I get the following message (besides the
expected package info):

WARNING: cache is out of date: C:/Program Files (x86)/Haskell
Platform/2010.2.0.0\lib\package.conf.d\package.cache
 use 'ghc-pkg recache' to fix.

What does this mean? Is this harmful?

(In principal, I could just run ghc-pkg recache, but the installation is
replicated on about 20 machines, and I don’t have admin rights on
these.)

Best wishes,
Wolfgang


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

Re: [Haskell-cafe] H98, OOHaskell - getting started with objects in Haskell

[Wolfgang Jeltsch]

Am Sonntag, den 16.01.2011, 14:48 -0800 schrieb gutti:
> Looking at life u probably could save time, if u only would evaluate 
> code on cells, where the neighbors have changed status. So rather than
> triggering them all centrally and each checks its neighbours, we could
> use the concept: 
> 
> - let the active ones trigger the neighbours & so pass on activity 

But then you would have to take care to avoid cycles. You could also use
on-demand updates with a centralized approach, and a centralized
approach would probably make cycle detection easier.

Best wishes,
Wolfgang


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

Re: [Haskell-cafe] H98, OOHaskell - getting started with objects in Haskell

[Wolfgang Jeltsch]

Am Donnerstag, den 13.01.2011, 15:23 -0800 schrieb gutti:
> I'm especially interestes in engineering calculation tasks where cellular
> automata could be used. In that case all u have to do is to give the class
> the right properties and that "let it grow". 
> 
> Such a localised intelligence approach seems an ideal OO - task. I don't
> know whether something functional could achieve the same. 

Is this really ideal for OO? I thought that in a cellular automaton, all
cells have to change synchronously. In addition, cells have to access
the old states of their neighbours to compute their new states. So you
would have to heavily synchronize the objects.

In this light, I’d say that the distributed OO approach isn’t very
practical. A global control of the whole system might be better.

Note that I’m by no way an expert in cellular automata. I’m just
thinking of the game of life. :-) 

Best wishes,
Wolfgang


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

Re: [Haskell-cafe] Improving HList programming/debugging (longish)

[Wolfgang Jeltsch]

Am Dienstag, den 11.01.2011, 20:05 -0500 schrieb jeff p:
> This message shows how to slightly reformulate HLists (and other
> type-level things) to get better type-checking and more informative
> error messages. The technique is interesting in that it uses GADTs and
> functional dependencies and seems to not be implementable with
> associated type synonyms. It also makes higher-order HList
> programming/debugging much more tractable.

Hi,

a few years ago, I also experienced with using GADTs for representing
heterogenous lists. However, I dropped this idea, since GADTs force you
to provide type signatures in certain situations. For example, you
cannot leave out the type signatures in the following definitions:

> hHead :: HList (x :* xs) -> x
> hHead (x :* _) = x
> 
> hTail :: HList (x :* xs) -> HList xs
> hTail (_ :* xs) = xs

This was at odds with a feature I wanted: It should be possible to match
a polymorphic value representing a family of heterogenous lists against
a pattern such that the type of the pattern specifies the concrete list
to use.

I finally switched back to the traditional approach used in today’s
HList. You can read about the pattern-matching thing in Subsection 5.4
of my paper “Generic Record Combinators with Static Type Checking” [1].

Best wishes,
Wolfgang

[1] 


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

Re: [Haskell-cafe] record update

[Wolfgang Jeltsch]

Am Dienstag, den 14.09.2010, 13:31 -0600 schrieb Jonathan Geddes:
> Wow, I had no idea there were so many record packages!

The trouble is that only one of them (i.e., mine) is categorized under
“Records” on Hackage.

Best wishes,
Wolfgang

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

Re: [Haskell-cafe] Re: Coding conventions for Haskell?

[Wolfgang Jeltsch]

Am Sonntag, den 26.09.2010, 17:25 +0100 schrieb Maciej Piechotka: 
> I use it in following way;
> 
> 1. For short sharing name (rarely)
> 
> let a = b ++ c in (a, a) 
> 
> 2. Default
> 
> let a :: [Int]
> a = b ++ c
> f :: Int -> String
> f 0 = ""
> f x = show x
> in map f a

I like to separate declaration by empty lines:

let

a :: [Int]
a = b ++ c

f :: Int -> String
f 0 = ""
f x = show x

in map f a

I think this is much more readable, since you can easily see which of
those lines belong together.

Best wishes,
Wolfgang

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

Re: [Haskell-cafe] record update

[Wolfgang Jeltsch]

Am Samstag, den 11.09.2010, 11:21 -0600 schrieb Jonathan Geddes:
> I know that record updates is a topic that has become a bit of a dead
> horse, but here I go anyway:
> 
> I find that most of the record updates I read and write take the form
> 
> >someUpdate :: MyRecord -> MyRecord
> >someUpdate myRecord = myRecord
> > { field1 = f $ field1 myRecord
> > , field2 = g $ field2 myRecord
> > , field3 = h $ filed3 myRecord
> > }
> 
> I find myself wishing I could write something more like
> 
> >someUpdate :: MyRecord -> MyRecord
> >someUpdate myRecord = myRecord
> > { field1 => f
> > , field2 => g
> > , field3 => h
> > }
> 
> with equivalent semantics. Here => reads "is transformed by". Operator
> = could still be used for assignment as in current record updates.
> 
> The best part about such an extension, in my opinion, is that it would
> open the door for anonymous lambda record updates. Something like:
> 
> >someUpdate :: MyRecord -> MyRecord
> >someUpdate = \{field1 => f, field2 => g, field3 => h}
> 
> again, with the same semantics. This becomes possible because you no
> longer need to refer to the record within the {} part of the update.
> 
> This would be useful, for example, in the State monad. We could write:
> 
> >someStateTransform :: State MyRecord ()
> >someStateTransform = do
> > modify $ \{field1 => (++"!")}
> > ...
> 
> where currently we see code like
> 
> >someStateTransform :: State MyRecord ()
> >someStateTransform = do
> > modify $ \record->record{field1 = (++"!") $ field1 record}
> > ...
> 
> which repeats the record name 3 times and the field name twice. The
> repetition just feels out of place next to all the other terse,
> readable Haskell code in the program.
> 
> So what do my fellow haskellers think? Is this idea worth writing up a
> proposal for?
> 
> Alternatively, can you offer me some advice on writing code in Haskell
> 2010 that avoids the ugly, repetitive style of record update?
> 
> --Jonathan

You might want to have a look at the records package:



Here is a code example:

> import Data.Kind
> import Data.TypeFun
> import Data.Record
> import Data.Record.Combinators
>
> data Surname = Surname deriving (Show)
> data Age = Age deriving (Show)
> data Room= Roomderiving (Show)
>
> instance Name Surname where name = Surname
> instance Name Age where name = Age
> instance Name Roomwhere name = Room
>
> oldData = X :& Surname := "Jeltsch"
> :& Age := 31
> :& Room:= "EH/202"
> `withStyle` Id KindStar
>
> newData = modify (X :& Age := (+2) :& Room := const "HG/2.39") oldData

Evaluating newData gives you:

> X :& Surname := "Jeltsch" :& Age := 33 :& Room := "HG/2.39"

If you have any question regarding the records package, please ask,
since I’m its author. :-) 

Best wishes,
Wolfgang

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

Re: [Haskell-cafe] Haskell, arrows and signal processing

[Wolfgang Jeltsch]

Am Mittwoch, den 08.09.2010, 11:47 -0300 schrieb Rafael Gustavo da Cunha
Pereira Pinto:
> The input and output are  infinite streams. I have a few questions:
> 
> 1) Is it possible to change it to use arrows? How would it look like?
> 2) How would one implement an continuous time version?

Have you had a look at Yampa?

Best wishes,
Wolfgang


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

Re: Re[2]: [Haskell-cafe] overloaded list literals?

[Wolfgang Jeltsch]

Am Montag, den 06.09.2010, 19:38 +0400 schrieb Bulat Ziganshin:
> btw, i also had proposal to automatically convert typeclasses used in
> type declarations into constraints, so that:
> 
> putStr :: StringLike -> IO ()
>
> treated as
>
> putStr :: StringLike s => s -> IO ()

This blurs the distinction between classes and types, which are two
fundamentally different concepts in Haskell. In addition, it works only
for special cases. I would like the language to be simple. Alas, more
and more sugar is added to Haskell, which makes it unnecessarily
complicated.

Best wishes,
Wolfgang


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

Re: [Haskell-cafe] overloaded list literals?

[Wolfgang Jeltsch]

Am Montag, den 06.09.2010, 11:47 +0100 schrieb Neil Brown:
> I would have thought you have two obvious choices for the type-class 
> (things like folding are irrelevant to overloading list literals):
> 
> class IsList f where
>fromList :: [a] -> f a
> 
> or:
> 
> class IsList f where
>cons :: a -> f a -> f a
>empty :: f a

We should definitely get rid of these Is* class identifiers like
IsString and IsList. We also don’t have IsNum, IsMonad, etc.

Best wishes,
Wolfgang

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

Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions

[Wolfgang Jeltsch]

Am Donnerstag, 11. März 2010 00:37:18 schrieb wren ng thornton:
> Wolfgang Jeltsch wrote:
> > Hello,
> >
> > some time ago, it was pointed out that generalized newtype deriving could
> > be used to circumvent module borders. Now, I found out that generalized
> > newtype deriving can even be used to define functions that would be
> > impossible to define otherwise. To me, this is surprising since I thought
> > that generalized newtype deriving was only intended to save the
> > programmer from writing boilerplate code, not to extend expressiveness.
> 
> Let's dig down and figure out the problem. When you annotate the type
> "Wrapped a" with "deriving (Iso a)" what are you saying? You're saying
> that the compiler should derive an instance (Iso a (Wrapped a)). Well,
> that instance gives you the method instance conv :: forall f. f a -> f
> (Wrapped a). The funny thing is that the only implementation for
> ---something like--- that type would be fmap Wrap.

If the parameter of f is contravariant then we would need a “contraMap”, not 
an fmap. Example:

> newtype CoFun a b = CoFun (b -> a)
>
> class ContraFunctor f where
>
> contraMap :: (a -> b) -> f b -> f a
>
> instance ContraFunctor (CoFun a) where
>
> contraMap f (CoFun g) = CoFun (g . f)
>
> coFun :: CoFun Int Char
> coFun = CoFun ord
>
> directlyConverted :: CoFun Int (Wrapped Char)
> directlyConverted = conv coFun
>
> manuallyConverted :: CoFun Int (Wrapped Char)
> manuallyConverted = contraMap unwrap coFun

Here, unwrap is the inverse of Wrap.

Let us look at the Set example from John Meacham. Set is a (covariant) 
functor, not a contravariant functor. However, it isn’t a functor from and to 
the category of Haskell types and functions but the category of types of class 
Ord and Ord homomorphisms (functions that respect ordering). The problem in 
John Meacham’s Set example is that Down doesn’t preserve ordering. If conv is 
used with a newtype wrapper constructor that does preserve ordering, this is 
the same as applying Set.map or Set.mapMonotonic.

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

Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions

[Wolfgang Jeltsch]

Am Dienstag, 9. März 2010 11:53:14 schrieben Sie:
> Isn't this just an extension of the notion that multi-parameter typeclasses
> without functional dependencies or type families are dangerous and allow
> for type-naughtiness?

Multi-parameter typeclasses are dangerous? It’s the first time I hear that. 
Could you elaborate, please?

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

Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions

[Wolfgang Jeltsch]

Am Dienstag, 9. März 2010 15:54:16 schrieb Jan-Willem Maessen:
> On Mar 9, 2010, at 5:53 AM, Max Cantor wrote:
> > Isn't this just an extension of the notion that multi-parameter
> > typeclasses without functional dependencies or type families are
> > dangerous and allow for type-naughtiness?
> 
> I wondered the same thing, but came up with an analogous problematic case
> that *only* uses generalized newtype deriving:
>
> […]

Originally, I had a more restricted example in mind which is similar to yours. 
However, I wanted to generalize the problem and therefore introduced the 
general Iso class which made MultiParamTypeClasses and FlexibleInstances 
necessary. The actual problem is related neither to MultiParamTypeClasses nor 
to FlexibleInstances.

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

Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions

[Wolfgang Jeltsch]

Am Dienstag, 9. März 2010 07:24:35 schrieb Steffen Schuldenzucker:
> On 03/08/2010 10:45 PM, Wolfgang Jeltsch wrote:
> > The point is, of course, that such conversions are not only possible for
> > binary operations but for arbitrary values and that these conversions are
> > done by a single generic function conv. I don’t think it would be
> > possible to implement conv without generalized newtype deriving.
> >
> > Any thoughts?
> 
> Hi Wolfgang,
> 
> it's not exactly the same, but...
> 
> > import Control.Applicative
> >
> > newtype Wrapped a = Wrap a deriving Show
> >
> > instance Functor Wrapped where
> > fmap f (Wrap x) = Wrap $ f x
> >
> > instance Applicative Wrapped where
> > pure = Wrap
> > (Wrap f) <*> (Wrap x) = Wrap $ f x
> >
> > convBinOp :: (a -> a -> a) -> (Wrapped a -> Wrapped a -> Wrapped a)
> > convBinOp op x y = pure op <*> x <*> y

I think this is fundamentally different. As I said above:

> The point is, of course, that such conversions are not only possible for
> binary operations but for arbitrary values and that these conversions are
> done by a single generic function conv.

Your applicative functor Wrapped allows conversions only for n-ary functions, 
so, for example, John Meachem’s trick to break the invariant of Set doesn’t 
work. On the other hand, you need a separate conversion function for each 
arity (pure, fmap, liftA2, liftA3, …) whereas generalized newtype deriving 
allows you to use the same conversion function for all arities.

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

Re: [Haskell-cafe] Haskell course, training

[Wolfgang Jeltsch]

Am Montag, 8. März 2010 23:17:56 schrieb Henning Thielemann:
> On Sun, 7 Mar 2010, G?nther Schmidt wrote:
> > I think I've reached the point where I need some tutoring, so provided
> > I've got money for travel and course fees, and time, where do I get it?
> > I'm not a student so some courses aren't available to me.
> 
> How about visiting our Haskell meeting in Leipzig, June 4th?

By the way, has this been announced already?

Is the program already fixed or are applications for a talk or a tutorial still 
welcome? To be more precise, would the organizers be interested in something 
about dependent types? I might be able to offer something in this direction.

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

Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions

[Wolfgang Jeltsch]

Am Montag, 8. März 2010 22:45:19 schrieb Wolfgang Jeltsch:
> Hello,
> 
> some time ago, it was pointed out that generalized newtype deriving could
> be used to circumvent module borders. Now, I found out that generalized
> newtype deriving can even be used to define functions that would be
> impossible to define otherwise. To me, this is surprising since I thought
> that generalized newtype deriving was only intended to save the programmer
> from writing boilerplate code, not to extend expressiveness.
> 
> Have a look at the following code:
> > {-# LANGUAGE
> > GeneralizedNewtypeDeriving,
> > MultiParamTypeClasses,
> > FlexibleInstances
> > #-}
> >
> > class Iso a b where
> >
> > conv :: item a -> item b
> >
> > instance Iso a a where
> >
> > conv = id
> >
> > newtype Wrapped a = Wrap a deriving (Iso a, Show)
> 
> Now any value whose type contains some type t can be converted into a value
> of the type that you get if you replace t by Wrap t. Here is some code to
> demonstrate this for binary operations:
>
> > newtype BinOp a = BinOp (a -> a -> a)
> >
> > convBinOp :: (a -> a -> a) -> (Wrapped a -> Wrapped a -> Wrapped a)
> > convBinOp op = let BinOp op' = conv (BinOp op) in op'
> 
> Now, you can enter
> 
> convBinOp (*) (Wrap 5) (Wrap 3)
> 
> into GHCi, and you will get
> 
> Wrap 15
> 
> as the result.
> 
> The point is, of course, that such conversions are not only possible for
> binary operations but for arbitrary values and that these conversions are
> done by a single generic function conv. I don’t think it would be possible
> to implement conv without generalized newtype deriving.

Generalized newtype deriving doesn’t just allow otherwise undefinable functions 
to be defined. It probably also allows for faster function implementations. For 
example, with the above conv method, you could probably convert a list of some 
type [t] into a list of type [Wrapped t] in O(1) time. If you would code this 
conversion by hand, it would take O(n) time, of course.

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

[Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions

[Wolfgang Jeltsch]

Hello,

some time ago, it was pointed out that generalized newtype deriving could be 
used to circumvent module borders. Now, I found out that generalized newtype 
deriving can even be used to define functions that would be impossible to 
define 
otherwise. To me, this is surprising since I thought that generalized newtype 
deriving was only intended to save the programmer from writing boilerplate 
code, not to extend expressiveness.

Have a look at the following code:

> {-# LANGUAGE
> GeneralizedNewtypeDeriving,
> MultiParamTypeClasses,
> FlexibleInstances
> #-}
> 
> class Iso a b where
> 
> conv :: item a -> item b
> 
> instance Iso a a where
> 
> conv = id
> 
> newtype Wrapped a = Wrap a deriving (Iso a, Show)

Now any value whose type contains some type t can be converted into a value of 
the type that you get if you replace t by Wrap t. Here is some code to 
demonstrate this for binary operations:

> newtype BinOp a = BinOp (a -> a -> a)
> 
> convBinOp :: (a -> a -> a) -> (Wrapped a -> Wrapped a -> Wrapped a)
> convBinOp op = let BinOp op' = conv (BinOp op) in op'

Now, you can enter

convBinOp (*) (Wrap 5) (Wrap 3)

into GHCi, and you will get

Wrap 15

as the result.

The point is, of course, that such conversions are not only possible for 
binary operations but for arbitrary values and that these conversions are done 
by a single generic function conv. I don’t think it would be possible to 
implement conv without generalized newtype deriving.

Any thoughts?

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

Re: [Haskell-cafe] Re: GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)

[Wolfgang Jeltsch]

Am Samstag, 6. März 2010 03:45:02 schrieb Maciej Piechotka:
> PS. There is also GPL-with-linking-exception which allows linking etc.
> but does not require relinking capability. I'd believe that in such case
> the cross-module inlining is not a problem since it is 'linking' for
> compiler.

The term “linking” is quite well-defined in computer science. You seem to 
redefine it and assume that copyright holders will accept your redefinition.

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

Re: [Haskell-cafe] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)

[Wolfgang Jeltsch]

Am Donnerstag, 4. März 2010 18:57:03 schrieb MightyByte:
> Interesting.  It seems to me that the only solution for the
> BSD-oriented haskell community is to practically boycott GPL'd
> libraries.  From what I understand, this is exactly what the LGPL is
> for.  I've known the basic idea behind the GPL/LGPL distinction for
> quite awhile, but I didn't realize that mistaking the two had such
> far-ranging consequences.  Since GPL seems to be the big elephant in
> the room, it seems very easy to make this mistake.  At the very least
> we should try to educate the community about this.

To my knowledge, the LGPL only allows *linking* with non-(L)GPL software. But 
GHC doesn’t just link but performs massive cross-module inlining. So in my 
opinion, LGPL is not a solution, too. Use BSD3!

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

Re: [Haskell-cafe] grapefruit on windows or osX

[Wolfgang Jeltsch]

Am Sonntag, 21. Februar 2010 21:57:45 schrieb gladst...@gladstein.com:
> I'm unable to get grapefruit going on osx or windows because (I think) I
> can't get the underlying GTK installed.

Hi,

thank you for giving Grapefruit a try.

Yes, you are most likely right that Gtk2Hs is the stumbling block. Grapefruit 
itself doesn’t do anything OS-specific, and since it works on Linux, it should 
also work on OS X.

I strongly suggest that you try out the current development version of 
Grapefruit instead of the version on Hackage, since the latter is lacking a 
bunch of features.

If you have any Grapefruit-related questions, please ask here or on the 
Grapefruit mailing list.

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

Re: [Haskell-cafe] Examples

[Wolfgang Jeltsch]

Am Samstag, 8. August 2009 13:29 schrieb Andrew Coppin:
> As some of you may remember, I recently released a couple of packages on
> Hackage. I'd like to also release some example programs using these
> packages, but I'm not sure of the best way to do this.
>
> Do I make the example programs part of the package itself? Do I release
> a seperate package which just contains the example code? Something else
> entirely? What's the recommendation here?

I had to make this decision for Grapefruit, and I decided to put the examples 
into a separate package named grapefruit-examples. Note that the rest of 
Grapefruit was already split into several packages with names of the form 
grapefruit-*.

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

Re: [Haskell-cafe] Hackage and version control

[Wolfgang Jeltsch]

Am Montag, 20. Juli 2009 05:25 schrieb Robin Green:
> community.haskell.org requires you to wait for a volunteer to review
> every new project request.

However, response times are usually low.

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

Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

[Wolfgang Jeltsch]

Am Sonntag, 19. Juli 2009 23:42 schrieben Sie:
> On Jul 18, 2009, at 9:26 PM, Wolfgang Jeltsch wrote:
> > I don’t think, it’s a good idea to have German identifiers, since
> > Haskell’s keywords are English.
>
> Put it this way:  if Haskell's keywords were in German, do you suppose I
> would write my Haskell code in anything but English?

At least, many people all over the world write their code in something other 
than their native language. :-) 

> Does the fact that 'data' is a Latin word mean that some fraction of our
> Haskell identifiers should be in Latin?

data is also an English word nowadays.

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

Re: [Haskell-cafe] is closing a class this easy?

[Wolfgang Jeltsch]

Am Samstag, 18. Juli 2009 08:58 schrieb Miguel Mitrofanov:
> Oops... Sorry, wrong line. Should be
>
> isAB :: forall p. p A -> p B -> p x

Is this a well-known approach for closing classes?

I came across the same idea and implemented a generic framework for closing 
classes in this way. I did this to simulate algebraic data kinds and kind 
polymorphism over such kinds. I needed this for the record system of 
Grapefruit. The code is here:



Explaination of the techniques used in this code will probably follow as part 
of an IFL 2009 paper.

Now I wonder which of my ideas are actually new and which are just old hat. 
Could you maybe answer this question?

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

Re: newtype deriving, was Re: [Haskell-cafe] is closing a class this easy?

[Wolfgang Jeltsch]

Am Samstag, 18. Juli 2009 11:43 schrieb Conor McBride:
> The trouble here is that somewhere along the line (GADTs? earlier?)
> it became possible to construct candidates for p :: * -> * which don't
> respect isomorphism.

Hello Conor,

I’m not sure whether I exactly understand what you mean here. I think, it’s 
the following:

Say, you have a type A and define a type B as follows:

newtype B = B A

Then, for any p :: * -> *, the type p A should be isomorphic to p B, i.e., it 
should basically contain the same values. This is no longer true with GADTs 
since you can define something like this:

data GADT a where

GADT :: GADT A

Now, GADT :: GADT A but not GADT :: GADT B.

Is this what you mean?

> These tend to be somewhat intensional in nature, and they mess up the
> transfer of functionality.

Could you maybe elaborate on this?

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

Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

[Wolfgang Jeltsch]

Am Samstag, 18. Juli 2009 06:31 schrieben Sie:
> On Jul 18, 2009, at 2:35 AM, Wolfgang Jeltsch wrote:
> > So I should upload a package with German identifiers to Hackage?
>
> Sure, why not?  The fact that I can't read it is my loss, not your fault,
> and there will be plenty of other German-reading Haskellers to benefit from
> it.  I've happily worked with programs in French (not large ones (:-)).

I don’t think, it’s a good idea to have German identifiers, since Haskell’s 
keywords are English. On the other hand, I strongly argue that a library 
about Bézier curves uses the identifier Bézier, not Bezier. So non-ASCII 
identifiers are useful even if identifiers are in English.

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

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release

[Wolfgang Jeltsch]

Hello Jeff,

it’s been some time that we had the conversation below and I have to tell you 
the same thing I told Jamie in a haskell-cafe mail sent a few minutes ago: 
The student who wrote the Qt binding generator never managed to send me a 
final version of his code. At least, I was able to make him send me the 
current state. I don’t think he will improve this code anymore.

If you want to have a look at the code, please visit

<http://haskell.org/haskellwiki/HQK>

and follow the link to the code and have a look at the building tips. In case 
you would like to improve the binding generator, I’d be happy to receive 
patches. :-) 

Sorry for these bad news.

Best wishes,
Wolfgang

Am Mittwoch, 18. Februar 2009 15:42 schrieb Jeff Heard:
> When he gives you the code, could you let me know?  I would really
> love to bind Open Scene Graph, but it's entirely C++ and that makes
> for a lot more difficult coding to say the least.
>
> On Wed, Feb 18, 2009 at 4:17 AM, Wolfgang Jeltsch
>
>  wrote:
> > Am Dienstag, 17. Februar 2009 19:36 schrieben Sie:
> >> > If you have problems with Gtk2Hs on Windows, it might be better to
> >> > write a Win32-based backend for Grapefruit instead of a
> >> > wxWidgets-based one. What do you think about that?
> >>
> >> Win32-based backend would make more sense as it is one less layer to
> >> deal with. But how? Same thing with Mac.
> >
> > A student of mine wrote a fully automatic binding generator for C++
> > libraries which also supports Qt extensions (signals and slots).
> > (However, this guy still has to give me the code. :-/ ) One could do a
> > similar thing for generating Win32 and Cocoa bindings. Then one could
> > write Grapefruit UI backends based on these bindings.
> >
> > Best wishes,
> > Wolfgang
> > ___
> > 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] Re: [Haskell] ANNOUNCE: first Grapefruit release

[Wolfgang Jeltsch]

Am Montag, 16. Februar 2009 15:27 schrieben Sie:
> On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote:
> > [redirecting to haskell-cafe]
> >
> > Am Sonntag, 15. Februar 2009 00:25 schrieben Sie:
> >> Hi Wolfgang,
> >>
> >> I was wondering if I can use FLTK as GUI backend for Grapefruit?
> >
> > This should be possible in principal. It just could be that my
> > assumptions about how widgets are created and composed were too tight so
> > that Grapefruit’s general interface doesn’t fit FLTK. In this case,
> > please just tell me and I will try to make the interface more general.
>
> Ok, great I ll have to use them then I will see and know what improvement
> is needed.
>
> >> I believe for this to make it happen, I would have to output FLTK's C++
> >> into C then create bindings for Haskell (via FFI).  Is that doable or an
> >> quite tall order?
> >
> > Recently, a student of mine has written a program which generates a
> > Haskell Qt binding fully automatically from Qt header files. The
> > generated binding consists of three layers. The first layer is C++ code
> > which reexports Qt’s functionality as a pure C interface. The C interface
> > is ugly for humans and not type safe (because C doesn’t know classes).
> > The second layer consists of a couple of FFI declarations. The third
> > layer is Haskell code which provides a nice interface similar to the
> > original C++ interface.
> >
> > I still have to get the source code of the binding generator from that
> > student but I hope this will happen soon. I want to publish it then on
> > the web. It hope that it is possible to reuse this binding generator for
> > other C++ libraries.
>
> That would be very helpful, I ll be looking forward.

Hello Jamie,

it’s been quite some time that we had this discussion about writing a 
FLTK-based GUI backend for Grapefruit. I’m sorry that I have to tell you that 
the above-mentioned student never managed to send me a final version of this 
Qt binding generator. At least, I was able to make him send me the current 
state of his code. I don’t think he will improve this code anymore.

If you want to have a look at the code, please visit

<http://haskell.org/haskellwiki/HQK>

and follow the link to the code and have a look at the building tips. In case 
you would like to improve the binding generator, I’d be happy to receive 
patches. :-) 

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

Re: [Haskell-cafe] What is the point of the 'What the bleep' names in haskell?

[Wolfgang Jeltsch]

Am Freitag, 17. Juli 2009 21:06 schrieb Daryoush Mehrtash:
> Why do Haskell programmers (and libraries) name their function like "<@<"
> or "###"?Why not use a more descriptive label for functions?

It’s for the same reason that mathematicians say 2 + 3 instead of plus(2,3): 
it’s more readable at times. :-) 

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

Re: [Haskell-cafe] Pattern matching with where free variables can be used more than once

[Wolfgang Jeltsch]

Am Freitag, 17. Juli 2009 20:38 schrieb Stefan Holdermans:
> Christopher,
>
> > Wouldn't it be great if pattern variables could be used more than once
> > in a pattern? Like so:
> >
> >foo [x,x,_,x] =  "The values are the same!"
> >foo _  = "They're not the same!"
>
> These are called nonlinear patterns. I think Miranda (a precursor of
> Haskell, sort of) used to have them.

Yes, Miranda had them.

I see the following problem with them: Patterns are about the structure of 
data. So using the same variable twice in the same pattern should mean that 
the values that match the variable must have the same structure. This would 
break data abstraction. For example, matching a pair of sets against the 
pattern (x,x) would succeed if both sets were represented by the same tree 
internally, but not succeed if both sets were equal but represented 
differently.

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

Re: [Haskell-cafe] What's the status with unicode characters on haddock ?

[Wolfgang Jeltsch]

Am Freitag, 17. Juli 2009 16:43 schrieben Sie:
> On Fri, Jul 17, 2009 at 4:37 PM, Wolfgang
>
> Jeltsch wrote:
> > To my knowledge, Haddock only supports ASCII as input encoding. If you
> > want to have characters outside ASCII, you have to escape them using
> > something like  .
>
> Which would mean, while editing the code I'd have to read comments like
> that :
>
> -- | s lection de l' tat
>
> Which becomes totally unreadable.
>
> :(

Yes, it’s a pity. For me, it’s not such a big problem since I don’t write my 
Haddock comments in my native language (German) but in English. I only 
experience this problem because I use nice typography, i.e., “ ” – instead 
of " " -.

GHC supports UTF-8 input, and Haddock uses GHC nowadays. So, in my opinion, 
Haddock should also support UTF-8 input. Do you want to file a feature 
request?

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

Re: [Haskell-cafe] What's the status with unicode characters on haddock ?

[Wolfgang Jeltsch]

Am Freitag, 10. Juli 2009 09:54 schrieb david48:
> Hello all,
>
> I made a small program for my factory and I wanted to try to document
> it using haddock. The thing is, the comments are in French and the
> resulting html pages are unreadable because the accentuated letters
> are mangled.
>
> It's not acceptable to use HTML entities, as I'd like the comments to
> remain readable when/if I edit the code.
>
> Anyone has had the same problem ? Found a workaround ?
>
> Thanks,
>
> David.

To my knowledge, Haddock only supports ASCII as input encoding. If you want to 
have characters outside ASCII, you have to escape them using something like 
 .

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

Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

[Wolfgang Jeltsch]

Am Mittwoch, 15. Juli 2009 05:27 schrieben Sie:
> On Jul 10, 2009, at 8:44 PM, Wolfgang Jeltsch wrote:
> > Why do we use English for identifiers? Because English is the language of
> > computer science. What English should we use? It’s tempting to say, we
> > should use the original English, which is British English. But we should
> > ask again what is the language of computer science. And the language of
> > computer science is American English. 
>
> It was possible to adopt such an attitude in the 20th century. But this is
> the 21st century.  We have globalisation, internationalisation,
> localisation.  We have Unicode, so that people are no longer limited to the
> set of characters that technicians from the USA found tolerable back in
> 1967.

So I should upload a package with German identifiers to Hackage?

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

Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

[Wolfgang Jeltsch]

Am Dienstag, 7. Juli 2009 14:42 schrieb Robin Green:
> On Fri, 10 Jul 2009 10:44:51 +0200
>
> Wolfgang Jeltsch  wrote:
> > PASCAL
> > uses “program”, not “programme”,
>
> The word program (as in computer program) is spelled program in both
> British and American English.

Probably just because British English took it from American English. It’s 
similar to the “German” word “Computer”. It’s not native.

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

Re: [Haskell-cafe] Alternative IO

[Wolfgang Jeltsch]

Am Samstag, 11. Juli 2009 00:16 schrieben Sie:
> On Friday 10 July 2009 4:35:15 am Wolfgang Jeltsch wrote:
> > I fear that this instance doesn’t satisfy required laws. As far as I
> > know, the following equalities should hold:
> >
> > (*>) = (>>)
> >
> > f *> empty = empty
>
> IO already fails at this law, because (f *> empty) is not the same as
> empty,

Huh? There was no Applicative instance for IO. This was the reason for 
Cristiano to define one, and my mail pointed out a problem in his definition.

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

Re: [Haskell-cafe] Alternative IO

[Wolfgang Jeltsch]

Am Freitag, 10. Juli 2009 23:41 schrieben Sie:
> On Jul 10, 2009, at 4:35 AM, Wolfgang Jeltsch wrote:
> > I fear that this instance doesn’t satisfy required laws. As far as
> > I know, the following equalities should hold:
> >
> > (*>) = (>>)
> >
> > f *> empty = empty
> >
> > empty <|> g = g
> >
> > This implies the following:
> >
> > (f >> empty) <|> g = g
> >
> > But this wouldn’t hold with your instance. (f >> empty) <|> g would
> > cause the side effects of f and of g, while g would (obviously) only cause
> > the side effects of g.
>
> I think the third equality you provide is too strong (which isn't to
> say that it might not be the law that people have documented and
> expect). Lots of useful alternative instances fail it, not least any
> parser combinator library (such as Parsec) without automatic
> backtracking.

Really? The third equality is required since Alternative instances have to be 
monoids with empty as the neutral element and (<|>) as composition.

> […]

> Additionally, the second equality you provide is just wrong.
>
> f *> empty = empty is no more true than f *> g = g,

I don’t understand this. The equation f *> g = g is much more general than
f *> empty = empty. (<|>) usually denotes non-determinism and empty should be 
the neutral element of non-determinism, which is failing. This leads me to
f *> empty = empty.

> […]

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

Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

[Wolfgang Jeltsch]

Am Freitag, 10. Juli 2009 05:26 schrieb rocon...@theorem.ca:
> I find it amazing that you independently chose to spell colour with a `u'.
> It makes me feel better about my choice.

I have to admit that it makes me unhappy. :-( 

Why do we use English for identifiers? Because English is the language of 
computer science. What English should we use? It’s tempting to say, we should 
use the original English, which is British English. But we should ask again 
what is the language of computer science. And the language of computer 
science is American English.

To my knowledge, most early developments in computer science had their roots 
in the US. One consequence of this is that reserved words of programming 
languages are typically in American English. PASCAL uses “program”, 
not “programme”, and BASIC uses “COLOR”, not “COLOUR”. So, in my opinion, 
Haskell color packages should use the identifier Color, not Colour. By the 
way, I also write my papers and documentation in American English.

Best wishes,
Wolfgang
(who is neither British nor American)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Alternative IO

[Wolfgang Jeltsch]

Am Donnerstag, 9. Juli 2009 15:27 schrieb Cristiano Paris:
> As a joke, I wrote an instance of Alternative for IO actions:
> {-# LANGUAGE ScopedTypeVariables #-}
> module Main where
>
> import Control.Applicative
> import Control.Exception
>
> instance Alternative IO where
>   empty = undefined
>   x <|> y = handle (\ (_ :: SomeException) -> y) x
>
> This would allow to write IO code which failsafes to a value if the
> previous computation failed, i.e.:
>
> *Main Control.Applicative> undefined <|> print "Hello"
> "Hello"
> *Main Control.Applicative> print "Hello" <|> undefined
> "Hello"
>
> It seems a neat way to catch exception in some scenarios. What do you
> think? Why is not Alternative IO defined in Control.Applicative?
>
> Thanks,
>
> Cristiano

Hello Cristiano,

I fear that this instance doesn’t satisfy required laws. As far as I know, the 
following equalities should hold:

(*>) = (>>)

f *> empty = empty

empty <|> g = g

This implies the following:

(f >> empty) <|> g = g

But this wouldn’t hold with your instance. (f >> empty) <|> g would cause the 
side effects of f and of g, while g would (obviously) only cause the side 
effects of g.

If empty would be a real empty, it would have to undo the effects of previous 
actions (like f above). So an Applicative instance makes sense for STM but 
not for IO.

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

Re: [Haskell-cafe] Creating a new Haskell mailing list

[Wolfgang Jeltsch]

Am Donnerstag, 18. Juni 2009 16:21 schrieb Henning Thielemann:
> Ryan Trinkle schrieb:
> > Hi all,
> >
> > I'm interested in starting a mailing list on haskell.org
> > .  Who should I talk to about such things?
>
> Is it a mailing list related to a project? Then you may request a
> project on community.haskell.org, then you can start a mailing list at
> yourproj...@project.haskell.org

See .

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

Re: [Haskell-cafe] GUIs, FRP, (Delimited) Continuations and Zippers

[Wolfgang Jeltsch]

Am Samstag, 16. Mai 2009 16:18 schrieb GüŸnther Schmidt:
> Hi all,
>
> In my app, there is one part which has a rather complicated GUI logic,
> it involves n drop downs with n choices each.
>
> Whenever the current selection in one of the drop downs changes by user
> interaction, the other (n-1) drop downs need to be notified and their
> item list need to possible change too.
>
> Now I have managed to code all this and it actually behaves correctly.
> But I'm also using tons of IORefs and tons of bookkeeping code for it.
> While I'd not be ashamed to show any other part of my code to another
> Haskeller, this part of the code is the most clumsiest I've ever written.
>
> And I have no clue if that piece of code *can* be written in any other
> way, ie. without the tons of IORefs and bookkeeping.
>
> The GUI library is WXHaskell.
>
> In the last few days I read up on Conal Elliotts FRP stuff (reactive)
> but also on Olegs ZFS (Zippers, Delimited Continuations), the latter
> leaving me totally baffled.
>
> Could either of those approaches (FRP / Delimited Continuations) be a
> solution for implementing complex GUI code?
>
> Günther

Hello Günther,

FRP can definitely help you a lot for these kinds of problems. You have n 
widgets where each widget outputs a discrete signal (event (stream)) of 
requests from the user. These are transformed and combined to form signals 
(behaviors) that describe the contents of the n widgets over time.

Have you looked at Grapefruit? It’s an FRP library, I’m developing, which 
already has integrated GUI support. If you want to try it out, better take 
the darcs version instead of the released version since there have been some 
important developments since the release date. You find Grapefruit’s homepage 
here: . If you have questions, 
please ask.

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

Re: [Haskell-cafe] Removing mtl from the Haskell Platform

[Wolfgang Jeltsch]

Am Mittwoch, 13. Mai 2009 01:03 schrieb rocon...@theorem.ca:
> I wanted to pass this idea around the cafe to get some thoughts before
> submitting a trac on this topic.
>
> I'd like to see the mtl removed from the Haskell Platform.
>
> The mtl was a tremendous step forward when it was developed.  However, we
> have learned a few things about monad transformers since the development
> of the mtl, and it is time that we moved forward.
>
> There are at least 3 significant problem with the mtl.
>
> 1) `pass' should not be a member functions of the MonadWriter class.  It
> is my understanding that there is no `MonadWriter w m => MonadWriter w
> (ContT s m)' instance because the `pass' function cannot be implemented.
> I'm also highly suspicious of some other methods too (I'm looking at you
> `local').
>
> 2) The `StateT s (Cont r a)' instance of callCC is wrong.  The paper on
> modular monad transformers
>  describes why this is
> wrong.
>
> 3) I am told by many people that the order of the state and value pair in
> `State' is backwards.  Actually, I'm not entirely sure what the issue is
> here, but I trust the people who say this.

4) The identifiers State and StateT are flawed. Something of value State s a 
doesn’t denote a state but a state transformer or however you want to name 
it.

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

Re: [darcs-users] [Haskell-cafe] Darcs as undo/redo system?

[Wolfgang Jeltsch]

Am Mittwoch, 13. Mai 2009 02:55 schrieb Trent W. Buck:
> Wolfgang Jeltsch  writes:
> > Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit:
> >> If you wanted to work on this, I would encourage you to read more
> >> about patch theory[1,2,3,4] and also try out libdarcs[5].
> >
> > Is libdarcs the same as the darcs library package on Hackage (which
> > exports the darcs API)?
>
> The Darcs package (both on Hackage and elsewhere) builds two things: the
> darcs(1) binary, and libHSdarcs.  The latter is what Jason was referring
> to.  Note that currently it just exposes all our internal functions,
> rather than providing a coherent (or stable!) API.

I know. My students, who worked on a darcs GUI frontend, already experienced 
this. ;-) 

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

Re: [Haskell-cafe] commending "Design concepts in programming languages"

[Wolfgang Jeltsch]

Am Freitag, 8. Mai 2009 14:31 schrieb Daniel Fischer:
> Though I had no contact with algebraists in the 1980s,

I also hadn’t. However, nowadays I have contact with someone who was an 
algebraist in the 1980s. It’s my boss (professor), by the way. :-) 

> > I think, also category theorists often wrote (write?) composition with
> > the first morphism on the left, i.e., “the other way round”.
>
> Yeah, I heard that, too. It's a field where the advantages of postfix
> notation show clearly and a young one, so for them it was relatively easy
> to switch.

However, I fear that all those other mathematicians who define
f . g = \x -> f(g(x), have made the category theorists switch to this 
suboptimal notation (first morphism on the right). At least, I cannot 
remember seeing the other notation (first morphism on the left) in category 
theory literature so far. It’s just that my above-mentioned professor told me 
that category theorists would use the first-morphism-on-the-left notation.

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

Re: [darcs-users] [Haskell-cafe] Darcs as undo/redo system?

[Wolfgang Jeltsch]

Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit:
> If you wanted to work on this, I would encourage you to read more
> about patch theory[1,2,3,4] and also try out libdarcs[5].

Is libdarcs the same as the darcs library package on Hackage (which exports 
the darcs API)?

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

Re: [Haskell-cafe] commending "Design concepts in programming languages"

[Wolfgang Jeltsch]

Am Donnerstag, 7. Mai 2009 14:42 schrieb Daniel Fischer:
> Of course, if centuries ago people had decided to write the argument before
> the function, composition would've been defined the other way round.
> They haven't.

Algebraists used to write x f instead of f(x) at least in the 1980s. I think, 
also category theorists often wrote (write?) composition with the first 
morphism on the left, i.e., “the other way round”.

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

Re: [Haskell-cafe] Interesting Thread on OO Usefulness (scala mailing list)

[Wolfgang Jeltsch]

Am Dienstag, 5. Mai 2009 18:39 schrieb Bulat Ziganshin:
> Hello Wolfgang,
>
> Tuesday, May 5, 2009, 8:27:17 PM, you wrote:
> >> i know two problems in Haskell/GHC that require OO-loke features -
> >> extensible exceptions and GUI widget types hierarchy
> >
> > Note that you don’t need different types for different kinds of GUI
> > widgets if you use Functional Reactive Programming (FRP). You need
> > different types if you use OO because you have to explicitely modify
> > widgets after you have created them, and what modifications you are
> > allowed to do, depends on the kind of widget. With FRP, you specify the
> > behavior over all time when you create the widget, so no need for later
> > method calls.
>
> (i don't know anything about FRP)
>
> i think it doesn't change anything. the main reason why i need common
> operations is because i write generic procedures. another erason os
> what i can't remember 100 individual 'setSize' operations for 100
> types of widgets. so we need to have some generic names, short of they
> are used due initialization or later

Yes, you need generic names also with FRP. The difference is that with OO, 
every property (e.g., size) corresponds to a pair of methods (setSize, 
getSize) while in FRP every property correspond to an input (or a parameter 
of the constructor if you think in OO terms). So with FRP, you need some kind 
of record system, preferably with the possibility to extend records. At 
least, this is the solution I use in Grapefruit.

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

Re: [Haskell-cafe] Interesting Thread on OO Usefulness (scala mailing list)

[Wolfgang Jeltsch]

Am Montag, 4. Mai 2009 13:35 schrieb Bulat Ziganshin:
> Hello Paolo,
>
> Monday, May 4, 2009, 2:05:44 PM, you wrote:
> > Martin Odersky advocates the OO features of the scala language
> > proposing an interesting problem where the OO approach seams
> > valuable.
>
> i know two problems in Haskell/GHC that require OO-loke features -
> extensible exceptions and GUI widget types hierarchy

Note that you don’t need different types for different kinds of GUI widgets if 
you use Functional Reactive Programming (FRP). You need different types if 
you use OO because you have to explicitely modify widgets after you have 
created them, and what modifications you are allowed to do, depends on the 
kind of widget. With FRP, you specify the behavior over all time when you 
create the widget, so no need for later method calls.

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

Re: [Haskell-cafe] Research in functional programming

[Wolfgang Jeltsch]

Am Sonntag, 3. Mai 2009 23:13 schrieb Louis Wasserman:
> Where might I find or submit a paper on functional data structures?
> Examples I've found so far include ICFP 
> and the JFP ,
> but Google hasn't found me anything else.
>
> Louis Wasserman
> wasserman.lo...@gmail.com

Have a look at .

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

Re: [Haskell-cafe] Research in functional programming

[Wolfgang Jeltsch]

Am Montag, 4. Mai 2009 11:32 schrieb Malcolm Wallace:
> TFP  - Trends in Functional Programming

Deadline on sunday.

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

Re: [Haskell-cafe] When is it OK to create a new mailing list?

[Wolfgang Jeltsch]

Am Samstag, 2. Mai 2009 14:11 schrieb Mads Lindstrøm:
> Hi
>
> I wanted a mailing list for my project WxGeneric and I am wondering when
> it is OK to do so? How big must the potential audience be? Is there any
> kind of etiquette or guidelines?
>
> Here http://haskell.org/mailman/admin it says that I must have "the
> proper authority" to create a mailing list. What is meant by "proper
> authority"? Can I just try to create one and see if I am successful? Or
> must I request someone to do it?

Hello,

I think there are two Mailmans on haskell.org. The page 
 refers to the one which hosts 
haskell-cafe, ghc-users, etc. The other one hosts the mailing lists of 
projects.haskell.org.

You can host relatively small projects on projects.haskell.org and you can 
create a mailing list for each of them. So maybe projects.haskell.org is the 
way to go for you?

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

Re: [Haskell-cafe] ANN: Elerea, another FRP library

[Wolfgang Jeltsch]

Am Mittwoch, 22. April 2009 16:00 schrieb Patai Gergely:
> This also means that if you want to restart a signal without external
> dependencies using a latcher, you have to inject some bogus dependency
> to prevent memoisation. If the new signal depends on some others,
> latching should behave intuitively.

So does this mean that whether a signal is started at the beginning or at 
switching time depends on what dependencies the signal has?

> > Implementing the first semantics is difficult since the system
> > would have to know what signals will be used later. I think
> > this is impossible in general because of undecidability
> > issues. (Grapefruit's approach is to force the user to specify
> > what signals are used later.)
>
> Do you have a compact use case that demonstrates this problem?

Maybe it’s not directly undecidability.

What I have in mind is the following: Say, you have a complicated function
f :: DTime -> Bool and two signals s1 and s2. Then you form the following 
signal: (\t -> if f t then s1 else s2) <$> time. In order to know what 
signals should be started at the beginning, you would have to know whether f 
will ever yield False or True so that you know which of s1 and s2 will be 
needed at some point.

> > Implementing the second semantics would require a single signal
> > having possibly different values when started at different
> > times. This in turn would disallow caching of signal values in
> > mutable variables.
>
> Or at least it would require deep copying some initial snapshot at every
> restart. But this only applies to completely self-contained signals,
> since anything that depends on the outer world cannot be restarted by
> definition.

Why not? You could have a signal which always yields the last key press. This 
clearly depends on the outer world. Then you construct another signal out of 
this which counts how often a certain key was pressed. If this latter signal 
is evaluated several times, it could start counting from different times on, 
couldn’t it?

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

Re: [Haskell-cafe] ANN: Elerea, another FRP library

[Wolfgang Jeltsch]

Am Dienstag, 21. April 2009 17:18 schrieb Patai Gergely:
> > What about evaluation time? If I remember correctly, the values
> > of signals depend on the time when the signal expressions are
> > evaluated. So evaluating them multiple times might lead to
> > different behavior. Is this correct?
>
> It is. However, there is really only one construct that needs extra care
> here: the latcher. All the others create top-level nodes that get
> evaluated just once during the first attempt to sample the output of the
> network. Therefore, duplication and merging of identical expressions
> only affects the performance unless they are hidden in the input signal
> of a latcher.

But isn’t the latter a fundamental problem?

To make things a bit more concrete, look at the following code snippet:

> time :: Signal DTime
> time = stateful 0 (+)
>
> timeSwitching :: Signal Bool -> Signal DTime
> timeSwitching control = latcher time control (pure time)

If the time signal is evaluated only once then for any signal c,
timeSwitching c should be equivalent to time. But what if I replace time by 
stateful 0 (+) in the definition of timeSwitching? If stateful 0 (+) is 
evaluated everytime a switch occurs then timeSwitching would always switch 
back to time 0.

So one first has to answer the question what the intended semantics should be. 
Should signals start at the beginning or should they start every time they 
are switched into?

Implementing the first semantics is difficult since the system would have to 
know what signals will be used later. I think this is impossible in general 
because of undecidability issues. (Grapefruit’s approach is to force the user 
to specify what signals are used later.)

Implementing the second semantics would require a single signal having 
possibly different values when started at different times. This in turn would 
disallow caching of signal values in mutable variables.

Maybe I just misunderstood something, so please correct me if I’m wrong.

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

Re: [Haskell-cafe] ANN: Elerea, another FRP library

[Wolfgang Jeltsch]

Am Donnerstag, 16. April 2009 10:06 schrieb Patai Gergely:
> unsafePerformIO is apparently never inlined, i.e. each instance is
> executed once, so sharing works as desired

But expressions that use unsafePerformIO might get inlined.

> CSE is no problem either, it even helps if it's performed (and it is
> with optimisations turned on), since it results in smaller equivalent
> networks

What about evaluation time? If I remember correctly, the values of signals 
depend on the time when the signal expressions are evaluated. So evaluating 
them multiple times might lead to different behavior. Is this correct?

> I think we can expect it to be fairly well-behaving, because the 'side
> effect' of Elerea primitives is basically the same as that of pure
> values in general: upon evaluation a value is created in the memory and
> we get a reference to it.

But in contrast to ordinary values, you have an internal mutable state, don’t 
you?

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

Re: [Haskell-cafe] Non-atomic "atoms" for type-level programming

[Wolfgang Jeltsch]

Am Dienstag, 14. April 2009 20:01 schrieb Tillmann Rendel:
> How is the need for a common import for 'data TTrue; data TFalse'
> different then the need for a common import for 'data Bool = True | False'?

Why not say

data True

data False,

instead of

data TTrue

data TFalse?

I don’t see the reason why we should insert the “T”. Data constructors are in 
a different namespace than type constructors.

By the way, the grapefruit-records package imports type-level, only to not 
define its own type-level booleans but to reuse “common” types whereas I 
considered type-level as the standard type level programming library.

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

Re: [Haskell-cafe] Re: ANN: Elerea, another FRP library

[Wolfgang Jeltsch]

Am Mittwoch, 15. April 2009 09:03 schrieb Achim Schneider:
> I don't think using dirty tricks to implement FRP deserves flak, at
> all, from my POV, it sounds like complaining that the IO monad is
> implemented using C... meaning that if you're that close to bare
> thunks, you have every right to use any means necessary to make them
> behave properly.

It depends. Using unsafe stuff internally, might be acceptable and sometimes 
necessary. I also use unsafePerformIO in Grapefruit for implementing CSignals 
although I’m not very comfortable with this.

On the other hand, breaking referential transparency in the external interface 
is a very bad idea, in my opinion. Actually, this means that the library user 
would have to turn certain compiler optimizations off to get the intended 
behavior. Just have a look at the Haddock docs of unsafePerformIO. In my 
earlier years of Haskell programming, I thought that unsafePerformIO is not 
too bad but I had to discover that it can quickly lead to a catastrophe.

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

Re: [Haskell-cafe] ANN: Elerea, another FRP library

[Wolfgang Jeltsch]

Am Samstag, 11. April 2009 16:57 schrieb Patai Gergely:
> > Any idea how Elerea compares to Grapefruit? It's great to see a lot of
> > competition in the FRP arena, but I hope in the end this results in a
> > really usable and scalable FRP system for Haskell :-)
>
> I think Wolfgang can judge this better, because I don't really know the
> innards of Grapefruit,

I didn’t have a deep look at Elerea so far but looked at the Haddock docs.

If I understand correctly, Elerea’s signals construct mutable variables for 
caching their current values when they are evaluated. This happens using 
unsafePerformIO. Grapefruit’s DSignals and SSignals use a purely functional 
data structure to represent several possible future values of whom only the 
ones which are actually occuring are evaluated. This data structure is 
created using unsafeInterleaveIO.

So Elerea seems to have to take special care to not break referential 
transparency. Grapefruit has to take care only with CSignals since only these 
are using unsafePerformIO internally.

Since Grapefruit uses ordinary expression evaluation for evaluating signal 
values, it can probably make use of certain compiler optimizations. Elerea’s 
evaluation seems to be driven by hand-coded IO actions so that use of such 
compiler optimizations is certainly not possible.

Both Grapefruit and Elerea probably need a way to fix a signal to a specific 
starting time. Grapefruit does this using era type parameters. Elerea doesn’t 
seem to do anything about this at the moment.

Patai, could you please correct me where I’m wrong and clarify the points 
which are still unclear to me?

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

Re: [Haskell-cafe] ANN: Elerea, another FRP library

[Wolfgang Jeltsch]

Am Dienstag, 14. April 2009 11:33 schrieb Patai Gergely:
> and then the integration of a Grapefruit-like and a Reactive-like system
> could be the ultimate solution in the long run.

What do you think, Grapefruit is lacking, compared to Reactive?

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

Re: [Haskell-cafe] ANN: Elerea, another FRP library

[Wolfgang Jeltsch]

Am Freitag, 10. April 2009 18:41 schrieb Patai Gergely:
> is based on some unsafePerformIO dark magic (that might easily break
> depending on many factors)

I wonder if this breaks referential transparency. Say, you define a signal s 
and use s twice in some expression. s may be evaluated once and it maybe 
evaluated twice. Does this make a difference?

In the Haddock docs, you say that repeated evaluation of the same value is 
prevented by caching. However, caching probably only works if the signal in 
question is only evaluated once. If it’s evaluated twice, the 
second “instance” probably cannot reuse cached values of the 
first “instance”. Is it possible that thereby the second “instance” has 
different values than the first one?

A well known FRP problem is that the values of a signal with internal state 
(an accumulating signal) depend on the time when the signal is started, i.e., 
when accumulation starts. When are your signals started? At evaluation time? 
If yes, doesn’t this mean that the meaning of a signal depends on evaluation 
time so that evaluating the same signal expression twice actually results in 
two different signals?

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

Re: [Haskell-cafe] Re: categories and monoids

[Wolfgang Jeltsch]

Am Donnerstag, 19. März 2009 13:58 schrieben Sie:
> An easier idea to think about would be to categorize most adjectives
> applied to mathematical constructs into traits and cotraits.
>
> A trait refines a notion and a cotrait broadens the definition.
>
> When talking about a commutative ring, commutativity is a trait, it narrows
> the definition of the ring, adding a requirement of commutativity to the
> multiplication operation.
>
> When talking about semi rings, semi is a cotrait. It broadens the
> definition of a ring, removing the requirement that addition form a group,
> weakening it to merely require a monoid.

Is “semi” and adjective at all? In German, we say “halb” instead of “semi” and 
the semi ring becomes a Halbring. Note that “halb” and “ring” are written 
toghether which means that “Halbring” is a compound noun. (We always write 
compound nouns as a single word, e.g., “Apfelsaft” for “apple juice”). So at 
least in German (which shares common roots with English), the “halb” is not 
considered an adjectiv. “halb” means “half”, so a “Halbring” is just half of 
a ring – not a special ring but less than a ring.

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

Re: [Haskell-cafe] Re: categories and monoids

[Wolfgang Jeltsch]

Am Mittwoch, 18. März 2009 15:17 schrieben Sie:
> Wolfgang Jeltsch schrieb:
> > Okay. Well, a monoid with many objects isn’t a monoid anymore since a
> > monoid has only one object. It’s the same as with: “A ring is a field
> > whose multiplication has no inverse.” One usually knows what is meant
> > with this but it’s actually wrong. Wrong for two reasons: First, because
> > the multiplication of a field has an inverse. Second, because the
> > multiplication of a ring is not forced to have no inverse but may have
> > one.
>
> “A ring is like a field, but without a multiplicative inverse” is, in my
> eyes, an acceptable formulation. We just have to agree that “without”
> here refers to the definition, rather than to the definitum.

Note that you said: “A ring is *like* a field.”, not “A ring is a field.” 
which was the formulation, I criticized above.

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

Re: [Haskell-cafe] Re: Haskell Logo Voting has started!

[Wolfgang Jeltsch]

Am Donnerstag, 19. März 2009 03:53 schrieb Benjamin L.Russell:
> Therefore, rank 1 is the best.

This is quite the opposite of what Denis Bueno said. :-( 

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

Re: [Haskell-cafe] Re: Haskell Logo Voting has started!

[Wolfgang Jeltsch]

Am Mittwoch, 18. März 2009 13:31 schrieben Sie:
> On Wed, Mar 18, 2009 at 04:36, Wolfgang Jeltsch wrote:
> > Am Mittwoch, 18. März 2009 10:03 schrieb Benjamin L.Russell:
> >> Just go through the list, choose your top favorite, and assign rank 1
> >> to it;
> >
> > Is rank 1 the best or the worst?
>
> The condorcet info page makes it clear that higher is better.
>
> http://www.cs.cornell.edu/w8/~andru/civs/rp.html

So assigning rank 1 to my favorite, as Benjamin suggested, might not be the 
best idea. :-(  I hope, everyone who voted did it the right way.

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

Re: [Haskell-cafe] Re: Haskell Logo Voting has started!

[Wolfgang Jeltsch]

Am Mittwoch, 18. März 2009 03:22 schrieb Robin Green:
> I'm afraid it is entirely terminal-based (i.e. text only), so it doesn't
> show the pictures.

Hmm, this doesn’t help me since I’ve already written a terminal-based app. See 
attachement. However, no guarantees that this app works as intended. The 
preferences shown by the app are currently meant to stand for better logos if 
they are lower. So 1 is the winner, not 113.

Well, the terminal-based app is still not enough for me since it’s way too 
time-consuming to always lookup the pictures. You should have a GUI showing 
the pictures and allowing you to select the better one of a pair by a single 
click.

Best wishes,
Wolfgang
module Main (

main

) where

import List hiding (sort)

main :: IO ()
main = do
   putStr "Number of items: "
   itemCount <- fmap read getLine
   sorted <- sort (\val1 val2 -> do
 putStr $ "Is "   ++
  show val1   ++
  " better than " ++
  show val2   ++
  "? "
 initAnswer <- getLine
 getDecision initAnswer)
  [1..itemCount]
   putStr $ unlines [show val ++ " has preference " ++ show rank |
 (val,rank) <- sortBy (\(val1,rank1)
(val2,rank2) -> compare 
val1 val2) $
   zip sorted [1..itemCount]]

getDecision :: String -> IO Bool
getDecision "n" = return False
getDecision "y" = return True
getDecision _   = do
  putStr "Illegal answer. Try again. "
  answer <- getLine
  getDecision answer

sort :: (Monad monad) => (val -> val -> monad Bool) -> [val] -> monad [val]
sort compare []= return []
sort compare [val] = return [val]
sort compare vals  = let

 (part1,part2) = dissociate vals

 in do
sorted1 <- sort compare part1
sorted2 <- sort compare part2
merge compare sorted1 sorted2

dissociate :: [val] -> ([val],[val])
dissociate []   = ([],[])
dissociate [val]= ([val],[])
dissociate (val1 : val2 : vals) = let

  (subpart1,subpart2) = dissociate vals

  in (val1 : subpart1,val2 : subpart2)

merge :: (Monad monad) => (val -> val -> monad Bool) -> [val] -> [val] -> 
monad [val]
merge compare [] [] = return []
merge compare vals1  [] = return vals1
merge compare [] vals2  = return vals2
merge compare (val1 : vals1) (val2 : vals2) = do
  before <- compare val1 
val2
  if before
  then do
   subresult <- 
merge compare

  vals1

  (val2 : vals2)
   return (val1 
: subresult)
  else do
   subresult <- 
merge compare

  (val1 : vals1)

  vals2
   return (val2 
: subresult)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Haskell Logo Voting has started!

[Wolfgang Jeltsch]

Am Dienstag, 17. März 2009 21:08 schrieb Robin Green:
> However, I am now hacking together a quick-and-dirty utility for
> ranking things which I will put on hackage. I'm not sure that anyone
> other than myself will use it, but it's fun hacking it up.

If you announce it on the mailing list, I might use it.

By the way, when will the voting period be over?

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

Re: [Haskell-cafe] Re: Haskell Logo Voting has started!

[Wolfgang Jeltsch]

Am Mittwoch, 18. März 2009 10:03 schrieb Benjamin L.Russell:
> Just go through the list, choose your top favorite, and assign rank 1
> to it;

Is rank 1 the best or the worst?

I thought it would be the worst so I would probably have voted exactly the 
opposite way than I wanted to. :-( 

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

Re: [Haskell-cafe] Re: Haskell Logo Voting has started!

[Wolfgang Jeltsch]

Am Dienstag, 17. März 2009 16:55 schrieb Eelco Lempsink:
> We'll see.  Worst case: nobody votes (with 123 votes at this moment, I
> don't think that will be the problem).  Second worst case: most people
> don't have/take the time to order a bit, so it turns into a majority
> vote.

Or there are many people like me who won’t vote at all because the process is 
so difficult and time-consuming. :-( 

> That said, you're absolutely right the visual feedback of the voting
> system is suboptimal.  I'd be very interested in seeing a good UI for
> this sort of task.  I imagine it'd be pretty close to printing
> everything on small pieces of paper and ordering them by hand ;) 

A good UI is what we need here. Maybe someone can write a simple app that does 
the following:

* download the logos from the Haskell web server

* present the user pairs of logos and let him decide which one of the two
presented logos he likes better

* shows a progress bar during voting

* presents the voting result for easy entering into the webpage

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

Re: [Haskell-cafe] Type equality proof

[Wolfgang Jeltsch]

Am Dienstag, 17. März 2009 21:51 schrieben Sie:
> On Tue, Mar 17, 2009 at 6:14 AM, Wolfgang Jeltsch wrote:
> > Am Dienstag, 17. März 2009 11:49 schrieb Yandex:
> > > data (a :=: a') where
> > >   Refl :: a :=: a
> > >   Comm :: (a :=: a') -> (a' :=: a)
> > >   Trans :: (a :=: a') -> (a' :=: a'') -> (a :=: a'')
> >
> > I don’t think, Comm and Trans should go into the data type. They are not
> > axioms but can be proven. Refl says that each type equals itself. Since
> > GADTs are closed, Martijn’s definition also says that two types can *only*
> > be equal if they are actually the same.
> >
> > Here are the original definition and the proofs of comm and trans.
> > Compiles fine with GHC 6.10.1.
> >
> >data (a :=: a') where
> >
> >Refl :: a :=: a
> >
> >comm :: (a :=: a') -> (a' :=: a)
> >comm Refl = Refl
> >
> >trans :: (a :=: a') -> (a' :=: a'') -> (a :=: a'')
> >trans Refl Refl = Refl
>
> These two theorems should be in the package.

But they should not be data constructors.

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

Re: [Haskell-cafe] Re: categories and monoids

[Wolfgang Jeltsch]

Am Mittwoch, 18. März 2009 05:36 schrieb wren ng thornton:
> Wolfgang Jeltsch wrote:
> > Am Dienstag, 17. März 2009 10:54 schrieben Sie:
> > > I'm reading the Barr/Wells slides at the moment, and they say the
> > > following:
> > >
> > > "Thus a category can be regarded as a generalized monoid,
> >
> > What is a “generalized monoid”? According to the grammatical construction
> > (adjective plus noun), it should be a special kind of monoid, like a
> > commutative monoid is a special kind of monoid. But then, monoids would
> > be the more general concept and categories the special case, quite the
> > opposite of how it really is.
>
> Usually in math texts "a Y is a generalized X" means exactly "Ys are a
> generalization of Xs", and thus Y is the larger class of objects got by
> relaxing some law in X. It's a description, not a name. E.g. Hilbert
> space is a generalized Euclidean space, Heyting algebras are generalized
> Boolean algebras, modules are generalized vector spaces, etc.

I know these phrases but I always considered them as something, mathematicians 
use when they talk to each other informally, not what they would write in a 
book.

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

[Haskell-cafe] Re: categories and monoids

[Wolfgang Jeltsch]

Am Dienstag, 17. März 2009 18:43 schrieben Sie:
> On Tue, Mar 17, 2009 at 5:06 AM, Wolfgang Jeltsch
>
>  wrote:
> > What is a “generalized monoid”? According to the grammatical construction
> > (adjective plus noun), it should be a special kind of monoid
>
> There's no such implication in English. The standard example used by
> linguists is "fake gun".

Okay, but this is a corner case isn’t it?

And the phrase “generalized monoid” has another problem. It’s not a single 
monoid that is generalized but the “monoid concept”. The class of monoids is 
extended to become the class of categories.

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

[Haskell-cafe] Re: categories and monoids

[Wolfgang Jeltsch]

Am Dienstag, 17. März 2009 16:32 schrieben Sie:
> On Tue, 2009-03-17 at 13:06 +0100, Wolfgang Jeltsch wrote:
> > A category is not a “generalized monoid” but categories (as a concept)
> > are a generalization of monoids. Each category is a monoid, but not the
> > other way round.
>
> You mean ``each monoid is a category, but not the other way round''.

Exactly. :-) 

> > What is a monoid with many objects?
>
> A categorical definition of a monoid (that is, a plain old boring monoid
> in Set) is that it is a category with a single object.  A category is
> thus a monoid with the restriction to a single object lifted :) 

Okay. Well, a monoid with many objects isn’t a monoid anymore since a monoid 
has only one object. It’s the same as with: “A ring is a field whose 
multiplication has no inverse.” One usually knows what is meant with this but 
it’s actually wrong. Wrong for two reasons: First, because the multiplication 
of a field has an inverse. Second, because the multiplication of a ring is 
not forced to have no inverse but may have one.

It reminds me of a definition of “constant” in programming languages which 
occured in some literature: “A constant is a variable whose value cannot be 
changed.” :-) 

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

Re: [Haskell-cafe] Type equality proof

[Wolfgang Jeltsch]

Am Dienstag, 17. März 2009 11:49 schrieb Yandex:
> data (a :=: a') where
>   Refl :: a :=: a
>   Comm :: (a :=: a') -> (a' :=: a)
>   Trans :: (a :=: a') -> (a' :=: a'') -> (a :=: a'')

I don’t think, Comm and Trans should go into the data type. They are not 
axioms but can be proven. Refl says that each type equals itself. Since GADTs 
are closed, Martijn’s definition also says that two types can *only* be equal 
if they are actually the same.

Here are the original definition and the proofs of comm and trans. Compiles 
fine with GHC 6.10.1.

data (a :=: a') where

Refl :: a :=: a

comm :: (a :=: a') -> (a' :=: a)
comm Refl = Refl

trans :: (a :=: a') -> (a' :=: a'') -> (a :=: a'')
trans Refl Refl = Refl

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

categories and monoids (was: Re: [Haskell-cafe] Design Patterns by Gamma or equivalent)

[Wolfgang Jeltsch]

Am Dienstag, 17. März 2009 10:54 schrieben Sie:
> Wolfgang Jeltsch  writes:
> > By the way, the documentation of Control.Category says that a category is
> > a monoid (as far as I remember). This is wrong. Category laws correspond
> > to monoid laws but monoid composition is total while category composition
> > has the restriction that the domain of the first argument must match the
> > codomain of the second. 
>
> I'm reading the Barr/Wells slides at the moment, and they say the
> following:
>
> "Thus a category can be regarded as a generalized monoid,

What is a “generalized monoid”? According to the grammatical construction 
(adjective plus noun), it should be a special kind of monoid, like a 
commutative monoid is a special kind of monoid. But then, monoids would be 
the more general concept and categories the special case, quite the opposite 
of how it really is.

A category is not a “generalized monoid” but categories (as a concept) are a 
generalization of monoids. Each category is a monoid, but not the other way 
round.

A monoid is clearly defined as a pair of a set M and a (total) binary 
operation over M that is associative and has a neutral element. So, for 
example, the category of sets and functions is not a monoid. First, function 
composition is not total if you allow arbitrary functions as its arguments. 
Second, the collection of all sets is not itself a set (but a true class) 
which conflicts with the above definition which says that M has to be a set.

> or a 'monoid with many objects'"

What is a monoid with many objects?

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

Re: [Haskell-cafe] Design Patterns by Gamma or equivalent

[Wolfgang Jeltsch]

Am Dienstag, 17. März 2009 05:09 schrieb wren ng thornton:
> a...@spamcop.net wrote:
> > Or to put it another way, category theory is the pattern language of
> > mathematics.
>
> Indeed. Though, IMO, there's a distinction between fairly banal things
> (e.g. monoids),

Monoids aren’t a concept of category theory. There are a generalization of 
groups. So they more belong to group theory.

By the way, the documentation of Control.Category says that a category is a 
monoid (as far as I remember). This is wrong. Category laws correspond to 
monoid laws but monoid composition is total while category composition has 
the restriction that the domain of the first argument must match the codomain 
of the second.

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

Re: [Haskell-cafe] Natural Numbers: Best implementation?

[Wolfgang Jeltsch]

Am Samstag, 14. März 2009 23:33 schrieben Sie:
> On Fri, 13 Mar 2009, Wolfgang Jeltsch wrote:
> > Class instances should satisfy certain laws. (Although these laws are
> > often not stated explicitely, they are assumed to hold by users of the
> > class and they should hold to make the instance sensible.) In the case of
> > Num, I would expect num + negate num to equal num.
>
> "equal zero" ?

Exactly.

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

Re: [Haskell-cafe] Microsoft PhD Scholarship at Strathclyde

[Wolfgang Jeltsch]

Am Samstag, 14. März 2009 14:51 schrieb Conor McBride:
> > Conor, is Epigram currently under development?
>
> We've even stopped working on the engine and started working on the chassis.
> I'm in an intensive teaching block until the end of April, but from May it
> becomes Priority. The "Reusability and Dependent Types" project studentship 
> will hopefully bring an extra pair of hands, come October.

This sounds good!

> I don't see any conflict -- indeed I see considerable synergy -- in working
> simultaneously on the experimental frontier of dependent type systems and
> on the pragmatic delivery of their basic benefits via a much more
> established language like Haskell. Indeed, I think we'll learn more readily
> about the engineering realities of developing applications with dependent
> types by doing plenty of the latter.

This makes sense indeed.

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

Re: [Haskell-cafe] Microsoft PhD Scholarship at Strathclyde

[Wolfgang Jeltsch]

Am Samstag, 14. März 2009 08:19 schrieb Peter Verswyvelen:
> Well, in C++ one can already use the numerical values with templates for
> achieving a lot of compile time computations.
>
> So I would be very happy to have this feature in Haskell. It might also be
> good research towards full dependent types no?

I doubt that it will be a good thing to include full dependent types into a 
language with partial functions like Haskell.

Conor, is Epigram currently under development?

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

Re: [Haskell-cafe] Natural Numbers: Best implementation?

[Wolfgang Jeltsch]

Am Freitag, 13. März 2009 09:21 schrieb Roman Cheplyaka:
> * Alexander Dunlap  [2009-03-12 20:01:57-0700]
>
> > Also, a lot of functions just take
> > Integers so it would be more of a pain to use.
>
> AFAIK there are very few fuctions that take Integers. Many functions
> take instances of Integral, but it's not a problem to make your own type
> such an instance.

I’d say that it is a problem. Class instances should satisfy certain laws. 
(Although these laws are often not stated explicitely, they are assumed to 
hold by users of the class and they should hold to make the instance 
sensible.) In the case of Num, I would expect num + negate num to equal num. 
This wouldn’t hold for a Natural instance of Num.

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

Re: [Haskell-cafe] Natural Numbers: Best implementation?

[Wolfgang Jeltsch]

Am Freitag, 13. März 2009 04:53 schrieb Brandon S. Allbery KF8NH:
> On 2009 Mar 12, at 22:54, Mark Spezzano wrote:
> > I was wondering what the best way to implement Natural number would
> > be. Is there a package which already does this?
>
> type-level on Hackage.

I think, the original poster wanted value-level naturals, not type-level 
naturals.

> > 2.  Use the type
> > data Natural = Zero | Succ !Natural
>
> One of the reasons people use type-level naturals is to get laziness;
> you've made this strict.  Is there a reason?

Do you really mean type-level naturals? The following is a definition of 
value-level naturals:

data Natural = Zero | Succ Natural

Type-level naturals would be defined like this:

data Zero

data Succ nat

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

Re: [Haskell-cafe] Natural Numbers: Best implementation?

[Wolfgang Jeltsch]

Am Freitag, 13. März 2009 04:01 schrieb Alexander Dunlap:
> > 2.  Use the type
> >
> > data Natural = Zero | Succ !Natural
>
> […]
>
> In terms of speed, I think that [3] would be reasonably fast (unless
> you do a ton of subtraction with bounds-checking) and [2] would
> probably be quite slow, because you don't get the speed-boost from
> doing computations right on the processor.

Not only that but also because operations like addition now take at least 
linear time.

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

Re: [Haskell-cafe] State monad is missing Applicative instance

[Wolfgang Jeltsch]

Am Freitag, 13. März 2009 05:09 schrieb Denis Bueno:
> This works because every monad induces an Applicative instance in a
> way I've ingested just enough wine to forget. =]

pure = return

(<*>) = ap

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

Re: [Haskell-cafe] Re: Against cuteness

[Wolfgang Jeltsch]

Am Freitag, 13. März 2009 04:29 schrieb Benjamin L.Russell:
> Consider the following logo:
>
> Silver red monad.png
> http://commons.wikimedia.org/wiki/File:Silver_red_monad.png

Can’t we choose something which is not connected to certain worldviews?

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

Re: [Haskell-cafe] Re: Sugestion for a Haskell mascot

[Wolfgang Jeltsch]

Am Donnerstag, 12. März 2009 22:00 schrieb Martijn van Steenbergen:
> Deniz Dogan wrote:
> > Then of course,
> > there's the downside that there's no connection to the language itself
> > in any way.
>
> I usually go for names that don't have to do anything with the
> application itself: GroteTrap (translates to GreatBustard), Yogurt,
> Custard... saves me from having to think of "appropriate" names. :-P 

This is basically how I chose the name “Grapefruit” for “my” FRP library. 
Okay, it refers to Fruit (a FRP GUI library) but the only further meaning 
of “Grapefruit” is that I find Grapefruits to be tasty. :-)  Often people 
choose meaningful names and convert them to acronyms, noone can pronounce.

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

Re: [Haskell-cafe] How to insert character key self in sourceView?

[Wolfgang Jeltsch]

Maybe you should direct your question to the Gtk2Hs users mailing list 
.

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

Re: [Haskell-cafe] Sugestion for a Haskell mascot

[Wolfgang Jeltsch]

Am Dienstag, 10. März 2009 00:59 schrieb Joe Fredette:
> Hehe, I love it. Sloth is a synonym for Lazyness in English too, and
> they're so freaking cute... :) 

Same in German: The german “Faultier” means “lazy animal”.

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

Re: [Haskell-cafe] FRP + physics / status of hpysics

[Wolfgang Jeltsch]

Am Samstag, 7. März 2009 18:49 schrieb Roman Cheplyaka:
> Great! I'll have more free time after March 15, and we can arrange an
> IRC meeting to discuss this.

I’d be happy if you would also invite me to this IRC meeting when it will 
finally happen.

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

[Haskell-cafe] Re: [grapefruit] [reactive] FRP + physics / status of hpysics

[Wolfgang Jeltsch]

Am Freitag, 6. März 2009 17:57 schrieb Wolfgang Jeltsch:
> Am Freitag, 6. März 2009 17:51 schrieb Wolfgang Jeltsch:
> > By the way, the adress of the Grapefruit mailing list is
> > grapefr...@projects.haskell.org, not grapefr...@haskell.org.
>
> Oh, this is really strange: I addressed my e-mail to
> grapefr...@projects.haskell.org but the version arriving at the Reactive
> mailing list has grapefr...@haskell.org in its To: header. However, my
> e-mail also reached the Grapefruit mailing list (but Daniel Bünzli’s
> didn’t) and the version there has the correct address in its To: headers.
>
> Does anyone know who is responsible for the Haskell mail server?
>
> Best wishes,
> Wolfgang

It was a misconfiguration of the mailserver which is believed to be fixed now.

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

[Haskell-cafe] Re: [reactive] FRP + physics / status of hpysics

[Wolfgang Jeltsch]

Am Freitag, 6. März 2009 17:51 schrieb Wolfgang Jeltsch:
> By the way, the adress of the Grapefruit mailing list is
> grapefr...@projects.haskell.org, not grapefr...@haskell.org.

Oh, this is really strange: I addressed my e-mail to 
grapefr...@projects.haskell.org but the version arriving at the Reactive 
mailing list has grapefr...@haskell.org in its To: header. However, my e-mail 
also reached the Grapefruit mailing list (but Daniel Bünzli’s didn’t) and the 
version there has the correct address in its To: headers.

Does anyone know who is responsible for the Haskell mail server?

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

[Haskell-cafe] Re: [reactive] FRP + physics / status of hpysics

[Wolfgang Jeltsch]

Am Freitag, 6. März 2009 14:34 schrieb Daniel Bünzli:
> > without using recursive signal functions,
>
> If this is because there's this limitation in the frp system you use

It is.

> then better fix the system.

The system is Grapefruit, by the way. And I’m its developer, by the way. :-)  
I have to say that it’s hard, if not impossible, to combine recursive signal 
definitions with other features, I want to have.

The point of recursive definitions is that you want to turn recursive 
equations from your problem domain directly into Haskell definitions. This is 
nice from a user’s point of view but hard from a programmers point of view. 
Standard Haskell already shows that. While it is possible to define an 
infinite list of ones by

ones = 1 : ones,

it is not possible to do the same for sequences of type Seq. The above 
definition of ones relies very much on the structure of lists. Analogously, 
the ability to define signals recursively restricts the set of possible 
signal implementations seriously.

Haskell’s recursive definitions are very general. They have to find fixpoints 
of arbitrary functions over arbitrary type. Therefore, their semantics are 
rather weak. They give you the least defined fixpoint. The consequence is 
that you get bottom if you use something like

x = 0 * x

although x = 0 might be what you prefered.

What I want to say is that coming up with a signal implementation that allows 
Haskell recursion and has other advantages at the same time is a big 
challenge. There are three features, you might want from a signal 
implementation:

1. support for recursive signal definitions using Haskell equations

2. memoization (for avoiding time leaks, for example)

3. signals which may depend on external sources

I tried hard to support 2 and 3 well in Grapefruit. Fran has 1 but has 
problems with 2 and 3. I don’t know whether Reactive has a solution for 2 in 
the context of recursive definitions, i.e., whether the space and time leak 
problems of Fran were solved. I think, it has at least problems with 3.

For me, 2 and 3 are more important than 1. One reason is that 1 has other 
problems than being in conflict with 2 and 3. The result of a recursively 
defined signal depends on when sampling occurs. Since a recursive definition 
tends to result in accumulation of values, errors introduced by sampling may 
accumulate too. So you have to use clever approximation algorithms in 
addition.

My new idea is to view the problem in a different way. Let’s take the problem 
where the position of a ball is the integral of the difference between the 
mouse position and the ball position. As far as I can see, the transformation 
of the mouse position signal into the ball position signal forms a linear 
system. So the ball position signal is the mouse position signal convoluted 
with another signal.

If we would have a function that performes convolution, we could probably 
implement many problems using this function. Using convolution would let us 
get rid of the problems with accumulating errors.

I suppose that most of the recursive definitions you would use in FRP are 
differential or integral equations. Let’s look at the equation for the 
ball-following-the-mouse example:

ballPos = integral (mousePos - ballPos)

ballPos can be represented in terms of mousePos as follows:

ballPos = (exp . negate) * mousePos

where * means convolution. We could provide a library which supports common 
stuff like distance-dependent acceleration, friction etc.

Of course, you could say that now the programmer isn’t able anymore to enter 
his equations directly which isn’t nice. However, this situation is not 
different to other areas. For example, you cannot write

x = 5 - x / 2

and expect x to be 10 / 3. Instead, you have to transform the equation first.

> Soon or later it you'll want it elsewhere. A recursive reactive signal just
> means that some of what your reactive program computed will be
> usefull/necessary for the next step.

You can do this with convolution, I think.

By the way, continuous signals don’t have steps. These are just introduced by 
sampling.

> You'll see that happen very quickly (e.g. any simple reactive state
> machine).

“State machine” sounds like a discrete problem. You can use accumulation over 
event sequences here (as, for example, provided by the scan function in 
FRP.Grapefruit.Signal.Discrete).

By the way, the adress of the Grapefruit mailing list is 
grapefr...@projects.haskell.org, not grapefr...@haskell.org.

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

Re: [Haskell-cafe] A foray into type-level programming, and getting stuck

[Wolfgang Jeltsch]

Am Sonntag, 1. März 2009 22:10 schrieb Brian Bloniarz:
> Hi George,
>
> Since none of the type metaprogramming specialists have answered you
> on-list, I took a crack at this -- I think you can work around the issue by
> avoiding overlapping instances entirely. I learned about this technique
> from the HList paper & this message:
> http://okmij.org/ftp/Haskell/keyword-arguments.lhs
> (see "the rest of the implementation").

Note that HList still needs overlapping instances for implementing type 
equality. If we will have closed type families at some future time, this will 
change. See:



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

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

[Wolfgang Jeltsch]

Am Donnerstag, 26. Februar 2009 20:20 schrieb Achim Schneider:
> Wolfgang Jeltsch  wrote:
> > Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde:
> > > Peter Hercek  writes:
> > > >> Relinking against newer Gtk2Hs versions might not work.
> > >
> > > You have the option of recompiling the new Gtk2Hs with the old GHC
> > > and relinking, don't you?
> >
> > Relinking is technically not possible because of inlining.
>
> I don't think the situation is any different from providing C headers
> that contain macros or inline functions.

But as Peter Hercek said, the LGPL limits the amount of macro expansion for C 
libraries. And the amount of GHC’s inlining would probably exceed all 
limits. ;-) 

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

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

[Wolfgang Jeltsch]

Am Donnerstag, 26. Februar 2009 21:39 schrieb Peter Hercek:
> The acceptable size of inlined fuctions for a C code is about 10 lines.
> I did not read any info how it would be for Haskell.

At least, GHC inlines very massively, to my knowledge. And I think you need 
this massive inlining for reasonable performance because of Haskell’s high 
level nature, lazy evaluation, etc.

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

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

[Wolfgang Jeltsch]

Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde:
> Peter Hercek  writes:
> >> Relinking against newer Gtk2Hs versions might not work.
>
> You have the option of recompiling the new Gtk2Hs with the old GHC and
> relinking, don't you?

Relinking is technically not possible because of inlining.

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

Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing

[Wolfgang Jeltsch]

Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek:
> So my opinion (IAMNAL):
> 1) source code under very limiting commercial license (just to allow
> recompile with a newer LGPL lib and nothing else) is OK
> 2) it is probable that only the *.o, *.hi files and a linking script are
> OK too

I think, it’s technically not possible to let your Haskell application use 
another library version when you just have the .o and .hi files of the new 
library version. The .hi files typically contain code which is inlined by the 
application, so you have to be able to recompile the application. Or am I 
misunderstanding you?

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

[Haskell-cafe] Grapefruit infrastructure

[Wolfgang Jeltsch]

Hello,

I just want to mention that the Grapefruit FRP library now has a mailing list 
and a Trac instance which contains a bug tracker. See:



Please also note that the Grapefruit repositories have moved to 
code.haskell.org.

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

Re: [Haskell-cafe] subscription problems for projects.haskell.org mailing list

[Wolfgang Jeltsch]

Am Mittwoch, 25. Februar 2009 17:15 schrieb Wolfgang Jeltsch:
> Am Mittwoch, 25. Februar 2009 17:05 schrieb Wolfgang Jeltsch:
> > Hello,
> >
> > I created a mailing list for Grapefruit on the Haskell Community Server
> > (). If I try to subscribe to it, I
> > receive a confirmation e-mail but my answers to this e-mail seem to get
> > ignored. Does anyone have an idea what’s wrong here?
>
> Confirmation via the weblink inside the confirmation e-mail works, by the
> way.

Meanwhile, I received automatic answers to my two unsuccesful confirmation 
e-mails. They both claim that the confirmation string is invalid. However, 
the confirmation string worked when confirming via the website.

The only problem I can imagine at the moment is that the URLs with the 
confirmation string were broken into two lines in my confirmation e-mails. 
However, Mailman should take the string from the subject line, shouldn’t it?

The error notifications told me that for each of my confirmation e-mails, the 
last paragraph was “ignored” while everything before it was “unprocessed”. 
What does that mean?

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

Re: [Haskell-cafe] subscription problems for projects.haskell.org mailing list

[Wolfgang Jeltsch]

Am Mittwoch, 25. Februar 2009 17:05 schrieb Wolfgang Jeltsch:
> Hello,
>
> I created a mailing list for Grapefruit on the Haskell Community Server
> (). If I try to subscribe to it, I receive
> a confirmation e-mail but my answers to this e-mail seem to get ignored.
> Does anyone have an idea what’s wrong here?

Confirmation via the weblink inside the confirmation e-mail works, by the way.

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

[Haskell-cafe] subscription problems for projects.haskell.org mailing list

[Wolfgang Jeltsch]

Hello,

I created a mailing list for Grapefruit on the Haskell Community Server 
(). If I try to subscribe to it, I receive a 
confirmation e-mail but my answers to this e-mail seem to get ignored. Does 
anyone have an idea what’s wrong here?

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

Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing

[Wolfgang Jeltsch]

Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts:
> Note that some people will tell you that by a strict interpretation of
> the LGPL that statically linked Haskell libs under that license are a
> pain in the backside. When we decided on that license for gtk2hs that
> was not our intention. In other words nobody is going to sue you if you
> statically link gtk2hs libs. Of course if you need a cast iron legal
> guarantee then that's not good enough and you'd have to ship .a and .o
> files to let users relink if they wanted to.

I’m not sure whether this would be enough. .a and .o files are not compatible 
among GHC versions, as far as I know. Relinking against newer Gtk2Hs versions 
might not work. And a program using Gtk2Hs contains code from the .hi files 
of Gtk2Hs through inlining. So it’s not pure linking. However, the LGPL only 
allows linking, as far as I understand.

I want to repeat what I’ve said earlier on this list: For Haskell, there is no 
real difference between LGPL and GPL, as far as I understand it. If you don’t 
want to force the users of your library to use an open source license for 
their work then use BSD3 or a similar license for your library.

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