Richard Cobbe | 1 Aug 2012 02:35
Favicon

Re: GHC rendering of non-ASCII characters configurable?

On Tue, Jul 31, 2012 at 09:17:34PM +1000, Ivan Lazar Miljenovic wrote:
> On 31 July 2012 21:01, Richard Cobbe <cobbe <at> ccs.neu.edu> wrote:
> > On Mon, Jul 30, 2012 at 11:45:38PM +1000, Ivan Lazar Miljenovic wrote:

> >> Can I ask what you're doing here? Are you printing individual
> >> characters or entire chunks of text?
> >
> > Mostly, I'm working with expressions of type String, rather than Text;
>
> Any particular reason why?  Using Text will probably solve your
> problem and give you a performance improvement at the same time.

Well, I initially went with String because I didn't want to clutter up my
code with all of the calls to 'pack', especially around string literals.
I'm open to being convinced that it's worth it to switch, though.

In any case, while Text is undoubtedly faster than String, it unfortunately
doesn't solve my problem with output rendering:

    [vimes:~]$ ghci
    GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
    Loading package ghc-prim ... linking ... done.
    Loading package integer-gmp ... linking ... done.
    Loading package base ... linking ... done.
    Prelude> :m +Data.Text
    Prelude Data.Text> pack "\x1f00"
    Loading package array-0.4.0.0 ... linking ... done.
    Loading package bytestring-0.9.2.1 ... linking ... done.
    Loading package deepseq-1.3.0.0 ... linking ... done.
    Loading package text-0.11.2.0 ... linking ... done.
(Continue reading)

Thomas Schilling | 1 Aug 2012 02:54
Gravatar

Re: Haskell Platform - BSD License?

You may concatenate the licenses of all the packages you are using. GHC includes the LGPL libgmp. The license file for each package is mentioned in the .cabal file.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Patrick Browne | 1 Aug 2012 10:01
Picon

Re: specifying using type class

Ertugrul,
Thank you for your detailed and helpful reply.
I was unaware of the distinction between data/value and type constructors.
Regards,
Pat



On 31/07/12, Ertugrul Söylemez <es <at> ertes.de> wrote:
Patrick Browne <patrick.browne <at> dit.ie> wrote:

> Thanks for all the very useful feed back on this thread.
> I would like to present my possibly incorrect summarized  view:
> Class signatures can contain placeholders for constructors.
> These place-holder-constructors cannot be used in the class to define
> functions (I assume other in-scope constructors can be used). In the
> instance a real constructor can be substituted for the
> place-holder-constructor. Does this restrict the type of equation
> that can be used in a type class? It seems that some equations
> respecting the constructor discipline are not allowed.

Your intuition seems to be near the truth, although your terminology is
currently wrong.  Let's look at an example:

    class Functor f where
        fmap :: (a -> b) -> (f a -> f b)

The 'f' in the class header is probably what you call a "placeholder for
constructors".  This is not a placeholder, but a type variable.  It
represents a type.  Incidentally in this case it indeed represents a
constructor, namely a /type/ constructor (like Maybe).  This is an
important distinction, because generally when we talk about
"constructors", we mean /value/ constructors (like Just or Nothing):

    data Maybe a = Just a | Nothing

Here Maybe is a type constructor.  This is because it's not a type in
its own right, but is applied to another type (like Int) to yield an
actual type (Maybe Int).  The type Maybe is applied to is represented
by the type variable 'a' in the code above.  To simplify communication
we often call Maybe itself also a type, but it's really not.

Let's write the Functor instance for Maybe.  It is common to use a
helper function (a so-called fold function), which allows us to express
many operations more easily.  It's called 'maybe' for Maybe:

    maybe :: b -> (a -> b) -> Maybe a -> b
    maybe n j (Just x) = j x
    maybe n j Nothing  = n

    instance Functor Maybe where
        fmap f = maybe Nothing (Just . f)

This is the instance for Maybe.  The type variable 'f' from the class
now becomes a concrete type constructor Maybe.  In this instance you
have f = Maybe, so the type of 'fmap' for this particular instance
becomes:

    fmap :: (a -> b) -> (Maybe a -> Maybe b)

The notable thing here is that this is really not a
placeholder/replacement concept, but much more like a function and
application concept.  There is nothing that stops you from having type
variables in an instance:

    instance Functor (Reader e) where

As you can see there is still what you called a "placeholder" in this
instance, so the placeholder concept doesn't really make sense here.
The declaration can be read as:

    "For every type 'e' the type 'Reader e' is an instance of the
    Functor type class."


> I appreciate that in Haskell the most equations occur in the
> instances, [...]

Not at all.  When programming Haskell you write lots and lots of
equations outside of class instances.  Whenever you write "=" you
introduce an equation, for example in top-level definitions and in 'let'
and 'where' bindings.


> [...] but from my earlier post: "I merely wish to identify the
> strengths and weakness of *current Haskell type classes* as a pure
> *unit of specification*"

I think you will be interested in this Stack Overflow answer:

    <http://stackoverflow.com/a/8123973>

Even though the actual question answered is different, it does give a
nice overview of the strengths and weaknesses of type classes.


Greets,
Ertugrul

--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.

Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a bheith slán. http://www.dit.ie
This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Erik Hesselink | 1 Aug 2012 10:24
Picon
Gravatar

Re: GHC rendering of non-ASCII characters configurable?

On Wed, Aug 1, 2012 at 2:35 AM, Richard Cobbe <cobbe <at> ccs.neu.edu> wrote:
> Well, I initially went with String because I didn't want to clutter up my
> code with all of the calls to 'pack', especially around string literals.
> I'm open to being convinced that it's worth it to switch, though.

For string literals, you can turn on OverloadedStrings to get rid of
the calls to 'pack'.

Erik
Heinrich Apfelmus | 1 Aug 2012 14:43
Picon
Favicon
Gravatar

Re: Key-Parametrized Lookup Table

Alexander Foremny wrote:
> At first glance I noticed some problems with the vault library for my
> particular approach.
> 
> Despite from being unique, Key values don't appear to carry any
> information like the Label I need. However, it might be possible to
> work around that.
> 
> The more grave problem seems to be that a Key cannot be
> (de-)serialized. This might be impossible due to the type parameter a
> in Key a.

Vault is intended to be a store for values of any type, so it doesn't 
include any restriction on the type  a  in  Key a . For reasons of type 
safety, this means that keys have to be abstract. You can't create a 
typed key from an untyped label alone, because this would allow you to 
coerce a value to a different type (just create two keys of different 
types from the same label).

> However, it is no problem to fix the types of values to some finite collection.

That should work. You have to reify the type  a  in  Key a  in the value 
of the key. I think it's possible to use a data type family for the map 
type.

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com
Paolino | 1 Aug 2012 18:43
Picon
Gravatar

Re: Key-Parametrized Lookup Table


Hello, I made some trial and error with ghci to make it happy. I'm not really sure this has the type safety you asked.

{-# LANGUAGE TypeFamilies, ExistentialQuantification, FlexibleContexts #-}

import Prelude hiding (lookup)
import Data.Typeable

class Typeable a => Key a where
    type Value a :: *
   
data Assoc = forall a . (Typeable (Value a),Key a) => Assoc a (Value a)

insert :: (Typeable (Value a), Key a) => a -> Value a -> [Assoc] -> [Assoc]
insert k v = (Assoc k v :)

lookup :: (Typeable (Value a), Eq a, Key a) => a -> [Assoc] -> Value a
lookup k [] = error "noassoc"
lookup k ((Assoc k' v):xs) = case cast k' of
        Nothing -> lookup k xs
        Just k'' -> if k'' == k then case cast v of
                Nothing -> error "nocast"
                Just v' -> v'
            else lookup k xs

I've tried without the typeclass with no luck.
For some reasons

type family Key a :: *
type family Value a :: *

and adding Typeable (Key a) to the contexts and Key 'a' in place of 'a' leads to a lot of type errors.
Maybe it's possible with more help.

Hope I got it right.

Regards
paolino

2012/7/31 Alexander Foremny <alexanderforemny <at> gmail.com>
Hello list,

I am currently thinking that a problem of mine would best be solved if
there was a Map-like data structure in which the value returned is
parametrized over the lookup type.

I wonder is this makes sense and if such a data structure exists or if
it could be created while still being well typed. I essentially want
to statically define a scope of Key values and dynamically define a
list of keys.

> -- Scope of possible keys.
> type Label = String
> data Key a where
>     KeyStr :: Label -> Key String
>     KeyInt :: Label -> Key Int
>     KeyChoice :: Label -> [a] -> Key a

> -- Some key values, to be extended at runtime.
> strKey "Some String"
> strKey' "Another String"
> intKey "Some integer"
> choiceKey "Chose one" [ "a", "b", "c" ] :: KeyChoice String

Now I need a data structure to possibly associate a value to the key.

> data MapG = ...
> type Value a = a
> insert :: Key a -> Value a -> MapG Key Value -> MapG Key Value
> lookup :: Key a -> MapG Key Value -> Maybe (Value a)

I tried implementing this with multiple Map k a's. I tried adding a
phantom type on some storage type of to implement KeyChoice as of type
Key Int, but I ran into troubles with this approach. I wonder if
Dynamic or Type Families could achieve this, but I am quite at a loss
and would like to hear your opinion.

I did try to search for this a bit, but I don't quite know how to
phrase my problem. I'd like to apologize in advance if this question
has been asked already.

Regards,
Alexander Foremny

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Paolino | 1 Aug 2012 19:16
Picon
Gravatar

Re: Key-Parametrized Lookup Table

This is without class :-)

{-# LANGUAGE TypeFamilies, ExistentialQuantification, FlexibleContexts #-}
import Prelude hiding (lookup)
import Data.Typeable

type family Value a :: *
   
data Assoc = forall a . (Typeable (Value a), Typeable a) => Assoc a (Value a)

insert :: (Typeable (Value a), Typeable a) => a -> Value a -> [Assoc] -> [Assoc]
insert k v = (Assoc k v :)

lookup :: (Typeable (Value a), Typeable a, Eq a) => a -> [Assoc] -> Value a
lookup k [] = error "noassoc"
lookup k ((Assoc k' v):xs) = case cast k' of
        Nothing -> lookup k xs
        Just k'' -> if k'' == k then case cast v of
                Nothing -> error "nocast"
                Just v' -> v'
            else lookup k xs

*Main> type instance Value Integer  = Char
*Main> type instance Value Int = String
*Main> let u = insert (1::Integer) 'c' $ insert (1::Int) "ciao" []
*Main> lookup (1 :: Integer)  u
'c'
*Main> lookup (1 :: Int)  u
"ciao"
*Main>

Regards
paolino

2012/8/1 Paolino <paolo.veronelli <at> gmail.com>

Hello, I made some trial and error with ghci to make it happy. I'm not really sure this has the type safety you asked.

{-# LANGUAGE TypeFamilies, ExistentialQuantification, FlexibleContexts #-}

import Prelude hiding (lookup)
import Data.Typeable

class Typeable a => Key a where
    type Value a :: *
   
data Assoc = forall a . (Typeable (Value a),Key a) => Assoc a (Value a)

insert :: (Typeable (Value a), Key a) => a -> Value a -> [Assoc] -> [Assoc]
insert k v = (Assoc k v :)

lookup :: (Typeable (Value a), Eq a, Key a) => a -> [Assoc] -> Value a
lookup k [] = error "noassoc"
lookup k ((Assoc k' v):xs) = case cast k' of
        Nothing -> lookup k xs
        Just k'' -> if k'' == k then case cast v of
                Nothing -> error "nocast"
                Just v' -> v'
            else lookup k xs

I've tried without the typeclass with no luck.
For some reasons

type family Key a :: *
type family Value a :: *

and adding Typeable (Key a) to the contexts and Key 'a' in place of 'a' leads to a lot of type errors.
Maybe it's possible with more help.

Hope I got it right.

Regards
paolino


2012/7/31 Alexander Foremny <alexanderforemny <at> gmail.com>
Hello list,

I am currently thinking that a problem of mine would best be solved if
there was a Map-like data structure in which the value returned is
parametrized over the lookup type.

I wonder is this makes sense and if such a data structure exists or if
it could be created while still being well typed. I essentially want
to statically define a scope of Key values and dynamically define a
list of keys.

> -- Scope of possible keys.
> type Label = String
> data Key a where
>     KeyStr :: Label -> Key String
>     KeyInt :: Label -> Key Int
>     KeyChoice :: Label -> [a] -> Key a

> -- Some key values, to be extended at runtime.
> strKey "Some String"
> strKey' "Another String"
> intKey "Some integer"
> choiceKey "Chose one" [ "a", "b", "c" ] :: KeyChoice String

Now I need a data structure to possibly associate a value to the key.

> data MapG = ...
> type Value a = a
> insert :: Key a -> Value a -> MapG Key Value -> MapG Key Value
> lookup :: Key a -> MapG Key Value -> Maybe (Value a)

I tried implementing this with multiple Map k a's. I tried adding a
phantom type on some storage type of to implement KeyChoice as of type
Key Int, but I ran into troubles with this approach. I wonder if
Dynamic or Type Families could achieve this, but I am quite at a loss
and would like to hear your opinion.

I did try to search for this a bit, but I don't quite know how to
phrase my problem. I'd like to apologize in advance if this question
has been asked already.

Regards,
Alexander Foremny

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Tom Murphy | 2 Aug 2012 07:29
Picon

Proposal: Technique to handle package dependency gridlock

We've got a problem with dependencies:
http://cdsmith.wordpress.com/2011/01/21/a-recap-about-cabal-and-haskell-libraries/
http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/
http://www.reddit.com/r/haskell/comments/x4knd/what_is_the_reason_for_haskells_cabal_package/

I'd like to present a proto-proposal for another arrow in our quiver.

First, a few...
Principles:

  This problem isn't uniquely Haskell's
    ...Although it may be uniquely Haskell's to solve. Lots of
languages have a problem managing their package dependencies. To quote
Chris Smith, "it’s fair to say that perhaps Haskell is one of the few
environments where we’ve got a prayer at solving the problem."

  It's a magnitude problem
    The trick is to not find one perfect solution; it's to use enough
effective solutions that the remaining tricky cases can be swept away
individually. Solving the problem will most likely involve several
techniques (good versioning policy, a little work on the part of
package maintainers, smarter Cabal, new tools, etc.). Once we get the
problem down to a manageable level, then it's a problem that can be
dealt with package-by-package.

  Haskell packages are not black boxes
    Inheriting - from the imperative world - the idea of packages as
indivisible units may be a mistake. A language like Ruby may have to
import a full library, because it's nearly-impossible to reason about
the behavior of part of it in isolation from the rest of it. Haskell's
not like that, though! Referential transparency gives us awesome
powers to reason about a pure function's behavior in nearly all cases.
    We could define package dependency in terms of providing
functions-that-behave-like-the-ones-we-used.
    I mean, for god's sake, we can write QuickCheck properties like
`quickSort == bubbleSort` and test it with a very high degree of
assurance. The ability to pass the same suite of QuickCheck tests, or
even the ability to pass a test like `fmap-3.1.2 == fmap 3.1.3`, could
be strong enough proof - in the vast majority of cases - of functions'
equivalence and therefore interchangeability. This could ease a
significant number of package version constraints. Call it
Property-Based Versioning - where your packages dependencies are based
on which other versions of the package can provide the same
functionality *for the functions and types that your package uses*.

  Programmer time is precious
    Thus far, the package dependency issue has been more or less a
tug-of-war between package maintainers not wanting to do more work,
and package users not wanting to do more work. Users just want to use
the packages. Maintainers have a potentially-endless list of versions
to check compatibility for ("I'm using foo-2.5.3. I assume anything
2.3 or greater is fine. Should I check through and see if 2.4 works?
2.3? 2.2? [...]"). Not to mention they can't know what the future will
hold for later versions of the dependent packages, and they have to
make a usually-pretty-uneducated guess about the future.

    Instead of maintainers and users, maybe computers should lift some
of the load. Huge swaths of the most-used packages on Hackage are pure
functions and data types. These are relatively easy to reason about,
and if we could come close to reducing our dependency problem by, say,
30-50%, that would in my view put us within striking distance of
having a very smoothly-running package ecosystem.

  These are decisions the community has to make
    There are lots of decisions to make and tradeoffs to balance. The
main reason that I'm presenting such an embryonic description of this
technique is to see what the Haskell community values most.
    In my view the ideal would be to be able to write a dependency
description like "This package needs functions that behave like the
ones I used in foo-3.1.2". A potentially less hair-shirty way to get
some of the same functionality is for package authors to have a
cabal-install or pre-cabal-install tool that determines which
functions and data types are used from a package, finds equivalent
ones in other packages, and write a dependency spec based on its
findings (this wouldn't have anything to say about compatibility of
not-yet-written packages, of course).

Tom
Jonathan Geddes | 2 Aug 2012 07:34
Picon
Gravatar

What Haskell Records Need

Greetings,

tl;dr - What Haskell Records need are
semantic editor combinators for free.

I know this is yet another Record proposal
among many, but none of them out there
strike me as being exactly what I want in
Haskell.

Take the following types from a contrived
example.

>type Salary = Integer
>
>data Job = Job
>  { title  :: String
>  , salary :: Salary
>  }
>
>data Person = Person
>  { name :: String
>  , job  :: Job
>  }

Since I've used record syntax, I get
getter/accessor functions (title, salary,
name, job) for free. Now suppose I want to
create an aggregate getter function: return
the salary of a given person. Piece of cake,
it's just function composition

>getSalary :: Person -> Salary
>getSalary = salary . job

Done! Now suppose I want to write a
setter/mutator function for the same nested
field

>setSalaryMessy :: Salary -> Person -> Person
>setSalaryMessy newSalary person =
>  person {
>    job = (job person) {
>      salary = newSalary
>    }
>  }

Ouch! And that's not even very deeply nested.
Imagine 4 or 5 levels deep. It really makes
Haskell feel clunky next to `a.b.c.d = val`
that you see in other languages. Of course
immutability means that the semantics of
Haskell are quite different (we're creating
new values here, not updating old ones) but
it's still common to model change using these
kinds of updates.

What if along with the free getters that
the compiler generates when we use record
syntax, we also got semantic editor
combinator (SEC) functions[0] that could be
used as follows?

>setSalary newSalary = job' $ salary' (const newSalary)
>
>giveRaise amount = job' $ salary' (+amount)
>
>givePercentRaise percent = job' $ salary' (*(1+percent))

For each field x, the compiler generates a
function x' (the tic is mnemonic for change).
These little functions aren't hard to write,
but they're classic boilerplate.

>job' :: (Job -> Job) -> Person -> Person
>job' f person = person {job = f $ job person}

>salary' :: (Salary -> Salary) -> Job -> Job
>salary' f job = job { salary = f $ salary job}

These type of utility functions are a dream
when working with any reference type or
State Monad.

> modify $ givePercentRaise 0.25

The compiler could also generate polymorphic
SEC functions for polymorphic fields.
Further, the compiler could disallow using
old-style update syntax for fields whose SEC
update function is not in scope, giving us
fine-grained control over access and update.
On the other hand we currently have to create
new functions to achieve this (exporting the
getter means exporting the ability to update
as well, currently).

Of course this doesn't address the
namespacing issues with records, but it is
likely nicely orthogonal to other proposals
which do.

Also note that there's a package on hackage [1]
that will generate SEC functions using TH.
It's nice, but I prefer the style of field
names used above for updaters (field' vs
editField).

Let me know what you think. I'll write up an
official proposal if there's a bit of
general interest around this.

Thanks for reading,

--Jonathan




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
oleg | 2 Aug 2012 08:27

Re: CRIP: the Curiously Reoccuring Instance Pattern


> did you see this, and the discussion around that time?
> http://www.haskell.org/pipermail/haskell-prime/2012-May/003688.html
>
> I implemented hDeleteMany without FunDeps -- and it works in Hugs (using 
> TypeCast -- but looks prettier in GHC with equality constraints).

I'm afraid I didn't see that -- I was on travel during that time.

It is nice that hDeleteMany works on Hugs.  I forgot if we tried it
back in 2004. To be sure some HList code did work on Hugs. We even had
a special subset of HList specifically for Hugs (which I removed from
the distribution some time ago). The problem was that Hugs
inexplicably would fail in some other HList code. Perhaps 2006 version
is better in that respect, and more or all of HList would work on it.

Thank you.

Gmane