[Haskell-cafe] Unified Haskell login

[Michael Snoyman]

Hi cafe,

Let me preface this by stating that this is purposely a half-baked
idea, a straw man if you will. I'd like to hear what the community
thinks about this.

I mentioned yesterday that I was planning on building haskellers.com.
The first technicality I considered was how login should work. There
are a few basic ideas:

* Username/password on the site. But who wants to deal with *another* password?
* OpenID. Fixes the extra password problem, but doesn't give us any
extra information about the user (email address, etc).
* Facebook/Twitter/Google: We get the users email address, but do we
*really* want to force users to have one of those accounts?

I then started thinking about the Yesod documentation site[1], and
realized in the not-too-distant future I'm going to want to provide a
feature tracker. Once again, I'll need to face the exact same problem.
And then I realized something: I already have *two* Haskell-centric
logins: one for Hackage, and one for the Haskell wiki.

Consolidating our logins as a community could be a huge plus. If we
keep the same kind of system as we have now with Hackage and the wiki,
we can verify each new user to keep things "clean". Or even better: we
could have a built-in permissions system: permissions for uploading to
Hackage, modifying the wiki, feature requests, etc. Users get
simplification of only needing to apply for an account once and only
need to remember one password. (In fact, if we wanted to, we could
bypass the password some of the time by allowing OpenID
authentication.)

But perhaps the biggest advantage would be the community building
advantage. Imagine if you go to Hackage and the upload by field is a
link to someone's Haskellers profile. Imagine going to Haskellers and
seeing a list of all the users uploaded packages and wiki
contributions. We could even start with some clever things like badges
per user. I'm sure there are lots of possibilities out there I haven't
considered.

Obviously there are some technical hurdles to overcome. We would
probably need to do some significant work on the wiki to get this to
happen. But given that we seem to have had trouble with mediawiki in
the past (I remember hearing about some migration issues), maybe it's
time to eat our own dog food and switch to a Haskell-based wiki[2]
that could be more easily modified to suit our needs. We would also
need some kind of protocol for the cross-site authentication; OAuth
2.0 might be worth considering for this.

All of this may just be the ramblings of a mad-man (I haven't had
breakfast yet), but I do think that *some* form of unified login could
really push Haskell forward.

Michael

[1] http://docs.yesodweb.com/
[2] http://hackage.haskell.org/package/gitit
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] IO-oriented cache library for interacting with GUI

[Antoine Latter]

2010/9/16 Alexey Karakulov :
> Hi. I'm writing GUI (gtk) program which purpose is take some data as user
> input, perform some evaluations, and produce some plots and coefficients.
> Since some evaluations take significant time (about 10 seconds), I try to
> cache results. The problem is that dependency structure is quite
> complicated, something like this:
>
>    a* -> x, b*
>    x -> c
>    x, b* -> d
>
> where
>   α -> β means that β depends on α
>   values designated by a,b,c,d can be showed to user by request, and x is
> internal value
>   values designated by letters with asterisk (a*,b*) can be edited by user
>

That sounds a lot like a spreadsheet (like Excel). A person just
released a spreadsheet app writtern in Haskell[1], so there might be
something in it of interest.

Antoine

[1] http://www.haskell.org/pipermail/haskell-cafe/2010-September/083070.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Reachable variables exercise

[Carlos Camarao]

Ah... now I understand your concern; I should have written
something like:

where K  +_t  K'  denotes the set of constraints from K plus
those from K' that have type variables reachable from t.

instead of:

where K  +_t  K'  denotes the constraint-set obtained by adding from K'
only constraints with type variables reachable from t.

Cheers,

Carlos

On Thu, Sep 16, 2010 at 6:56 PM, Luke Palmer  wrote:

> I am not totally sure if I understand your proposal correctly, but if
> I do, then it has a flaw.  Consider:
>
>class Boolable a where
>boolify :: a -> Bool
>
>class O a where
>o :: a
>
> main = print $ boolify o
>
> It seems like under your proposal this should not be a type error.
> But if that is so, then what is its output?
>
> Luke
>
> On Thu, Sep 16, 2010 at 7:31 AM, Carlos Camarao
>  wrote:
> > Hi. Consider for example an expression e0 like:
> >
> >   fst (True,e)
> >
> > where e is any expression.
> >
> > e0 should have type Bool IMHO irrespectively of the type of e. In Haskell
> > this is the case if e's type is monomorphic, or polymorphic, or
> > constrained and there is a default in the current module that removes
> > the constraints. However, e0 is not type-correct if e has a
> > constrained type and the constraints are not subject to
> > defaulting. For example:
> >
> >   class O a where o::a
> >   main = print $ fst(True,o)
> >
> > generates a type error; in GHC:
> >
> >   Ambiguous type variable `a' in the constraint:
> >  `O a' arising from a use of `o' at ...
> > Probable fix: add a type signature that fixes these type variable(s)
> >
> > A solution (that avoids type signatures) can be given as follows.
> >
> > The type of f e, for f of type, say, K=>t'->t and e of type K'=> t'
> > should be:
> >
> >   K  +_t   K' => t  (not K U K' => t)
> >
> > where K  +_t  K'  denotes the constraint-set obtained by adding from K'
> > only constraints with type variables reachable from t.
> >
> > (A type variable is reachable if it appears in the same constraint as
> > either a type variable free in the type, or another reachable type
> > variable.)
> >
> > Comments? Does that need and deserve a proposal?
> >
> > Cheers,
> >
> > Carlos
> >
> > ___
> > 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] Curious why "cabal upgrade parsec" not installing latest version

[Ivan Lazar Miljenovic]

On 17 September 2010 13:52, Ivan Lazar Miljenovic
 wrote:
> Run "ghc-pkg check", and do a "cabal install --reinstall" for all
> packages that it says need to be rebuilt at the bottom.

Actually, I just re-read your post and you seem to have bigger problems...

The cause of the problem: you used "cabal upgrade".  This appears to
have resulted in cabal-install "upgrading" boot libraries, which is a
big no-no.

Probably the easiest way to fix this is to delete your ~/.ghc/
directory (and thus wipe out the libraries you installed with
cabal-install) and re-install the libraries you want.

>
> On 17 September 2010 13:44, Peter Schmitz  wrote:
>> This gets a little hilarious (but better to laugh than cry).
>>
>> Well, I decided to try Parsec version 3 (i.e., 3.1.0) after all, and
>> edited my cabal config to include:
>>
>> preference: parsec >= 3
>>
>> I did not include "base >= 4"; hope that is not a problem.
>>
>> I did "cabal upgrade parsec", which went great.
>>
>> It added the new dirs:
>>
>> ...\cabal\parsec-3.1.0
>> ...\cabal\mtl-1.1.1.0
>> ...\cabal\bytestring-0.9.1.7
>>
>> I recompiled my little parsec demo.hs using various appropriate
>> Text.Parsec modules (instead of Text.ParserCombinators.Parsec), and
>> it worked great. Wonderful!
>>
>> So, I tried to recompile another program I have that uses:
>>
>>> module Main where
>>> import Control.Monad.Trans ( liftIO )
>>> import Data.IORef
>>> import Graphics.UI.Gtk
>>> import Graphics.UI.Gtk.Gdk.GC
>>> import Graphics.UI.Gtk.Gdk.EventM
>>> import Graphics.UI.Gtk.Glade
>>> import List ( delete, nub )
>>
>> For this code (which previously compiled okay):
>>
>>>    on canvas exposeEvent $ do
>>>       -- drawWindow <- eventWindow
>>>       -- region <- eventRegion
>>>       liftIO $ do                    -- <<< this is line 135
>>>       updateCanvas canvas currentPattern pattern2CanvasOffset zoomFactor id
>>>       (w,h) <- widgetGetSize canvas   -- get (width,height) of DrawingArea
>>>       putStrLn $ "DrawingArea redrawn; (width, height) = " ++ show (w,h)
>>>       return True
>>
>> I get:
>>
>>> life.hs:135:6:
>>>     No instance for (Control.Monad.Trans.MonadIO
>>>                        (mtl-1.1.0.2:Control.Monad.Reader.ReaderT
>>>                           (GHC.Ptr.Ptr EExpose) IO))
>>>       arising from a use of `liftIO' at life.hs:135:6-11
>>>     Possible fix:
>>>       add an instance declaration for
>>>       (Control.Monad.Trans.MonadIO
>>>          (mtl-1.1.0.2:Control.Monad.Reader.ReaderT
>>>             (GHC.Ptr.Ptr EExpose) IO))
>>>     In the first argument of `($)', namely `liftIO'
>>>     In the expression:
>>>           liftIO
>>>         $ do { updateCanvas
>>>                  canvas currentPattern pattern2CanvasOffset zoomFactor id;
>>>                (w, h) <- widgetGetSize canvas;
>>>                  putStrLn
>>>                $   "DrawingArea redrawn; (width, height) = " ++ show (w, h);
>>>                return True }
>>>     In the second argument of `($)', namely
>>>         `do { liftIO
>>>             $ do { updateCanvas
>>>                      canvas currentPattern pattern2CanvasOffset zoomFactor 
>>> id;
>>>                    (w, h) <- widgetGetSize canvas;
>>>                     } }'
>>
>>
>> When I did: "ghc --make life.hs  -v", I saw among the output:
>>
>> "hiding package mtl-1.1.0.2 to avoid conflict with later version
>> mtl-1.1.1.0"
>>
>> I guess that the parsec upgrade installed the newer mtl, and I'm
>> wondering if that is what is making life.hs fail to compile. (?)
>>
>> Silly me, I noticed my gtk package was not up to date:
>>
>>> * gtk
>>>     Synopsis: Binding to the Gtk+ graphical user interface library.
>>>     Latest version available: 0.11.2
>>>     Latest version installed: 0.11.0    <<<
>>>     Homepage: http://www.haskell.org/gtk2hs/
>>>     License:  LGPL-2.1
>>
>> So!, thinking it might help, I did: "cabal upgrade gtk" too. (In the
>> past I have successfully done "cabal install gtk", so I thought this
>> would be okay.  :-)  I got:
>>
>>> H:\proc\dev\cmd>cabal upgrade gtk
>>> Resolving dependencies...
>>> Configuring old-time-1.0.0.5...
>>> cabal: The package has a './configure' script. This requires a Unix
>>> compatibility toolchain such as MinGW+MSYS or Cygwin.
>>> Configuring random-1.0.0.2...
>>> Preprocessing library random-1.0.0.2...
>>> Building random-1.0.0.2...
>>> [1 of 1] Compiling System.Random    ( System\Random.hs, 
>>> dist\build\System\Random.o )
>>> Registering random-1.0.0.2...
>>> Installing library in H:\proc\tools\cabal\random-1.0.0.2\ghc-6.12.1
>>> Registering random-1.0.0.2...
>>> cabal: Error: some packages failed to install:
>>> cairo-0.11.1 depends on old-time-1.0.0.5 which failed to install.
>>> directory-1.0.1.2 depends on old-time-1.0.0.5 which failed to install.
>>> gio-0.11.1 depends on old-time-1.0.0.5 which failed to install.
>>> glib-0.11.2 depends on old-time-1.0.0.5 which failed to install.
>>> gtk-0.11.2 depends on old-time-1.0.0.5 which failed to insta

Re: [Haskell-cafe] Curious why "cabal upgrade parsec" not installing latest version

[Ivan Lazar Miljenovic]

Run "ghc-pkg check", and do a "cabal install --reinstall" for all
packages that it says need to be rebuilt at the bottom.

On 17 September 2010 13:44, Peter Schmitz  wrote:
> This gets a little hilarious (but better to laugh than cry).
>
> Well, I decided to try Parsec version 3 (i.e., 3.1.0) after all, and
> edited my cabal config to include:
>
> preference: parsec >= 3
>
> I did not include "base >= 4"; hope that is not a problem.
>
> I did "cabal upgrade parsec", which went great.
>
> It added the new dirs:
>
> ...\cabal\parsec-3.1.0
> ...\cabal\mtl-1.1.1.0
> ...\cabal\bytestring-0.9.1.7
>
> I recompiled my little parsec demo.hs using various appropriate
> Text.Parsec modules (instead of Text.ParserCombinators.Parsec), and
> it worked great. Wonderful!
>
> So, I tried to recompile another program I have that uses:
>
>> module Main where
>> import Control.Monad.Trans ( liftIO )
>> import Data.IORef
>> import Graphics.UI.Gtk
>> import Graphics.UI.Gtk.Gdk.GC
>> import Graphics.UI.Gtk.Gdk.EventM
>> import Graphics.UI.Gtk.Glade
>> import List ( delete, nub )
>
> For this code (which previously compiled okay):
>
>>    on canvas exposeEvent $ do
>>       -- drawWindow <- eventWindow
>>       -- region <- eventRegion
>>       liftIO $ do                    -- <<< this is line 135
>>       updateCanvas canvas currentPattern pattern2CanvasOffset zoomFactor id
>>       (w,h) <- widgetGetSize canvas   -- get (width,height) of DrawingArea
>>       putStrLn $ "DrawingArea redrawn; (width, height) = " ++ show (w,h)
>>       return True
>
> I get:
>
>> life.hs:135:6:
>>     No instance for (Control.Monad.Trans.MonadIO
>>                        (mtl-1.1.0.2:Control.Monad.Reader.ReaderT
>>                           (GHC.Ptr.Ptr EExpose) IO))
>>       arising from a use of `liftIO' at life.hs:135:6-11
>>     Possible fix:
>>       add an instance declaration for
>>       (Control.Monad.Trans.MonadIO
>>          (mtl-1.1.0.2:Control.Monad.Reader.ReaderT
>>             (GHC.Ptr.Ptr EExpose) IO))
>>     In the first argument of `($)', namely `liftIO'
>>     In the expression:
>>           liftIO
>>         $ do { updateCanvas
>>                  canvas currentPattern pattern2CanvasOffset zoomFactor id;
>>                (w, h) <- widgetGetSize canvas;
>>                  putStrLn
>>                $   "DrawingArea redrawn; (width, height) = " ++ show (w, h);
>>                return True }
>>     In the second argument of `($)', namely
>>         `do { liftIO
>>             $ do { updateCanvas
>>                      canvas currentPattern pattern2CanvasOffset zoomFactor 
>> id;
>>                    (w, h) <- widgetGetSize canvas;
>>                     } }'
>
>
> When I did: "ghc --make life.hs  -v", I saw among the output:
>
> "hiding package mtl-1.1.0.2 to avoid conflict with later version
> mtl-1.1.1.0"
>
> I guess that the parsec upgrade installed the newer mtl, and I'm
> wondering if that is what is making life.hs fail to compile. (?)
>
> Silly me, I noticed my gtk package was not up to date:
>
>> * gtk
>>     Synopsis: Binding to the Gtk+ graphical user interface library.
>>     Latest version available: 0.11.2
>>     Latest version installed: 0.11.0    <<<
>>     Homepage: http://www.haskell.org/gtk2hs/
>>     License:  LGPL-2.1
>
> So!, thinking it might help, I did: "cabal upgrade gtk" too. (In the
> past I have successfully done "cabal install gtk", so I thought this
> would be okay.  :-)  I got:
>
>> H:\proc\dev\cmd>cabal upgrade gtk
>> Resolving dependencies...
>> Configuring old-time-1.0.0.5...
>> cabal: The package has a './configure' script. This requires a Unix
>> compatibility toolchain such as MinGW+MSYS or Cygwin.
>> Configuring random-1.0.0.2...
>> Preprocessing library random-1.0.0.2...
>> Building random-1.0.0.2...
>> [1 of 1] Compiling System.Random    ( System\Random.hs, 
>> dist\build\System\Random.o )
>> Registering random-1.0.0.2...
>> Installing library in H:\proc\tools\cabal\random-1.0.0.2\ghc-6.12.1
>> Registering random-1.0.0.2...
>> cabal: Error: some packages failed to install:
>> cairo-0.11.1 depends on old-time-1.0.0.5 which failed to install.
>> directory-1.0.1.2 depends on old-time-1.0.0.5 which failed to install.
>> gio-0.11.1 depends on old-time-1.0.0.5 which failed to install.
>> glib-0.11.2 depends on old-time-1.0.0.5 which failed to install.
>> gtk-0.11.2 depends on old-time-1.0.0.5 which failed to install.
>> haskell98-1.0.1.1 depends on old-time-1.0.0.5 which failed to install.
>> old-time-1.0.0.5 failed during the configure step. The exception was:
>> ExitFailure 1
>> pango-0.11.2 depends on old-time-1.0.0.5 which failed to install.
>> process-1.0.1.3 depends on old-time-1.0.0.5 which failed to install.
>
> (This is where I began laughing instead of crying  :-)
>
> I don't recall ever having problems with old-time in the past.
>
> If anyone has any suggestions, I would appreciate it.
>
> I am willing to either keep parsec 3 and resolve the life.hs compile
> errors, or to reve

Re: [Haskell-cafe] Curious why "cabal upgrade parsec" not installing latest version

[Peter Schmitz]

This gets a little hilarious (but better to laugh than cry).

Well, I decided to try Parsec version 3 (i.e., 3.1.0) after all, and
edited my cabal config to include:

preference: parsec >= 3

I did not include "base >= 4"; hope that is not a problem.

I did "cabal upgrade parsec", which went great.

It added the new dirs:

...\cabal\parsec-3.1.0
...\cabal\mtl-1.1.1.0
...\cabal\bytestring-0.9.1.7

I recompiled my little parsec demo.hs using various appropriate
Text.Parsec modules (instead of Text.ParserCombinators.Parsec), and
it worked great. Wonderful!

So, I tried to recompile another program I have that uses:

> module Main where
> import Control.Monad.Trans ( liftIO )
> import Data.IORef
> import Graphics.UI.Gtk
> import Graphics.UI.Gtk.Gdk.GC
> import Graphics.UI.Gtk.Gdk.EventM
> import Graphics.UI.Gtk.Glade
> import List ( delete, nub )

For this code (which previously compiled okay):

>on canvas exposeEvent $ do
>   -- drawWindow <- eventWindow
>   -- region <- eventRegion
>   liftIO $ do-- <<< this is line 135
>   updateCanvas canvas currentPattern pattern2CanvasOffset zoomFactor id
>   (w,h) <- widgetGetSize canvas   -- get (width,height) of DrawingArea
>   putStrLn $ "DrawingArea redrawn; (width, height) = " ++ show (w,h)
>   return True

I get:

> life.hs:135:6:
> No instance for (Control.Monad.Trans.MonadIO
>(mtl-1.1.0.2:Control.Monad.Reader.ReaderT
>   (GHC.Ptr.Ptr EExpose) IO))
>   arising from a use of `liftIO' at life.hs:135:6-11
> Possible fix:
>   add an instance declaration for
>   (Control.Monad.Trans.MonadIO
>  (mtl-1.1.0.2:Control.Monad.Reader.ReaderT
> (GHC.Ptr.Ptr EExpose) IO))
> In the first argument of `($)', namely `liftIO'
> In the expression:
>   liftIO
> $ do { updateCanvas
>  canvas currentPattern pattern2CanvasOffset zoomFactor id;
>(w, h) <- widgetGetSize canvas;
>  putStrLn
>$   "DrawingArea redrawn; (width, height) = " ++ show (w, h);
>return True }
> In the second argument of `($)', namely
> `do { liftIO
> $ do { updateCanvas
>  canvas currentPattern pattern2CanvasOffset zoomFactor id;
>(w, h) <- widgetGetSize canvas;
> } }'


When I did: "ghc --make life.hs  -v", I saw among the output:

"hiding package mtl-1.1.0.2 to avoid conflict with later version
mtl-1.1.1.0"

I guess that the parsec upgrade installed the newer mtl, and I'm
wondering if that is what is making life.hs fail to compile. (?)

Silly me, I noticed my gtk package was not up to date:

> * gtk
> Synopsis: Binding to the Gtk+ graphical user interface library.
> Latest version available: 0.11.2
> Latest version installed: 0.11.0<<<
> Homepage: http://www.haskell.org/gtk2hs/
> License:  LGPL-2.1

So!, thinking it might help, I did: "cabal upgrade gtk" too. (In the
past I have successfully done "cabal install gtk", so I thought this
would be okay.  :-)  I got:

> H:\proc\dev\cmd>cabal upgrade gtk
> Resolving dependencies...
> Configuring old-time-1.0.0.5...
> cabal: The package has a './configure' script. This requires a Unix
> compatibility toolchain such as MinGW+MSYS or Cygwin.
> Configuring random-1.0.0.2...
> Preprocessing library random-1.0.0.2...
> Building random-1.0.0.2...
> [1 of 1] Compiling System.Random( System\Random.hs, 
> dist\build\System\Random.o )
> Registering random-1.0.0.2...
> Installing library in H:\proc\tools\cabal\random-1.0.0.2\ghc-6.12.1
> Registering random-1.0.0.2...
> cabal: Error: some packages failed to install:
> cairo-0.11.1 depends on old-time-1.0.0.5 which failed to install.
> directory-1.0.1.2 depends on old-time-1.0.0.5 which failed to install.
> gio-0.11.1 depends on old-time-1.0.0.5 which failed to install.
> glib-0.11.2 depends on old-time-1.0.0.5 which failed to install.
> gtk-0.11.2 depends on old-time-1.0.0.5 which failed to install.
> haskell98-1.0.1.1 depends on old-time-1.0.0.5 which failed to install.
> old-time-1.0.0.5 failed during the configure step. The exception was:
> ExitFailure 1
> pango-0.11.2 depends on old-time-1.0.0.5 which failed to install.
> process-1.0.1.3 depends on old-time-1.0.0.5 which failed to install.

(This is where I began laughing instead of crying  :-)

I don't recall ever having problems with old-time in the past.

If anyone has any suggestions, I would appreciate it.

I am willing to either keep parsec 3 and resolve the life.hs compile
errors, or to revert to parsec 2 and somehow undo my package
installation problems. (E.g., is there a
"cabal uninstall " command?)

Thanks again very much.
-- Peter




p.s., trying to compile the parsec 3 demo yields (sorry about the formatting):

H:\proc\dev\AAA\LC>ghc --make demo.hs -v
Glasgow Haskell Compiler, Version 6.12.1, for Haskell 98, sta

Fwd: [Haskell-cafe] Reachable variables exercise

[Carlos Camarao]

-- Forwarded message --
From: Carlos Camarao 
Date: Fri, Sep 17, 2010 at 12:01 AM
Subject: Re: [Haskell-cafe] Reachable variables exercise
To: Luke Palmer 



boolify o has type Boolable a => Bool under the proposal, then
we have ambiguity, type error, right?

In general, consider 'e' as (g:: K=>a -> t) (o:: O a=>a); then the
type of 'e' has constraint (O a) iff 'a' occurs in t.

Let's think about how could 'a' not occur in t. That happens if 'o' is
not needed for computing the result; well, or, as in your example, 'g'
is overloaded and requires the argument to resolve the overloading
('a' occurs in K and does not occur in t), in which case K=>t is
ambiguous.

Cheers,

Carlos



On Thu, Sep 16, 2010 at 6:56 PM, Luke Palmer  wrote:

> I am not totally sure if I understand your proposal correctly, but if
> I do, then it has a flaw.  Consider:
>
>class Boolable a where
>boolify :: a -> Bool
>
>class O a where
>o :: a
>
> main = print $ boolify o
>
> It seems like under your proposal this should not be a type error.
> But if that is so, then what is its output?
>
> Luke
>
> On Thu, Sep 16, 2010 at 7:31 AM, Carlos Camarao
>  wrote:
> > Hi. Consider for example an expression e0 like:
> >
> >   fst (True,e)
> >
> > where e is any expression.
> >
> > e0 should have type Bool IMHO irrespectively of the type of e. In Haskell
> > this is the case if e's type is monomorphic, or polymorphic, or
> > constrained and there is a default in the current module that removes
> > the constraints. However, e0 is not type-correct if e has a
> > constrained type and the constraints are not subject to
> > defaulting. For example:
> >
> >   class O a where o::a
> >   main = print $ fst(True,o)
> >
> > generates a type error; in GHC:
> >
> >   Ambiguous type variable `a' in the constraint:
> >  `O a' arising from a use of `o' at ...
> > Probable fix: add a type signature that fixes these type variable(s)
> >
> > A solution (that avoids type signatures) can be given as follows.
> >
> > The type of f e, for f of type, say, K=>t'->t and e of type K'=> t'
> > should be:
> >
> >   K  +_t   K' => t  (not K U K' => t)
> >
> > where K  +_t  K'  denotes the constraint-set obtained by adding from K'
> > only constraints with type variables reachable from t.
> >
> > (A type variable is reachable if it appears in the same constraint as
> > either a type variable free in the type, or another reachable type
> > variable.)
> >
> > Comments? Does that need and deserve a proposal?
> >
> > Cheers,
> >
> > Carlos
> >
> > ___
> > 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] Idea for hackage feature

[Conrad Parker]

On 17 September 2010 10:12, Ben Millwood  wrote:
> On Fri, Sep 17, 2010 at 1:44 AM, Ivan Lazar Miljenovic
>  wrote:
>> On 17 September 2010 03:18, Henning Thielemann
>>> My suggestion is to move the Unsafe modules to a new package 'unsafe'.
>>> Then you can easily spot all "dirty" packages by looking at reverse
>>> dependencies of 'unsafe'.
>>
>> Hooray, yet another supposedly stand-alone library that GHC will
>> depend on and thus can't be upgraded anyway, so there's no real
>> advantage of making it stand-alone (after all, doesn't base use
>> unsafeInterleaveIO or something for lazy IO?).
>>
>
> Well, it's not like we plan on regularly fiddling that API :)
>
> The clever thing about this suggestion is that most packages don't
> *export* equivalent power to unsafePerformIO even if they import it
> (inlinePerformIO from bytestring is a notable exception) so you can
> easily see from a library's *immediate* dependencies whether it could
> potentially do anything naughty or not. Also, it's implementable
> entirely with existing technology, although we'll probably want a
> major base version bump to remove the modules.

Couldn't that information be discovered by Hackage simply grepping the
sources? Surely if all you want to know is if a package calls
unsafePerformIO directly, that is the simplest way. Grepping would
also find callers of inlinePerformIO, which would be far more useful
than tainting every package that depends on bytestring just because it
might call that function.

Conrad.

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

Re: [Haskell-cafe] Idea for hackage feature

[Ben Millwood]

On Fri, Sep 17, 2010 at 1:44 AM, Ivan Lazar Miljenovic
 wrote:
> On 17 September 2010 03:18, Henning Thielemann
>> My suggestion is to move the Unsafe modules to a new package 'unsafe'.
>> Then you can easily spot all "dirty" packages by looking at reverse
>> dependencies of 'unsafe'.
>
> Hooray, yet another supposedly stand-alone library that GHC will
> depend on and thus can't be upgraded anyway, so there's no real
> advantage of making it stand-alone (after all, doesn't base use
> unsafeInterleaveIO or something for lazy IO?).
>

Well, it's not like we plan on regularly fiddling that API :)

The clever thing about this suggestion is that most packages don't
*export* equivalent power to unsafePerformIO even if they import it
(inlinePerformIO from bytestring is a notable exception) so you can
easily see from a library's *immediate* dependencies whether it could
potentially do anything naughty or not. Also, it's implementable
entirely with existing technology, although we'll probably want a
major base version bump to remove the modules.

When discussing this sort of "taint" I think it's important not to
forget that the FFI can be just as bad. For a start, one common use of
unsafe functions is to provide a pure API to a foreign library (as is
done in RWH), and clearly in such cases the proof of correctness
cannot exist in the language because it depends on properties of
libraries, which may not even be linked until runtime. Secondly, FFI
imports are almost as bad safetywise as System.IO.Unsafe, and twice as
impossible to prove correct. So your taint measure should take into
account use of that extension, too.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Curious why "cabal upgrade parsec" not installing latest version

[Ben Millwood]

On Thu, Sep 16, 2010 at 4:00 AM, Ivan Lazar Miljenovic
 wrote:
> Because Parsec-3 apparently still has some speed regressions compared
> to Parsec-2 (I'm not qualified to note whether its design is slow or
> if you have to use it differently to get good performance out of it),
> so many developers prefer to stick to Parsec-2 for this reason.

I thought Parsec 3.1 had pretty much caught up with the performance of parsec 2?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Idea for hackage feature

[Ivan Lazar Miljenovic]

On 17 September 2010 03:18, Henning Thielemann
 wrote:
> Ivan Lazar Miljenovic schrieb:
>>
>> The problem with this is: unsafe* functions would be better called
>> "yesIGuaranteeThatUsingThisFunctionDoesResultInAReferentiallyTransparentEntityAndItsOKForMeToUseIt*".
>>  They are "unsafe" in that you shouldn't use them blindly.
>
> I think such a long and descriptive name would be helpful, since there
> seem to be many programmers, that do not know, that functions using
> unsafePerformIO must be referentially transparent.

Maybe we need more documentation then?  A better question is "why are
you using unsafePerformIO?" (then again, I know a first year student
that used it to get random numbers out of System.Random for an
assignment - when randomness wasn't needed - because he didn't
understand the explicit passing stuff we do and didn't bother asking).

> My suggestion is to move the Unsafe modules to a new package 'unsafe'.
> Then you can easily spot all "dirty" packages by looking at reverse
> dependencies of 'unsafe'.

Hooray, yet another supposedly stand-alone library that GHC will
depend on and thus can't be upgraded anyway, so there's no real
advantage of making it stand-alone (after all, doesn't base use
unsafeInterleaveIO or something for lazy IO?).

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] IO Put confusion

[Ben Millwood]

On Wed, Sep 15, 2010 at 12:45 AM, Chad Scherrer  wrote:
> Hello,
>
> I need to be able to use strict bytestrings to efficiently build a
> lazy bytestring, so I'm using putByteString in Data.Binary. But I also
> need random numbers, so I'm using mwc-random. I end up in the "IO Put"
> monad, and it's giving me some issues.
>
> To build a random document, I need a random length, and a collection
> of random words. So I have
> docLength :: IO Int
> word :: IO Put
>
> Oh, also
> putSpace :: Put
>
> My first attempt:
> doc :: IO Put
> doc = docLength >>= go
>  where
>  go 1 = word
>  go n = word >> return putSpace >> go (n-1)

I think you misunderstand, here, what return does, or possibly >>.
This function generates docLength random words, but discards all of
them except for the last one. That's what the >> operator does: run
the IO involved in the left action, but discard the result before
running the right action.

The IO action 'return x' doesn't do any IO, so 'return x >> a' does
nothing, discards x, and then does a, i.e.

return x >> a = a

> Unfortunately, with this approach, you end up with a one-word
> document. I think this makes sense because of the monad laws, but I
> haven't checked it.

Yes, the above equation is required to hold for any monad (it is a
consequence of the law that 'return x >>= f = f x')

>
> Second attempt:
> doc :: IO Put
> doc = docLength >>= go
>  where
>  go 1 = word
>  go n = do
>    w <- word
>    ws <- go (n-1)
>    return (w >> putSpace >> ws)
>
> This one actually works, but it holds onto everything in memory
> instead of outputting as it goes. If docLength tends to be large, this
> leads to big problems.

Here you're using the >> from the Put monad, which appends lazy
ByteStrings rather than sequencing IO actions. The problem is that the
ordering of IO is strict, which means that 'doc' must generate all the
random words before it returns, i.e. it must be completely done before
L.writeFile gets a look-in.

It turns out the problem you're trying to solve isn't actually simple
at all. Some of the best approaches to efficient incremental IO are
quite involved - e.g. Iteratees. But your case could be made a great
deal easier if you used a pure PRNG instead of one requiring IO. If
you could make word a pure function, something like word :: StdGen ->
(StdGen, Put) (which is more or less the same as word :: State StdGen
Put), then you'd be able to use it lazily and safely.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Reachable variables exercise

[Luke Palmer]

I am not totally sure if I understand your proposal correctly, but if
I do, then it has a flaw.  Consider:

class Boolable a where
boolify :: a -> Bool

class O a where
o :: a

main = print $ boolify o

It seems like under your proposal this should not be a type error.
But if that is so, then what is its output?

Luke

On Thu, Sep 16, 2010 at 7:31 AM, Carlos Camarao
 wrote:
> Hi. Consider for example an expression e0 like:
>
>   fst (True,e)
>
> where e is any expression.
>
> e0 should have type Bool IMHO irrespectively of the type of e. In Haskell
> this is the case if e's type is monomorphic, or polymorphic, or
> constrained and there is a default in the current module that removes
> the constraints. However, e0 is not type-correct if e has a
> constrained type and the constraints are not subject to
> defaulting. For example:
>
>   class O a where o::a
>   main = print $ fst(True,o)
>
> generates a type error; in GHC:
>
>   Ambiguous type variable `a' in the constraint:
>  `O a' arising from a use of `o' at ...
>     Probable fix: add a type signature that fixes these type variable(s)
>
> A solution (that avoids type signatures) can be given as follows.
>
> The type of f e, for f of type, say, K=>t'->t and e of type K'=> t'
> should be:
>
>   K  +_t   K' => t  (not K U K' => t)
>
> where K  +_t  K'  denotes the constraint-set obtained by adding from K'
> only constraints with type variables reachable from t.
>
> (A type variable is reachable if it appears in the same constraint as
> either a type variable free in the type, or another reachable type
> variable.)
>
> Comments? Does that need and deserve a proposal?
>
> Cheers,
>
> Carlos
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: monte-carlo version 0.3

[Patrick Perry]

monte-carlo is a haskell library providing a monad and associated monad 
transformer for computing with quasi-random numbers.  It provides a high-level 
interface to the distributions supported by the GNU Scientific Library 
(currently just uniform, normal, exponential, Poisson, Levy, but others are 
easy to add).  You can see examples of the library in action at 
http://github.com/patperry/hs-monte-carlo/tree/master/examples/ .   Hackage 
documentation is at http://hackage.haskell.org/package/monte-carlo .

A few blog posts describe an older version of the library, but beware the API 
has changed slightly, and these examples require some modification:

http://ptrckprry.com/blog/2008/08/26/a-monte-carlo-monad-for-haskell/ (see 
examples/Pi.lhs)
http://ptrckprry.com/blog/2008/12/31/monte-carlo-poker-odds/ (see 
examples/Poker.hs)

The changes since the last release are listed below.  I welcome feedback, bug 
reports, and contributions.


Patrick


Changes since version 0.2.

* Add strict versions of sampleSubset, sampleIntSubset, and shuffleInt.

* Port to vector-0.6.0.

* Add Exponential and Levy alpha-Stable distributions.

* Add Summary.Bool for indicators.

* Move Summary to Data.Summary

* Introduce `repeatMC`, which produces an infinite (lazy) stream of values, and
  `replicateMC`, which produces a lazy list of specified length.

* Remove `repeatMC/repeatMCWith`.

* Build fix for 6.8.2 from Robert Gunst.

* The function `sample`, `sampleWithWeights`, `sampleSubset`, and
  `shuffle` no longer require that you explicitly pass in the length.

* The pure RNG is now a newtype, so you can't use the functions from
  GLS.Random.Gen on it anymore.
  
* The internals of the monad have been cleaned up.  IO is used internally
  instead of `seq` calls and `unsafePerformIO` everywhere.  This results in
  a modest performance boost.

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

[Haskell-cafe] Re: Re: Full strict functor by abusing Haskell exceptions

[Ben Franksen]

Sjoerd Visscher wrote:
> But StrictIncl can't be a pointed functor, only endofunctors can be
> pointed.

Could someone tell me what exactly a pointed functor is? I googled but did
not find a definition.

Thanks
Ben

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

Re: [Haskell-cafe] IO-oriented cache library for interacting with GUI

[Vo Minh Thu]

2010/9/16 Evan Laforge :
> 2010/9/16 Alexey Karakulov :
>> Hi. I'm writing GUI (gtk) program which purpose is take some data as user
>> input, perform some evaluations, and produce some plots and coefficients.
>> Since some evaluations take significant time (about 10 seconds), I try to
>> cache results. The problem is that dependency structure is quite
>> complicated, something like this:
>
> You might do a search for "monads for incremental computing".  I
> skimmed the paper, but it didn't really fit my problem so I never
> implemented it.  It sounds like your problem might be a bit closer?

It seems the code from the paper is on hackage:
http://hackage.haskell.org/package/Adaptive

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

[Haskell-cafe] Re: Re: Do expression definition

[Ben Franksen]

wren ng thornton wrote:
> On 9/13/10 6:22 AM, Michael Lazarev wrote:
>> Thanks for examples and pointers.
>>
>> Since I came from Lisp, it never occurred to me that let and lambda
>> are different constructs in Haskell.
>> I thought that
>>  let x = y in f
>> is really
>>  (\x ->  f) y
>> It turns out that let is about declarations which are not the same as
>> function applications above.
> 
> Right. This is a common mistake for people coming from Lisp, Scheme, and
> other untyped lambda calculi. In the untyped world it's fine to conflate
> let and lambda, because they only differ in how they're typed (and if
> you have no types...).
> 
> The difference is that, for let-bindings, once you've figured out a type
> of the variable being bound, then that type can be "generalized". The
> exact process of generalization has some subtle details to watch out
> for, but suffice it to say that certain type variables are allowed to
> become universally quantified. Which means that you're allowed to use x
> at different types within f, provided all those different types are
> consistent with the generalized type.
> 
> Whereas, lambda-bindings don't get generalized, and so they'll always be
> monomorphic (assuming Hindley--Milner inference without extensions like
> -XRankNTypes). This is necessary in order to catch numerous type errors,

Disclaimer: I am not a type system expert. Anyway, I thought the reason was
that type inference for rank-n types (n>1) is undecidable. And therefore:

> though Haskell lets you override this behavior by giving an explicitly
> polymorphic type signature if you have -XRankNTypes enabled.

...so that polymorphic types for arguments don't have to be inferred.

I think it was in Milner's original paper where he tries to give some
intuition why let and lambda are treated differently: even though we always
have

  (\x -> e) y == let x = y in e

which means that let can be translated to lambda, the converse is not true,
since a lambda expression can appear in contexts other than (as the left
hand side of) an application. Thus, let is syntactically more restrictive
than lambda, which means we can be more liberal when typing it. In
principle, the type-checker *could* be extended to infer polymorphic types
for those lambda-bound variables where the lambda expression immediately
gets applied to some other expression. In practice this would be of little
use as these are exactly the situations where a let can (and should!) be
used instead of a lambda.

Cheers
Ben

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

Re: [Haskell-cafe] Web development work

[James Sanders]

I like this idea and would be happy to help if I can.


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

Re: [Haskell-cafe] Re: Curious why " cabal upgrade parsec" not installing latest version

[Jason Dagit]

On Thu, Sep 16, 2010 at 4:48 AM, Johannes Waldmann
 wrote:
> Jason Dagit  codersbase.com> writes:
>
>> preference: base >= 4, parsec >= 3
>
> I am trying this, but ...
>
> Warning: Error parsing config file /home/waldmann/.cabal/config:14:
> Parse of field 'preference' failed (dependency expected): base >= 4, parsec >=
> 3
> Warning: Using default configuration.
>

Sorry about that.  I wasn't sure on the concrete syntax and I should
have said so explicitly.

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

Re: [Haskell-cafe] IO-oriented cache library for interacting with GUI

[Evan Laforge]

2010/9/16 Alexey Karakulov :
> Hi. I'm writing GUI (gtk) program which purpose is take some data as user
> input, perform some evaluations, and produce some plots and coefficients.
> Since some evaluations take significant time (about 10 seconds), I try to
> cache results. The problem is that dependency structure is quite
> complicated, something like this:

You might do a search for "monads for incremental computing".  I
skimmed the paper, but it didn't really fit my problem so I never
implemented it.  It sounds like your problem might be a bit closer?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Memoization/call-by-need

[Román González]

Alex,

Maybe this pdf can enlighten you a little bit about memoization and lazy
evaluation in Haskell =>
http://www.cs.uu.nl/wiki/pub/USCS2010/CourseMaterials/A5-memo-slides-english.pdf

Cheers.

Roman.-


I feel that there is something that I don't understand completely:  I have
> been told that Haskell does not memoize function call, e.g.

> slowFib 50

will run just as slowly each time it is called.  However, I have read that
> Haskell has call-by-need semantics, which were described as "lazy evaluation
> with memoization"


> I understand that

> fib50 = slowFib 50

will take a while to run the first time but be instant each subsequent call;
> does this count as memoization?


> (I'm trying to understand "Purely Functional Data Structures", hence this
question)


-- 

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

Re: [Haskell-cafe] Idea for hackage feature

[Henning Thielemann]

Ivan Lazar Miljenovic schrieb:
> On 16 September 2010 16:04, Mitar  wrote:
>> Hi!
>>
>> I just got an idea for hackage feature. All functions/modules listed
>> there could have some mark if they or any function/module they use
>> uses an unsafe* function. Of course this will make probably almost
>> everything marked as unsafe, but this is the idea - to raise awareness
>> about that so that you can prefer some function/implementation over
>> another.
>> ...
> 
> The problem with this is: unsafe* functions would be better called
> "yesIGuaranteeThatUsingThisFunctionDoesResultInAReferentiallyTransparentEntityAndItsOKForMeToUseIt*".
>  They are "unsafe" in that you shouldn't use them blindly.

I think such a long and descriptive name would be helpful, since there
seem to be many programmers, that do not know, that functions using
unsafePerformIO must be referentially transparent.

My suggestion is to move the Unsafe modules to a new package 'unsafe'.
Then you can easily spot all "dirty" packages by looking at reverse
dependencies of 'unsafe'.

However I see the problem that there are two kinds of uses of
'unsafePerformIO':

1. "Final" usage that turns some IO code into something that looks like
Non-IO and thus must behave this way.
2. "Interim" usage that provides new kinds of unsafe* functions, that
delegates the proof obligation to their users.

Packages that provide functions of type 2 must be treated like the
"unsafe" package, thus complicate the reverse dependency lookup.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Idea for hackage feature

[Simon Michael]

On 9/16/10 9:44 AM, Bas van Dijk wrote:

I try to add NEWS files to my packages source repositories[1] but it
sure would be nice if this file was directly shown on hackage.


Agreed. For now I sometimes put the most recent release notes in the description, like 
http://hackage.haskell.org/package/rss2irc-0.4 .


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

Re: [Haskell-cafe] Idea for hackage feature

[Bas van Dijk]

On Thu, Sep 16, 2010 at 1:43 PM, Ville Tirronen  wrote:
> I'd be happy even if there was a mandatory "whats new" field on packages. I
> see version numbers flashing by but that doesn't really tell me whats
> happening.

See:
http://hackage.haskell.org/trac/hackage/ticket/299
http://hackage.haskell.org/trac/hackage/ticket/244

I try to add NEWS files to my packages source repositories[1] but it
sure would be nice if this file was directly shown on hackage.

Regards,

Bas

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

[Haskell-cafe] IO-oriented cache library for interacting with GUI

[Alexey Karakulov]

Hi. I'm writing GUI (gtk) program which purpose is take some data as user
input, perform some evaluations, and produce some plots and coefficients.
Since some evaluations take significant time (about 10 seconds), I try to
cache results. The problem is that dependency structure is quite
complicated, something like this:

   a* -> x, b*
   x -> c
   x, b* -> d

where
  α -> β means that β depends on α
  values designated by *a*,*b*,*c*,*d* can be showed to user by request, and
*x* is internal value
  values designated by letters with asterisk (*a**,*b**) can be edited by
user

Consider *x*. I have two values:
xCache :: IORef X
xUpToDate :: IORef Bool

Initial state is:
xCache <- newIORef undefined
xUpToDate <- newIORef False

Since *x* is evaluated once, I do
xCache `writeIORef` x
xUpToDate `writeIORef` True

When user changes the value of *a *and saves it, all dependent on *a *values
cache is expired:
xUpToDate `writeIORef` False
(recursively do it with all cache depends on *x*)

When it comes to handling all *a,b,c,d,x *dependencies the code becomes a
mess. I now have something like

import Data.Functor
import Data.IORef
import Control.Monad

data Mutable a = Mutable { ref :: IORef a, onChange :: IO () }

change :: Mutable a -> a -> IO ()
change Mutable {..} a = ref `writeIORef` a >> onChange

data Cache a b = Cache { fn :: a -> b, arg :: IORef a, cached :: IORef
b, upToDate :: IORef Bool }

expire :: Cache a b -> IO ()
expire Cache {..} = upToDate `writeIORef` False

update :: Cache a b -> IO ()
update Cache {..} = do
   utd <- readIORef upToDate
   unless utd $ writeIORef cached =<< fn <$> readIORef arg

test = do
  aRef <- newIORef undefined
  xRef <- newIORef undefined
  xCache <- Cache (^2) aRef xRef <$> newIORef False
  let aMut = Mutable aRef (expire xCache)
  aMut `change` 1
  update xCache
  print =<< readIORef xRef -- 1
  aMut `change` 2
  print =<< readIORef xRef -- still 1
  update xCache
  print =<< readIORef xRef -- now 4

I'd like to know if there is some library that could help me.

(Sorry for my English)
--
All the best,
Alexey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Web development work

[Clint Moore]

On Sep 16, 2010, at 5:35 AM, Michael Snoyman wrote:
> 
> OK, I'll bite on this one. I just registered the domain name
> haskellers.com (I was surprised it was available). So let me ask the
> community what information they would want out there. Here's the ideas
> I had:
> 
> * Users can create their own profiles. Profiles have the following 
> information:
>* Basic name, contact, website, photo, etc.
>* Brief bio
>* Skills. We'll probably have a list of skills to choose from.
>* Notable projects worked on, with strong focus on Hackage packages.
> * Some kind of "web of trust" feature, where users can confirm that
> someone else's profile is accurate. Open to suggestions on this.
> * A public message board for posting job information. I think this
> would not require login to post, but we would have spam protection
> (recaptcha).

This sounds like a lot of fun.  As far as features go, I think by the 
time you implement the features above you'll have a pretty good idea of what 
you would like to see in addition.  I for one would love to see something like 
this.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] benchmarking c/c++ and haskell

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/15/10 06:41 , Daniel Fischer wrote:
> play a role. Since ghc fares pretty well on 64-bit linux (David Terei and 
> Don), both, via the NCG and via C, it seems its 64-bit code generator is 
> better than its 32-bit code generator :(

amd64 has more registers; IIRC ghc needs a *lot* of registers to play with
to perform well (TBH *everything* does), so x86 is always going to be behind
the curve.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkySRUMACgkQIn7hlCsL25XG5QCfWOqBnm/jwFXM9L5cDU33yJiO
JYQAoLnytUMIZ2XHuWKcnin7fEWJk66u
=0FBK
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] A question about "threading" state

[michael rice]

I've been playing around with State Monads. Two I looked at earlier used 
*sequence* and *replicate* but when I came to this one I found myself puzzling 
over how to structure the problem when there was no predetermined count of how 
many times to thread the state.

== Program 1 = 

import Control.Monad
import Control.Monad.State

type GeneratorState = State (Int, Int)

-- lcf (largest common factor)
-- lcf :: (Int, Int) -> ((Int, Int), Int)
lcf (x, y)
  | x == y    = ((x, y), x)
  | x < y = ((y, x), 0)
  | otherwise = ((y, x-y), 0)

lcfstate :: GeneratorState Int
lcfstate = State (\st -> lcf st)

== Some output =

{-
*Main> runState lcfstate (24,18)
(0,(18,6))
*Main> runState lcfstate (18,6)
(0,(6,12))
*Main> runState lcfstate (6,12)
(0,(12,6))
*Main> runState lcfstate (12,6)
(0,(6,6))
*Main> runState lcfstate (6,6)
(6,(6,6))
*Main> runState (sequence $ replicate 5 lcfstate) (24,18)
([0,0,0,0,6],(6,6))
-}

{-
*Main> evalState (sequence $ replicate 2 lcfstate) (24,18)
[0,0]
*Main> evalState (sequence $ replicate 3 lcfstate) (24,18)
[0,0,0]
*Main> evalState (sequence $ replicate 4 lcfstate) (24,18)
[0,0,0,0]
*Main> evalState (sequence $ replicate 5 lcfstate) (24,18)
[0,0,0,0,6]
-}

===

Then I saw the same problem solved here

http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm

== Program 2 =

import Control.Monad
import Control.Monad.ST

newtype StateTrans s a = ST( s -> (s, a) )

instance Monad (StateTrans s)
  where
    -- (>>=) :: StateTrans s a -> (a -> StateTrans s b) -> StateTrans s b
    (ST p) >>= k  =  ST( \s0 -> let (s1, a) = p s0
    (ST q) = k a
    in q s1 )
                        
    -- return :: a -> StateTrans s a
    return a = ST( \s -> (s, a) )

applyST :: StateTrans s a -> s -> (s, a)
applyST (ST p) s = p s

type ImpState = (Int, Int)

getX, getY :: StateTrans ImpState Int
getX = ST(\(x,y)-> ((x,y), x))
getY = ST(\(x,y)-> ((x,y), y))

putX, putY :: Int -> StateTrans ImpState ()
putX x' = ST(\(x,y)->((x',y),()))
putY y' = ST(\(x,y)->((x,y'),()))

gcdST :: StateTrans ImpState Int
gcdST = do x <- getX
   y <- getY
   (if x == y
    then
 return x
    else if x < y
    then 
 do putY (y-x)
    gcdST
    else
 do putX (x-y)
    gcdST)

greatestCommonDivisor x y = snd( applyST gcdST (x,y) )

== Some output =

{-
*Main> greatestCommonDivisor 24 18
6-}



Very impressive. Is this solution typical for problems where the number of 
times the state must be threaded is dependent on the state itself? 

Michael




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

Re: [Haskell-cafe] Web development work

[Don Stewart]

michael:
> On Thu, Sep 16, 2010 at 10:26 AM, Andrew Coppin
>  wrote:
> >  On 16/09/2010 08:52 AM, Michael Snoyman wrote:
> >>
> >> future it would be beneficial to the community to have this
> >> information centralized on a website. I think it would be useful to
> >> have some basic skills and experience information, including system
> >> administration abilities.
> >
> > [..]
> >
> > (And yes, given the frequency with which this gets asked, we should probably
> > write this info down somewhere!)
> >
> 
> OK, I'll bite on this one. I just registered the domain name
> haskellers.com (I was surprised it was available). So let me ask the
> community what information they would want out there. Here's the ideas
> I had:
> 
> * Users can create their own profiles. Profiles have the following 
> information:
> * Basic name, contact, website, photo, etc.
> * Brief bio
> * Skills. We'll probably have a list of skills to choose from.
> * Notable projects worked on, with strong focus on Hackage packages.
> * Some kind of "web of trust" feature, where users can confirm that
> someone else's profile is accurate. Open to suggestions on this.
> * A public message board for posting job information. I think this
> would not require login to post, but we would have spam protection
> (recaptcha).
> 
> And then of course the basic what is Haskell, links to haskell.org,
> etc. I'll probably be able to get started on this early next week.
> 

Does http://cufp.org/jobs solve the same problem? user profiles/job
listings etc.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Web development work

[Daniel Peebles]

Sounds awesome! Why not grab .org too? or was that taken?

On Thu, Sep 16, 2010 at 2:35 PM, Michael Snoyman wrote:

> On Thu, Sep 16, 2010 at 10:26 AM, Andrew Coppin
>  wrote:
> >  On 16/09/2010 08:52 AM, Michael Snoyman wrote:
> >>
> >> future it would be beneficial to the community to have this
> >> information centralized on a website. I think it would be useful to
> >> have some basic skills and experience information, including system
> >> administration abilities.
> >
> > [..]
> >
> > (And yes, given the frequency with which this gets asked, we should
> probably
> > write this info down somewhere!)
> >
>
> OK, I'll bite on this one. I just registered the domain name
> haskellers.com (I was surprised it was available). So let me ask the
> community what information they would want out there. Here's the ideas
> I had:
>
> * Users can create their own profiles. Profiles have the following
> information:
>* Basic name, contact, website, photo, etc.
>* Brief bio
>* Skills. We'll probably have a list of skills to choose from.
>* Notable projects worked on, with strong focus on Hackage packages.
> * Some kind of "web of trust" feature, where users can confirm that
> someone else's profile is accurate. Open to suggestions on this.
> * A public message board for posting job information. I think this
> would not require login to post, but we would have spam protection
> (recaptcha).
>
> And then of course the basic what is Haskell, links to haskell.org,
> etc. I'll probably be able to get started on this early next week.
>
> Michael
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Reachable variables exercise

[Carlos Camarao]

Hi. Consider for example an expression e0 like:

  fst (True,e)

where e is any expression.

e0 should have type Bool IMHO irrespectively of the type of e. In Haskell
this is the case if e's type is monomorphic, or polymorphic, or
constrained and there is a default in the current module that removes
the constraints. However, e0 is not type-correct if e has a
constrained type and the constraints are not subject to
defaulting. For example:

  class O a where o::a
  main = print $ fst(True,o)

generates a type error; in GHC:

  Ambiguous type variable `a' in the constraint:
 `O a' arising from a use of `o' at ...
Probable fix: add a type signature that fixes these type variable(s)

A solution (that avoids type signatures) can be given as follows.

The type of f e, for f of type, say, K=>t'->t and e of type K'=> t'
should be:

  K  +_t   K' => t  (not K U K' => t)

where K  +_t  K'  denotes the constraint-set obtained by adding from K'
only constraints with type variables reachable from t.

(A type variable is reachable if it appears in the same constraint as
either a type variable free in the type, or another reachable type
variable.)

Comments? Does that need and deserve a proposal?

Cheers,

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

Re: [Haskell-cafe] Generating arbitrary functions with QuickCheck?

[Jonas Almström Duregård]

The type (String -> Maybe (a, String)) should already be an instance of
arbitrary if a is.

One way of generating functions is to have some sort of hashing function (a
-> Int). Functions from a to b can be generating by using the hash value to
transform the random seed before the b is generated. Here is a rough outline
for such a system:

genB :: StdGen -> B
hashA :: A -> Int
transformGen :: Int -> StdGen -> StdGen

genFun :: StdGen -> (A -> B)
genFun g a = genB $ transformGen (hashA a) g

In QC you have this instance:

(CoArbitrary
 a, 
Arbitrary
b)
=> 
Arbitrary
(a
-> b)

And CoArbitrary is the class where you implement the trick described above.
Look at the function called variant as well.

/J

On 16 September 2010 02:59, Ivan Lazar Miljenovic  wrote:

> On 16 September 2010 01:58, Thomas Davie  wrote:
> >> Firstly, as far as i can tell, one cannot declare a type synonym to be
> an instance of a type class, thus how would you make it an instance of
> Arbitrary?
> >
> > The standard solution here is to create a newtype, and generate them
> instead.
>
> I've also written and used dedicated generation functions (especially
> for Strings, since I don't want _really_ arbitrary strings since some
> of them might accidentally bring up formatting that my parser can't
> cope with (or will parse as something else).  Note that this is more
> for generating sub-parts of other data types, rather than for types I
> want to be able to run QC tests on.
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Full strict functor by abusing Haskell exceptions

[Sjoerd Visscher]

On Sep 16, 2010, at 6:45 AM, wren ng thornton wrote:

> Given that any functor for adding strictness will have to deal with the same 
> issue of preserving bottom-eating compositions, I postulated that there 
> exists no functor from (all of) Hask to !Hask. But, since !Hask is a 
> subcategory of Hask, it's trivial to go the other direction. In fact, the 
> Strict defined above can be considered as the inclusion functor from !Hask to 
> Hask by making the strictness of !Hask explicit. This also allows Strict to 
> be considered a pointed functor since fmap f . point = point . f for strict 
> functions f.

For fun here's this idea implemented with data-category:

> {-# LANGUAGE TypeFamilies #-}
> 
> import Prelude hiding ((.), id, Functor)
> import Data.Category
> import Data.Category.Functor

The definition of the subcategory of Hask with only strict functions:
> newtype StrictHask a b = StrictHask { unStrictHask :: a -> b }
> 
> instance Category StrictHask where  
>   id _ = StrictHask $ \x -> x `seq` x
>   StrictHask f . StrictHask g = StrictHask $ \x -> f $! g x  

The definition of the inclusion functor:
((%) maps morphisms, i.e. fmap, (:%) maps objects)
> data StrictIncl = StrictIncl
> 
> type instance Dom StrictIncl = StrictHask
> type instance Cod StrictIncl = (->)
> 
> type instance StrictIncl :% a = a
> 
> instance Functor StrictIncl where
>   StrictIncl % (StrictHask f) = f

And indeed we have StrictIncl % (f . g) = StrictIncl % f . StrictIncl % g

But StrictIncl can't be a pointed functor, only endofunctors can be pointed.

--
Sjoerd Visscher
http://w3future.com




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

Re: [Haskell-cafe] Re: Curious why " cabal upgrade parsec" not installing latest version

[Ivan Lazar Miljenovic]

On 16 September 2010 21:48, Johannes Waldmann
 wrote:
> Jason Dagit  codersbase.com> writes:
>
>> preference: base >= 4, parsec >= 3
>
> I am trying this, but ...
>
> Warning: Error parsing config file /home/waldmann/.cabal/config:14:
> Parse of field 'preference' failed (dependency expected): base >= 4, parsec >=
> 3
> Warning: Using default configuration.

Yeah, I managed to work out that to get this to work you just need
multiple preference lines.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Web development work

[Michael Snoyman]

On Thu, Sep 16, 2010 at 10:26 AM, Andrew Coppin
 wrote:
>  On 16/09/2010 08:52 AM, Michael Snoyman wrote:
>>
>> future it would be beneficial to the community to have this
>> information centralized on a website. I think it would be useful to
>> have some basic skills and experience information, including system
>> administration abilities.
>
> [..]
>
> (And yes, given the frequency with which this gets asked, we should probably
> write this info down somewhere!)
>

OK, I'll bite on this one. I just registered the domain name
haskellers.com (I was surprised it was available). So let me ask the
community what information they would want out there. Here's the ideas
I had:

* Users can create their own profiles. Profiles have the following information:
* Basic name, contact, website, photo, etc.
* Brief bio
* Skills. We'll probably have a list of skills to choose from.
* Notable projects worked on, with strong focus on Hackage packages.
* Some kind of "web of trust" feature, where users can confirm that
someone else's profile is accurate. Open to suggestions on this.
* A public message board for posting job information. I think this
would not require login to post, but we would have spam protection
(recaptcha).

And then of course the basic what is Haskell, links to haskell.org,
etc. I'll probably be able to get started on this early next week.

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

[Haskell-cafe] Re: Curious why " cabal upgrade parsec" not installing latest version

[Johannes Waldmann]

Jason Dagit  codersbase.com> writes:

> preference: base >= 4, parsec >= 3

I am trying this, but ...

Warning: Error parsing config file /home/waldmann/.cabal/config:14:
Parse of field 'preference' failed (dependency expected): base >= 4, parsec >=
3
Warning: Using default configuration.

cabal --version
cabal-install version 0.8.2
using version 1.8.0.6 of the Cabal library 


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

Re: [Haskell-cafe] Idea for hackage feature

[Ville Tirronen]

>
> Yeah, those other things were part of the "bigger picture" that I hope
> hackage will get some day: two axes of user rating, plus optional support
> for visualizing things like test coverage and regression tests that you
> include in your cabal file (cabal test was being worked on during one of
> this year's GSOC for example). I was just trying to show what this would get
> us one step closer to :P
>

I'd be happy even if there was a mandatory "whats new" field on packages. I
see version numbers flashing by but that doesn't really tell me whats
happening.

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

Re: [Haskell-cafe] Idea for hackage feature

[Daniel Peebles]

Yeah, those other things were part of the "bigger picture" that I hope
hackage will get some day: two axes of user rating, plus optional support
for visualizing things like test coverage and regression tests that you
include in your cabal file (cabal test was being worked on during one of
this year's GSOC for example). I was just trying to show what this would get
us one step closer to :P

On Thu, Sep 16, 2010 at 11:47 AM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> On 16 September 2010 17:00, Daniel Peebles  wrote:
> > But maybe one day we'll have way more than just "Stability: experimental;
> > Version: 0.0.1" on hackage, but instead:
> > Stability: experimental
> > Version: 0.0.1
> > Test coverage: 98%
> > User stability rating: 86%
> > User API quality rating: 56%
> > Local sources of impurity: none
> > Transitive sources of impurity: bytestring, base
> > Used by: 37 packages [click to see them]
> > But that's just a dream, and the impurity measures seem like a decent
> goal
> > in the mean time :)
>
> Problem is: whilst we might be able to derive the impurity stuff, and
> the usage is done by examing reverse dependencies, I'm not sure how
> you would categorise the stability and quality.  Furthermore, the test
> coverage bit presumably requires developers enable hpc when building
> tests, and if those tests are optional then wouldn't HPC's figures be
> slightly off since the test suite is now included in the amount of
> source you have compared to what most people see?
>
> >
> > Dan
> > On Thu, Sep 16, 2010 at 8:21 AM, Ivan Lazar Miljenovic
> >  wrote:
> >>
> >> On 16 September 2010 16:04, Mitar  wrote:
> >> > Hi!
> >> >
> >> > I just got an idea for hackage feature. All functions/modules listed
> >> > there could have some mark if they or any function/module they use
> >> > uses an unsafe* function. Of course this will make probably almost
> >> > everything marked as unsafe, but this is the idea - to raise awareness
> >> > about that so that you can prefer some function/implementation over
> >> > another.
> >> >
> >> > Of course marking/tagging everything as unsafe is not really useful.
> >> > Because of this I propose that then community votes/vouches on
> >> > correctness/stability of implementations and this would then influence
> >> > the how unsafe given function really is (or is according to community,
> >> > if we are more precise). Of course it would be even better that every
> >> > function using unsafe would have also a formal proof but as we cannot
> >> > believe that we will prove everything in a feasible feature we could
> >> > maybe opt for such "crowd intelligence" approach. We cannot have a
> >> > Turing machine, but maybe we can have crowd. ;-)
> >> >
> >> > (Of course low number of found bugs and good unit test code coverage
> >> > can then positively influence crowd, so authors would be motivated to
> >> > assure that.)
> >> >
> >> > Comments? Opinions?
> >> >
> >> > Because I really hate that I try to keep my code pure and separate IO
> >> > from everything else and then somewhere deep in there some unsafe*
> >> > lurks. (Ah, yes, a side effect of this tagging/marks would be also
> >> > that you would be able to see where all those unsafe* calls are for a
> >> > given function, so you would be able to fast jump (with link) to a
> >> > given line in code and evaluate circumstances in which that unsafe*
> >> > call is made. And then vote/vouch once you discover that it is
> >> > probably pretty safe.)
> >>
> >> The problem with this is: unsafe* functions would be better called
> >>
> >>
> "yesIGuaranteeThatUsingThisFunctionDoesResultInAReferentiallyTransparentEntityAndItsOKForMeToUseIt*".
> >>  They are "unsafe" in that you shouldn't use them blindly.
> >>
> >> Seeing as how lazy IO relies on various unsafe* functions, as do
> >> bytestrings, this means that any program that uses them is
> >> subsequently "tainted".
> >>
> >> A much better idea would be to have some kind of compilation warning
> >> unless you can prove that you're using the unsafe* function in a safe
> >> fashion, but such a proof is unlikely to be easily proven in a
> >> rigorous fashion nor mechanically checkable (and would delay
> >> compilation times).
> >>
> >> --
> >> Ivan Lazar Miljenovic
> >> ivan.miljeno...@gmail.com
> >> IvanMiljenovic.wordpress.com
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
>
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Idea for hackage feature

[Ivan Lazar Miljenovic]

On 16 September 2010 17:00, Daniel Peebles  wrote:
> But maybe one day we'll have way more than just "Stability: experimental;
> Version: 0.0.1" on hackage, but instead:
> Stability: experimental
> Version: 0.0.1
> Test coverage: 98%
> User stability rating: 86%
> User API quality rating: 56%
> Local sources of impurity: none
> Transitive sources of impurity: bytestring, base
> Used by: 37 packages [click to see them]
> But that's just a dream, and the impurity measures seem like a decent goal
> in the mean time :)

Problem is: whilst we might be able to derive the impurity stuff, and
the usage is done by examing reverse dependencies, I'm not sure how
you would categorise the stability and quality.  Furthermore, the test
coverage bit presumably requires developers enable hpc when building
tests, and if those tests are optional then wouldn't HPC's figures be
slightly off since the test suite is now included in the amount of
source you have compared to what most people see?

>
> Dan
> On Thu, Sep 16, 2010 at 8:21 AM, Ivan Lazar Miljenovic
>  wrote:
>>
>> On 16 September 2010 16:04, Mitar  wrote:
>> > Hi!
>> >
>> > I just got an idea for hackage feature. All functions/modules listed
>> > there could have some mark if they or any function/module they use
>> > uses an unsafe* function. Of course this will make probably almost
>> > everything marked as unsafe, but this is the idea - to raise awareness
>> > about that so that you can prefer some function/implementation over
>> > another.
>> >
>> > Of course marking/tagging everything as unsafe is not really useful.
>> > Because of this I propose that then community votes/vouches on
>> > correctness/stability of implementations and this would then influence
>> > the how unsafe given function really is (or is according to community,
>> > if we are more precise). Of course it would be even better that every
>> > function using unsafe would have also a formal proof but as we cannot
>> > believe that we will prove everything in a feasible feature we could
>> > maybe opt for such "crowd intelligence" approach. We cannot have a
>> > Turing machine, but maybe we can have crowd. ;-)
>> >
>> > (Of course low number of found bugs and good unit test code coverage
>> > can then positively influence crowd, so authors would be motivated to
>> > assure that.)
>> >
>> > Comments? Opinions?
>> >
>> > Because I really hate that I try to keep my code pure and separate IO
>> > from everything else and then somewhere deep in there some unsafe*
>> > lurks. (Ah, yes, a side effect of this tagging/marks would be also
>> > that you would be able to see where all those unsafe* calls are for a
>> > given function, so you would be able to fast jump (with link) to a
>> > given line in code and evaluate circumstances in which that unsafe*
>> > call is made. And then vote/vouch once you discover that it is
>> > probably pretty safe.)
>>
>> The problem with this is: unsafe* functions would be better called
>>
>> "yesIGuaranteeThatUsingThisFunctionDoesResultInAReferentiallyTransparentEntityAndItsOKForMeToUseIt*".
>>  They are "unsafe" in that you shouldn't use them blindly.
>>
>> Seeing as how lazy IO relies on various unsafe* functions, as do
>> bytestrings, this means that any program that uses them is
>> subsequently "tainted".
>>
>> A much better idea would be to have some kind of compilation warning
>> unless you can prove that you're using the unsafe* function in a safe
>> fashion, but such a proof is unlikely to be easily proven in a
>> rigorous fashion nor mechanically checkable (and would delay
>> compilation times).
>>
>> --
>> Ivan Lazar Miljenovic
>> ivan.miljeno...@gmail.com
>> IvanMiljenovic.wordpress.com
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Web development work

[Andrew Coppin]

 On 16/09/2010 08:52 AM, Michael Snoyman wrote:

Hi all,

Often times when trying to pitch Haskell to potential clients the
concern is the lack of qualified developers willing to take on
projects. As I'm sure many of you are familiar with, clients prefer
not to be locked in to a single programmer: an errant bus can
significantly reduce the value of their investment.

So I'd like to get an idea of how many people out there would be
interested in Haskell web development work. For the moment I'm just
interested in doing this informally via email, though perhaps in the
future it would be beneficial to the community to have this
information centralized on a website. I think it would be useful to
have some basic skills and experience information, including system
administration abilities.


You'd be surprised at the frequency with which emails almost exactly 
like this one pop up. Everybody thinks that since Haskell is such an 
obscure and unheard of language, it will be impossible to recruit 
programmers. Usually at this point Don or Duncan or somebody pops up and 
points out that as soon as they send an email to Haskell-cafe about a 
potential job opening, they get utterly swamped with enquiries.


I don't know about web development specifically, but there are *plenty* 
of Haskell programmers out here, and it's not difficult to contact them 
either. Finding the "good" onces might be somewhat harder, but there are 
plenty of people to chose from.


(And yes, given the frequency with which this gets asked, we should 
probably write this info down somewhere!)


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

Re: [Haskell-cafe] Memoization/call-by-need

[Ketil Malde]

Alex Rozenshteyn  writes:

> I understand that

>> fib50 = slowFib 50

> will take a while to run the first time but be instant each subsequent call;
> does this count as memoization?

I didn't see anybody else answering this in so many words, but I'd say
no, since you only name one particular value.  Memoization of slowFib
would mean to provide a replacement for the *function* that remembers
previous answers.

Try e.g. these in GHCi (import (i.e. :m +) Data.Array for memoFib):

  slowFib 0 = 1; slowFib 1 = 1; slowFib x = slowFib (x-1) + slowFib (x-2)
  memoFib x = a!x where a = listArray (0,n) (1:1:[ a!(x-1)+a!(x-2) | 
x<-[2..99]])

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Web development work

[Michael Snoyman]

Hi all,

Often times when trying to pitch Haskell to potential clients the
concern is the lack of qualified developers willing to take on
projects. As I'm sure many of you are familiar with, clients prefer
not to be locked in to a single programmer: an errant bus can
significantly reduce the value of their investment.

So I'd like to get an idea of how many people out there would be
interested in Haskell web development work. For the moment I'm just
interested in doing this informally via email, though perhaps in the
future it would be beneficial to the community to have this
information centralized on a website. I think it would be useful to
have some basic skills and experience information, including system
administration abilities.

I might also have one or two Yesod projects that I'll need to pass off
in the future, though it's still unclear if this will happen. If
you're interested in that, please let me know, I can give some more
details privately.

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

Re: [Haskell-cafe] Idea for hackage feature

[Daniel Peebles]

As we were discussing in #haskell, it would have to be more involved than
just a taint bit. A listing showing the "taint sources" of a given package
would give you confidence in its good behavior.

For example, if my nice, pure package's taint list showed that my only taint
sources were through my dependencies on base and bytestring, people could
trust my program not to launch missiles behind their backs. This would
essentially involve traversing transitive dependencies and looking for any
module that imports one of the unsafe modules and uses any function from
them (including GHC.Prim). This seems like it could be done fairly
efficiently, if you just try to do it on the module or package level. At the
function level, it would be a lot more computationally intensive, but would
be more or less the same idea.

I like the idea, but I don't think any formal proof of unsafeness is
feasible. We already can't prove arbitrary properties about even our pure
code, and proving stuff about impure code would require modeling the outside
world and proving your code safe under that model. Anyone reading the proof
would have to accept your model of the outside world as well as verifying
your proof.

But maybe one day we'll have way more than just "Stability: experimental;
Version: 0.0.1" on hackage, but instead:

Stability: experimental
Version: 0.0.1
Test coverage: 98%
User stability rating: 86%
User API quality rating: 56%
Local sources of impurity: none
Transitive sources of impurity: bytestring, base
Used by: 37 packages [click to see them]

But that's just a dream, and the impurity measures seem like a decent goal
in the mean time :)

Dan

On Thu, Sep 16, 2010 at 8:21 AM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> On 16 September 2010 16:04, Mitar  wrote:
> > Hi!
> >
> > I just got an idea for hackage feature. All functions/modules listed
> > there could have some mark if they or any function/module they use
> > uses an unsafe* function. Of course this will make probably almost
> > everything marked as unsafe, but this is the idea - to raise awareness
> > about that so that you can prefer some function/implementation over
> > another.
> >
> > Of course marking/tagging everything as unsafe is not really useful.
> > Because of this I propose that then community votes/vouches on
> > correctness/stability of implementations and this would then influence
> > the how unsafe given function really is (or is according to community,
> > if we are more precise). Of course it would be even better that every
> > function using unsafe would have also a formal proof but as we cannot
> > believe that we will prove everything in a feasible feature we could
> > maybe opt for such "crowd intelligence" approach. We cannot have a
> > Turing machine, but maybe we can have crowd. ;-)
> >
> > (Of course low number of found bugs and good unit test code coverage
> > can then positively influence crowd, so authors would be motivated to
> > assure that.)
> >
> > Comments? Opinions?
> >
> > Because I really hate that I try to keep my code pure and separate IO
> > from everything else and then somewhere deep in there some unsafe*
> > lurks. (Ah, yes, a side effect of this tagging/marks would be also
> > that you would be able to see where all those unsafe* calls are for a
> > given function, so you would be able to fast jump (with link) to a
> > given line in code and evaluate circumstances in which that unsafe*
> > call is made. And then vote/vouch once you discover that it is
> > probably pretty safe.)
>
> The problem with this is: unsafe* functions would be better called
>
> "yesIGuaranteeThatUsingThisFunctionDoesResultInAReferentiallyTransparentEntityAndItsOKForMeToUseIt*".
>  They are "unsafe" in that you shouldn't use them blindly.
>
> Seeing as how lazy IO relies on various unsafe* functions, as do
> bytestrings, this means that any program that uses them is
> subsequently "tainted".
>
> A much better idea would be to have some kind of compilation warning
> unless you can prove that you're using the unsafe* function in a safe
> fashion, but such a proof is unlikely to be easily proven in a
> rigorous fashion nor mechanically checkable (and would delay
> compilation times).
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe