[Haskell-cafe] ANN: data-textual: Human-friendly textual representations

[Mikhail Vorozhtsov]

Hello lists,

I'm pleased to announce the first release of data-textual[1], a library 
that provides human-friendly counterparts (called Printable/Textual) of 
the compiler-friendly Show/Read type classes. The library is intended to 
be used for printing and parsing of non-compound and non-polymorphic 
compound data (e.g. numbers, network and hardware addresses, date/time, 
etc).


A quick example (vs network-ip[2] library):

λ> import Data.Maybe (fromJust)
λ> import Data.Textual
λ> import Network.IP.Addr

λ> let x = fromString "[dead::b:e:e:f]:123" :: Maybe Inet6Addr
λ> x
Just (InetAddr {inetHost = ip6FromWords 0xdead 0x0 0x0 0x0 0xb 0xe 0xe 
0xf, inetPort = 123})

λ> toString (fromJust x)
"[dead::b:e:e:f]:123"

λ> let y = fromStringAs aNet4Addr "192.168.100.1/24"
λ> y
Just (netAddr (ip4FromOctets 192 168 100 1) 24)
λ> toText (netPrefix $ fromJust y)
"192.168.100.0"

[1] http://hackage.haskell.org/package/data-textual
[2] http://hackage.haskell.org/package/network-ip

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

Re: [Haskell-cafe] Instances for continuation-based FRP

[Conal Elliott]

Hi Hans,

Do you have a denotation for your representation (a specification for your
implementation)? If so, it will likely guide you to exactly the right type
class instances, via the principle of type class
morphisms(TCMs). If you
don't have a denotation, I wonder how you could decide what
correctness means for any aspect of your implementation.

Good luck, and let me know if you want some help exploring the TCM process,

-- Conal


On Tue, Apr 23, 2013 at 6:22 AM, Hans Höglund  wrote:

> Hi everyone,
>
> I am experimenting with various implementation styles for classical FRP.
> My current thoughts are on a continuation-style push implementation, which
> can be summarized as follows.
>
> > newtype EventT m r a= E { runE :: (a -> m r) -> m r -> m r }
> > newtype ReactiveT m r a = R { runR :: (m a -> m r) -> m r }
> > type Event= EventT IO ()
> > type Reactive = ReactiveT IO ()
>
> The idea is that events allow subscription of handlers, which are
> automatically unsubscribed after the continuation has finished, while
> reactives allow observation of a shared state until the continuation has
> finished.
>
> I managed to write the following Applicative instance
>
> > instance Applicative (ReactiveT m r) where
> > pure a  = R $ \k -> k (pure a)
> > R f <*> R a = R $ \k -> f (\f' -> a (\a' -> k $ f' <*> a'))
>
> But I am stuck on finding a suitable Monad instance. I notice the
> similarity between my types and the ContT monad and have a feeling this
> similarity could be used to clean up my instance code, but am not sure how
> to proceed. Does anyone have an idea, or a pointer to suitable literature.
>
> Best regards,
> Hans
>
> ___
> 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] New releases of crypto-api, DRBG, commsec, commsec-keyexchange, and cipher-aes128

[Thomas DuBuisson]

All,

I have recently released new versions of:

- crypto-api[1]:  An interface for cryptographic algorithms such as
block ciphers, hashes, and secure random number generators.  This
version includes Klondike's cbcMac and SIV modes of operation - much
thanks to his numerous patches.

- DRBG[2]: A set of deterministic random bit generators (aka CPRNGs)
based on NIST 800-90.

- commsec[3]: A communications security package that provides data in
transit security using AES-128 GCM without any external, C library,
dependencies.

- commsec-keyexchange[4]: A key exchange tool that leverages RSA keys
to establish connection's for use with the commsec package.

- cipher-aes128[5]: A re-packaging of Vincent Hanquez's excellent AES routines.

==Crypto API==

Crypto-API was first released in 2010 with an aim of providing an
interface useful to consumers of cryptographic algorithms and
providers of those algorithms.  It includes classes for block, stream,
and asymmetric ciphers as well as for random number generators,
hashes, and signature algorithms.

Recent changes include:
- Added SIV and cbcMac thanks to Klondike.  NOTE: Some of this code is
only conditionally included via a compile time flag due to GHC's slow
compilation of the CPoly module.
- Moved block cipher modes into the type classes, allowing use of
high-speed C or ASM mode implementations.
- More generator query methods in the CryptoRandomGen class.
- Updated build dependencies
- Move operations and expose them from Crypto.Util

==DRBG==

DRBG implements the Hash and HMAC based generators specified in NIST
SP 800-90.  A generator using block ciphers in CTR mode is also
provided, but is not based on the special publication.

==CommSec and CommSec-KeyExchange==

Together, these packages provide a way to start from shared RSA keys
and obtain a thread-safe secure communications channel.  A
pull-request is currently out to crypto-pubkey-openssh that would
allow the reading and use of RSA keys generated by ssh-keygen.

These packages aim to be "morally correct" in that they perform the
correct operations at an equivalent computational cost of a properly
vetted system, but are not themselves vetted for critical use.  For
small messages, commsec performs faster than the non-threadsafe
secure-sockets counterpart.  For larger messages the performance is
not as competitive due to the GCM routine not being fully optimized.

==cipher-aes128==

This package has performance benefits (vs cipher-aes) due to
function-pointer rewriting that allows us to avoid excessive checking
of the CPU info [6].  This package is hopefully going to be
short-lived with the optimizations getting folded into Vincent's
'cipher-aes' once things are mature enough.  A windows tester would
help.


Comments and patches are welcome.  Sorry if I forgot to thank anyone
who contributed, many of these projects have been neglected and I lose
context in the interim.

Cheers,
Thomas M. DuBuisson

[1] http://hackage.haskell.org/package/crypto-api
[2] http://hackage.haskell.org/package/DRBG
[3] http://hackage.haskell.org/package/commsec
[4] http://hackage.haskell.org/package/commsec-keyexchange
[5] http://hackage.haskell.org/package/cipher-aes128
[6] https://github.com/vincenthz/hs-cipher-aes/issues/8 - Up to 40%
faster for small operations.

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

[Haskell-cafe] what happened to alexAndPred?

[Johannes Waldmann]

Hi. I have ghc-7.6.3 and alex-3.0.5.
When I build https://github.com/jwaldmann/smt-lib
it breaks with Language/SMTLIB/Lexer.x:6:5: Not in scope: `alexAndPred'.
It was working with alex-2.3.5.

I was going t add "Can I constrain the alex version in the 
cabal file (I recall this is difficult for executables since
they're not registered with ghc)" but it wouldn't help since
alex-2.3.5 cannot be built with a recent ghc-7.6 
because Module `System.IO.Error' does not export `try'.
Also, not with ghc-7.4.2 because of
dist/build/alex/alex-tmp/Scan.hs:344:17:
Illegal bang-pattern (use -XBangPatterns):
And not with <= ghc-7.2 because of
Linking /tmp/alex-2.3.5-20331/alex-2.3.5/dist/setup/setup ...
unrecognized option `--disable-benchmarks'




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

Re: [Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs

[Alberto G. Corona]

Stephen

The paper is very interesting. We need something like that:

... As a result, the beginning programmer is likely to be discouraged from
pro-gramming in a functional language, and may see the rejection of
programs as a nuisance instead of a blessing. The experienced user might
not look at the messages at all.

*The problem is exacerbated in the case of combinator languages. Combinator
languages are a means of defining domain specific lan-guages embedded within
an existing programming language, using the abstraction facilities present
in the latter. However, since the domain specific extensions are mapped to
constructs present in the underlying language, all type errors are reported
in terms of the host language, and not in terms of concepts from the
combinator library. In addition, the developer of a combinator library may
be aware of various mistakes which users of the library can make, something
which he can explain in the documentation for the library, but which he
cannot make part of the library itself.*
In the meantime maybe we can have a simpler solution like a postprocessing
of errors in some way


2013/4/23 Stephen Tetley 

> Helium - Utrecht University's simplified Haskell - had scriptable
> "Type inference directives" so the creator of an EDSL was able to
> augment the type checker to provide better error messages, see:
>
> Scripting the Type Inference Process
> Bastiaan Heeren Jurriaan Hage S. Doaitse Swierstra
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

[Haskell-cafe] Markdown extension for Haddock as a GSoC project

[Mateusz Kowalczyk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

In light of fairly recent discussion, on this mailing list, I decided
to investigate the topic of Markdown support for Haddock. The archives
of the recent discussion can be seen at [1]. This post aims to
summarise the current state of discussion. I do aim to file a proposal
for a GSoC project on this issue but it'd be foolish to file a
proposal for a project aiming to benefit the community without
consulting the community itself.

Here are some main points and ideas gathered:
* reSt seems to have a small following - quite a bit smaller than the
Markdown community. In fact, there seems to be a significant amount of
people pushing for Markdown which contrasts what we can read in a
topic from 2008 at [2]. I guess it just shows how much Markdown has
gained in popularity in recent years.
* There are issues with using Markdown even before we attempt to use
it for Haskell documentation:
  * There exists no formal specification or semantics. It would seem
that a significant number of Markdown parsers are creating by reverse
engineering an already existing parser. This is bad because we end up
propagating the bugs and workarounds around ambiguity that the
original parser has.
  * As a follow-up to the previous point, the (vanilla) Markdown is
ambiguous and there is nothing to resolve it. As Richard A. O'Keefe
pointed out, there exist situations where it's not possible to infer
the semantics of Markdown from its official implementation and the
result is parser/writer-specific [6].
* John MacFarlane has already written a Markdown parser in Haskell. It
can be read at [3]. This means that the new extension would not need
to rely on Pandoc. He says ``I have an experimental thing here that
could be used as a basis (it's 7x faster than pandoc and uses 1/5 the
memory, BSD licensed)''. This is great! The post can be seen in full
at [4].
* An alternative idea was to simply write a writer module for Pandoc
for Haddock.
  * A reader module is already present.
  * According to John MacFarlane, Haddock is not expressive enough to
take advantage of this. Furthermore, Pandoc doesn't have some
constructions that Haddock does [4].
  * Comes back to the problem on relying on such a large package as
Pandoc.
* Yet another proposal was rather than introducing Markdown to
concentrate on fixing current issues and adding features to Haddock as
it stands [8]. This is one of the options listed at the short blog
post at [14] by Johan Tibell.
  * David Waern, one of Haddock maintainers admits that Haddock lacks
active development and it has been that way for a longer time. Having
said that, he seems to believe that Markdown integration is a project
that can realistically be completed over summer. Such project would be
able to use the existing HTML backend in Haddock. [9].
* Math expressions were requested and MathJAX was suggested as a
solution at [5]. math.stackexchange.com uses MathJAX and it works
quite well. Personally, I believe that Haskell documentation would
benefit from this simply due to the academic nature of the language.
* Support for Literate Haskell would be a welcome addition as
suggested by Andrew Butterfield at [7].
* There are issues with CPP and LHS in regards to using Markdown in
documentation. They are pointed out at [10] by John MacFarlane and
others that he's replying to.
* As pointed out 5 years ago at [11], we'd have to do some
preprocessing on current, fairly critical sections of comments used by
Haddock. I believe these are fairly useful and it would be a shame to
see them go.


I hope I haven't missed anything of high importance in a list above.
When researching the topic, issues with Markdown quickly become
apparent. Today, there are tens of different Markdown flavours: each
company has different needs and each company interprets the vague
original documentation in a way that's convenient to them. In these
situations, topics, e-mails and blog posts like this one happen. There
is a call to action from October 2012 at [12] but there seems to be
absolutely no progress on any of the miraculous things mentioned in
the post. As a result of that post, a W3C community was formed at
[13]. It's clear that the community is inactive and no progress
towards a solution was made.

Having considered all information gathered here, I believe this would
make a good GSoC project. There has been interest in this for Haskell
since 2008 judging by the size of the last thread, it's clear that the
community interest is high. In fact, it surprises me that this hasn't
been done in previous years.

The main issue that I see with using Markdown is the fact that we
can't simply add a {-# HADDOCK Markdown #-} and let some parser rip
through it. There are many issues that need to be resolved that I
outlined above. This will no doubt result in a Markdown flavour suited
to documenting Haskell rather than the wonderful, standardised
Markdown that [13] is talking about. Is this different in 

[Haskell-cafe] ANN: network-simple 0.1.0.1

[Renzo Carbonara]

Since the release of `pipes-network`, I've been encouraged to move the
non-pipes-related TCP utilities to their own package, so I've done
that, and `network-simple` is the result.

This package builds on top of the great `network` package available in
The Haskell Platform, and aims to simplify the usage of some common
networking patterns, such as binding a TCP socket to a port and
immediately start listening and accepting incoming connections to it,
handling each connection in a different thread. Managing the lifetime
of the obtained socket resources is also automated.

Currently, only utilities for dealing with TCP connections are
available, but I look forward to add support for UDP and Unix Domain
Sockets, as well as TLS.

Hackage hasn't rendered the documentation yet, so I uploaded the
documentation here:
http://monoid.k0001.org/haskell/network-simple/doc/index.html

The code can be found at: https://github.com/k0001/network-simple

I've only tried this package on the current Haskell Platform
2012.4.0.0 on Linux, let me know if something does not work in a
different environment.

By the way, `pipes-network-0.1.1.0` now depends on this package.


Regards,

Renzo Carbonara.

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

Re: [Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs

[Stephen Tetley]

Helium - Utrecht University's simplified Haskell - had scriptable
"Type inference directives" so the creator of an EDSL was able to
augment the type checker to provide better error messages, see:

Scripting the Type Inference Process
Bastiaan Heeren Jurriaan Hage S. Doaitse Swierstra

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

Re: [Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs

[Brent Yorgey]

On Tue, Apr 23, 2013 at 12:49:59PM +0200, Alberto G. Corona  wrote:
> Hi
> 
> I ever was worried about the barrier that the complexity of the Haskell
> errors impose to users of DSLs. Many DSLs look so simple that even someone
> without knowledge of Haskell can make use of them for some domains.
> 
> However when the program is compiled then al the monsters of the
> deep appear in the surface: polymorphisms, undefined instances, type errors
> reported in a line produced by a type assumption in another,  etc. This is
> a problem for an industrial use of Haskell in the large scale. For obvious
> reasons.

Indeed.  For example, in my experience this is a big problem for diagrams.

> 
> 
> The question: Is it possible to develop a GHC extension that attach (or
> prepend) such an explanation to the ghc error?
> 
> Or any other alternative that carry out the same functionality.

Surely it is possible.  I have wanted this too.  I guess the majority
of the work would just be in coming up with a good, general design
which is useful but not too difficult to implement.  If anyone wanted
to undertake such a project I would be happy to contribute some ideas.

-Brent

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

Re: [Haskell-cafe] Yi Google summer of code project

[Brent Yorgey]

Generally, for a successful proposal you need to already find someone
who is willing to mentor the project.

Honestly, I do not think working on Yi would make for a very strong
proposal.  It is definitely a cool piece of software, and definitely
worth working on, but it does not have a very large userbase and so
the benefit of this project to the Haskell community would be small.

-Brent

On Mon, Apr 22, 2013 at 02:12:02PM -0400, Gmail wrote:
> Hello again,
> 
> I forgot to ask if I need to find myself a mentor or one will be
> assigned to me by haskell.org?
> 
> Many thanks,
> 
> Bastien
> 
> On 4/21/13 5:57 PM, Bastien Jacot-Guillarmod wrote:
> >Hello,
> >
> >I'm interested in doing some improvments on the Yi editor for my Google
> >summer of code by implementing a completion pop up list for any buffer and a
> >smart completion for haskell.
> >
> >But I don't really know if this kind of project could be acceptable, for the
> >following reason:
> >
> >1) Should a GSoC project be mostly a working experience or also a learning
> >one? I am not the most seasoned haskell programmer, but I really which to
> >dive into a real-life project in this language.
> >
> >2) Is it too long, too small? I don't have too many years of programmation
> >in haskell behind me even if I have done some functionnal programming in
> >other languages (Scala most of the time), hence I don't want to take
> >something that will be overwhelming.
> >
> >3) is Yi associated with haskell.org or it is not possible to have a project
> >on Yi while being mentored by haskell?
> >
> >Thanks for your insight!
> >
> >Regards,
> >Bastien Jacot-Guillarmod, 3rd CS bachelor student at EPFL (Lausanne)
> >
> >
> >
> >
> >--
> >View this message in context: 
> >http://haskell.1045720.n5.nabble.com/Yi-Google-summer-of-code-project-tp5729090.html
> >Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
> >
> >___
> >Haskell-Cafe mailing list
> >Haskell-Cafe@haskell.org
> >http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> ___
> Haskell-Cafe 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] Implementing an embedded language that threads a global structure.

[Ian Bloom]

I'm probably not the best person to answer your questions but here is a try:

I refer to my language as a mini language because I'm only showing lamda,
application and extension. You might choose to add other features like
symbol definitions, fixed points, pattern matching etc. which in the more
extensive versions of my code, I have.

The state monad would essentially be application only, it would not include
the very powerful lambda. I imagine you could implement such a language
using monads but it would just be the same thing, yet more difficult to
read and understand. By implementing the language embedded in Haskell you
can "piggyback" on Haskell's parser and type-checker.

This is the first paper I read about embedded languages. Compiling Embedded
Languages - 
CiteSeerX
You might think of embedded languages as a style or design pattern. It's
purpose is to abstract an entire category of behavior and simplify the task
of a person programming in the embedded language even if they are somehow
limited.

It seems like an embedded language would be a good option.
In the code sample below, if you add a string parameter to LambdaExtension
to include pieces of Perl code and make a version of the instance Pr for
printing perl code into a string you might be well on your way:

module Main (
main,
lam,  app,  ext,
trmA,  trmB,  trmC,  trmD,  trmE,  trmF
) where

data LambdaExtension f = LExtend String f

int_ :: Integer -> LambdaExtension Integer
int_  x = LExtend (show x) x

add_ :: Num a => LambdaExtension (a -> a -> a)
add_= LExtend "+" (+)

mul_ :: Num a => LambdaExtension (a -> a -> a)
mul_= LExtend "*"  (*)

leq_ :: Ord a => LambdaExtension (a -> a -> Bool)
leq_= LExtend "<=" (<=)

not_ :: LambdaExtension (Bool -> Bool)
not_= LExtend "not" not

class Calculus repr where
lam:: String -> (repr gl a -> repr gl b) -> repr gl (a->b)
def:: String -> repr gl a -> repr gl a
app:: repr gl (a->b) -> repr gl a -> repr gl b
fix:: String -> (repr gl a -> repr gl a) -> repr gl a
ext:: LambdaExtension e -> repr gl e

-- R is the evaluator
data R gl t = R t deriving Show
unR (R x) = x

instance Calculus R where
lam _ f = R (\z -> unR (f (R z)))
def _ f = R (unR f)
app e1 e2 = R ( (unR e1) (unR e2) )
fix _ f = R (fx (unR . f. R)) where fx f = f (fx f)
ext(LExtend _ f) = R f

-- Pr is the printer

newtype Pr g a = Pr String
unPr (Pr f) = f

instance Calculus Pr where
lam vN f = Pr(let var = Pr vN
  body = unPr (f var)
  in "\\"++ vN ++"->"++ body)
def dN f = Pr (dN ++ " = " ++ unPr f)
app e1 e2 = Pr(let e1b = unPr e1
   e2b = unPr e2
   in "(" ++ e1b ++ " " ++ e2b ++ ")")
fix vN f = Pr(let var = Pr vN
  body = unPr (f var)
  in "fix\\" ++ vN ++ "->" ++ body)
ext(LExtend s _) = Pr s


app2 f x y = (app (app  f x) y)
app3 f x y z   = (app (app2 f x  y) z)
app4 f x y z w = (app (app3 f x  y  z) w)

-- Sample Terms
trmA = lam "x" (\x -> lam "y" (\y -> app x y))
trmB = lam "y" (\y -> app trmC y)
trmC = lam "c" (\c-> app2 (ext add_) c (ext (int_ 1)))
trmD = (ext (int_ 3))
trmE = app trmC trmD
trmF = app trmC trmE

main = do
   putStrLn "Hello!"
   putStrLn $ show $ unPr (trmA)
   putStrLn $ show $ unPr (trmF)
   putStrLn "**"

Cheers,
Ian


On Tue, Apr 23, 2013 at 11:12 AM, Ian Bloom  wrote:

> I'm probably not the best person to answer your questions but here is a
> try:
>
> I refer to my language as a mini language because I'm only showing lamda,
> application and extension. You might choose to add other features like
> symbol definitions, fixed points, pattern matching etc. which in the more
> extensive versions of my code, I have.
>
> The state monad would essentially be application only, it would not
> include the very powerful lambda. I imagine you could implement such a
> language using monads but it would just be the same thing, yet more
> difficult to read and understand. By implementing the language embedded in
> Haskell you can "piggyback" on Haskell's parser and type-checker.
>
> This is the first paper I read about embedded languages. Compiling
> Embedded Languages - 
> CiteSeerX
> You might think of embedded languages as a sty

Re: [Haskell-cafe] Monad Transformer Space Leak

[Clark Gaebel]

I'm on 7.6.2, and it does. Oh no.

  - Clark

On Tuesday, April 23, 2013, Tom Ellis wrote:

> On Tue, Apr 23, 2013 at 09:36:04AM +0200, Petr Pudlák wrote:
> > I tested it on GHC 6.12.1, which wasn't affected by the recent
> "ackermann"
> > bug, but still it leaks memory.
>
> I tested it on GHC 7.4.1 and I don't see any space leak.
>
> ___
> 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] Instances for continuation-based FRP

[Hans Höglund]

Hi everyone,

I am experimenting with various implementation styles for classical FRP. My 
current thoughts are on a continuation-style push implementation, which can be 
summarized as follows.

> newtype EventT m r a= E { runE :: (a -> m r) -> m r -> m r }
> newtype ReactiveT m r a = R { runR :: (m a -> m r) -> m r }
> type Event= EventT IO ()
> type Reactive = ReactiveT IO ()

The idea is that events allow subscription of handlers, which are automatically 
unsubscribed after the continuation has finished, while reactives allow 
observation of a shared state until the continuation has finished.

I managed to write the following Applicative instance

> instance Applicative (ReactiveT m r) where
> pure a  = R $ \k -> k (pure a)
> R f <*> R a = R $ \k -> f (\f' -> a (\a' -> k $ f' <*> a'))

But I am stuck on finding a suitable Monad instance. I notice the similarity 
between my types and the ContT monad and have a feeling this similarity could 
be used to clean up my instance code, but am not sure how to proceed. Does 
anyone have an idea, or a pointer to suitable literature.

Best regards,
Hans___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Automated Differentiation Type Question

[Dominic Steinitz]

Answering my own question, what I needed was:

testGrad2 :: (Fractional a, Num a) =>
 (forall s . Mode s => [AD s a]) ->
 (forall s . Mode s => [[AD s a]]) ->
 [a] -> [a]
testGrad2 ys xss = grad (costFn ys xss)


On 23 Apr 2013, at 10:44, Dominic Steinitz  wrote:

> Can anyone tell me why I get a type error with testGrad2? What are my 
> options? Clearly I would like to be able find the gradient of my cost 
> function for different sets of observations.
> 
> Thanks, Dominic.
> 
>> {-# LANGUAGE NoMonomorphismRestriction #-}
>> 
>> import Numeric.AD
>> 
>> default()
>> 
>> costFn :: Floating a => [a] -> [[a]] -> [a] -> a
>> costFn ys xss thetas = (/ (2*m)) $ sum $ map (^ (2 :: Int)) $
>>   zipWith (\y xs -> costFnAux y xs thetas) ys xss
>>  where
>>m = fromIntegral $ length xss
>>costFnAux :: Floating a => a -> [a] -> [a] -> a
>>costFnAux y xs thetas = y - head thetas - sum (zipWith (*) xs (tail 
>> thetas))
>> 
>> ys :: Floating a => [a]
>> ys = [1.0, 2.0, 3.0]
>> 
>> xss :: Floating a => [[a]]
>> xss = [[1.0], [2.0], [3.0]]
>> 
>> thetas :: Floating a => [a]
>> thetas = [0.0, 1.0]
>> 
>> test :: Floating a => a
>> test = costFn ys xss thetas
>> 
>> testGrad0 = grad (costFn ys xss)
>> 
>> testGrad1 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>> testGrad1 ys xss = grad (costFn (undefined :: Floating a => [a]) (undefined 
>> :: Floating a => [[a]]))
>> 
>> testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>> testGrad2 ys xss = grad (costFn ys xss)
> 
>> [1 of 1] Compiling Main ( 
>> /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs, interpreted )
>> 
>> /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:33:33:
>>Could not deduce (a ~ ad-3.4:Numeric.AD.Internal.Types.AD s a)
>>from the context (Floating a)
>>  bound by the type signature for
>> testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>>  at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:32:14-53
>>or from (Numeric.AD.Internal.Classes.Mode s)
>>  bound by a type expected by the context:
>> Numeric.AD.Internal.Classes.Mode s =>
>> [ad-3.4:Numeric.AD.Internal.Types.AD s a]
>> -> ad-3.4:Numeric.AD.Internal.Types.AD s a
>>  at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:33:20-39
>>  `a' is a rigid type variable bound by
>>  the type signature for
>>testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>>  at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:32:14
>>Expected type: [ad-3.4:Numeric.AD.Internal.Types.AD s a]
>>  Actual type: [a]
>>In the first argument of `costFn', namely `ys'
>>In the first argument of `grad', namely `(costFn ys xss)'
>>In the expression: grad (costFn ys xss)
>> 
>> /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:33:36:
>>Could not deduce (a ~ ad-3.4:Numeric.AD.Internal.Types.AD s a)
>>from the context (Floating a)
>>  bound by the type signature for
>> testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>>  at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:32:14-53
>>or from (Numeric.AD.Internal.Classes.Mode s)
>>  bound by a type expected by the context:
>> Numeric.AD.Internal.Classes.Mode s =>
>> [ad-3.4:Numeric.AD.Internal.Types.AD s a]
>> -> ad-3.4:Numeric.AD.Internal.Types.AD s a
>>  at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:33:20-39
>>  `a' is a rigid type variable bound by
>>  the type signature for
>>testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>>  at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:32:14
>>Expected type: [[ad-3.4:Numeric.AD.Internal.Types.AD s a]]
>>  Actual type: [[a]]
>>In the second argument of `costFn', namely `xss'
>>In the first argument of `grad', namely `(costFn ys xss)'
>>In the expression: grad (costFn ys xss)
>> Failed, modules loaded: none.
> 
> 


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

[Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs

[Alberto G. Corona]

Hi

I ever was worried about the barrier that the complexity of the Haskell
errors impose to users of DSLs. Many DSLs look so simple that even someone
without knowledge of Haskell can make use of them for some domains.

However when the program is compiled then al the monsters of the
deep appear in the surface: polymorphisms, undefined instances, type errors
reported in a line produced by a type assumption in another,  etc. This is
a problem for an industrial use of Haskell in the large scale. For obvious
reasons.

I would like to know

1) which techniques are used to minimize the problem
2) To suggest some kind of extension that would allow for example to add
extra information to the error messages by the library developer.. For
example, in

http://hackage.haskell.org/packages/archive/control-monad-exception/0.10.3.1/doc/html/Control-Monad-Exception.html

There is a nice documentation about two kind of errors that are frequent
when using that library:


*A type error of the form: *

*No instance for (UncaughtException MyException)
  arising from a use of `g' at examples/docatch.hs:21:32-35
Possible fix:
  add an instance declaration for (UncaughtException MyException)
In the expression: g ()*

*is the type checker saying: *

*"hey, you are trying to run a computation which throws a
MyExceptionwithout handling it, and I won't let you"
*

*Either handle it or declare MyException as an
UncaughtException.
*



The question: Is it possible to develop a GHC extension that attach (or
prepend) such an explanation to the ghc error?



Or any other alternative that carry out the same functionality.


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

[Haskell-cafe] Automated Differentiation Type Question

[Dominic Steinitz]

Can anyone tell me why I get a type error with testGrad2? What are my options? 
Clearly I would like to be able find the gradient of my cost function for 
different sets of observations.

Thanks, Dominic.

> {-# LANGUAGE NoMonomorphismRestriction #-}
> 
> import Numeric.AD
> 
> default()
> 
> costFn :: Floating a => [a] -> [[a]] -> [a] -> a
> costFn ys xss thetas = (/ (2*m)) $ sum $ map (^ (2 :: Int)) $
>zipWith (\y xs -> costFnAux y xs thetas) ys xss
>   where
> m = fromIntegral $ length xss
> costFnAux :: Floating a => a -> [a] -> [a] -> a
> costFnAux y xs thetas = y - head thetas - sum (zipWith (*) xs (tail 
> thetas))
> 
> ys :: Floating a => [a]
> ys = [1.0, 2.0, 3.0]
> 
> xss :: Floating a => [[a]]
> xss = [[1.0], [2.0], [3.0]]
> 
> thetas :: Floating a => [a]
> thetas = [0.0, 1.0]
> 
> test :: Floating a => a
> test = costFn ys xss thetas
> 
> testGrad0 = grad (costFn ys xss)
> 
> testGrad1 :: Floating a => [a] -> [[a]] -> [a] -> [a]
> testGrad1 ys xss = grad (costFn (undefined :: Floating a => [a]) (undefined 
> :: Floating a => [[a]]))
> 
> testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
> testGrad2 ys xss = grad (costFn ys xss)

> [1 of 1] Compiling Main ( 
> /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs, interpreted )
> 
> /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:33:33:
> Could not deduce (a ~ ad-3.4:Numeric.AD.Internal.Types.AD s a)
> from the context (Floating a)
>   bound by the type signature for
>  testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>   at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:32:14-53
> or from (Numeric.AD.Internal.Classes.Mode s)
>   bound by a type expected by the context:
>  Numeric.AD.Internal.Classes.Mode s =>
>  [ad-3.4:Numeric.AD.Internal.Types.AD s a]
>  -> ad-3.4:Numeric.AD.Internal.Types.AD s a
>   at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:33:20-39
>   `a' is a rigid type variable bound by
>   the type signature for
> testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>   at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:32:14
> Expected type: [ad-3.4:Numeric.AD.Internal.Types.AD s a]
>   Actual type: [a]
> In the first argument of `costFn', namely `ys'
> In the first argument of `grad', namely `(costFn ys xss)'
> In the expression: grad (costFn ys xss)
> 
> /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:33:36:
> Could not deduce (a ~ ad-3.4:Numeric.AD.Internal.Types.AD s a)
> from the context (Floating a)
>   bound by the type signature for
>  testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>   at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:32:14-53
> or from (Numeric.AD.Internal.Classes.Mode s)
>   bound by a type expected by the context:
>  Numeric.AD.Internal.Classes.Mode s =>
>  [ad-3.4:Numeric.AD.Internal.Types.AD s a]
>  -> ad-3.4:Numeric.AD.Internal.Types.AD s a
>   at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:33:20-39
>   `a' is a rigid type variable bound by
>   the type signature for
> testGrad2 :: Floating a => [a] -> [[a]] -> [a] -> [a]
>   at /Users/dom/Dropbox/Private/Whales/ADTypePuzzle.hs:32:14
> Expected type: [[ad-3.4:Numeric.AD.Internal.Types.AD s a]]
>   Actual type: [[a]]
> In the second argument of `costFn', namely `xss'
> In the first argument of `grad', namely `(costFn ys xss)'
> In the expression: grad (costFn ys xss)
> Failed, modules loaded: none.



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

[Haskell-cafe] Why are QuasiQuotes allowed in SafeHaskell?

[kudah]

In GHC User's Guide, the reason to disable TemplateHaskell is as
follows:

> TemplateHaskell — Is particularly dangerous, as it can cause side
> effects even at compilation time and can be used to access
> constructors of abstract data types.

Doesn't the same apply to quasi-quotes?

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

Re: [Haskell-cafe] Monad Transformer Space Leak

[Tom Ellis]

On Tue, Apr 23, 2013 at 09:36:04AM +0200, Petr Pudlák wrote:
> I tested it on GHC 6.12.1, which wasn't affected by the recent "ackermann"
> bug, but still it leaks memory.

I tested it on GHC 7.4.1 and I don't see any space leak.

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

Re: [Haskell-cafe] Monad Transformer Space Leak

[Petr Pudlák]

I tested it on GHC 6.12.1, which wasn't affected by the recent "ackermann"
bug, but still it leaks memory.

Petr Pudlak


2013/4/22 Clark Gaebel 

> I don't have a copy of GHC HEAD handy, and don't have the time to set up
> the ecosystem myself to test this one bug.
>
> Would someone else with a copy lying around mind testing it out for me?
>
> Thanks,
>   - Clark
>
> On Monday, April 22, 2013, Joachim Breitner wrote:
>
>> Hi,
>>
>> Am Montag, den 22.04.2013, 16:44 -0400 schrieb Clark Gaebel:
>> > More interestingly, the problem goes away if I enable profiling.
>> > That's kind of worrisome.
>>
>> this part sounds similar than the recently discussed problem with the
>> ackermann function (http://hackage.haskell.org/trac/ghc/ticket/7850) –
>> maybe your code is only allocating stacks and nothing else? In that case
>> you can try with GHC HEAD and see if the problem is fixed.
>>
>> Greetings,
>> Joachim
>>
>>
>> --
>> Joachim "nomeata" Breitner
>> Debian Developer
>>   nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
>>   JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
>>
>>
> ___
> 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