[Haskell-cafe] Constructor discipline and dependent types.
Hi, My understanding of the constructor discipline (CD) is that it is a restriction on the form of an equation that guarantees that the equation represents an executable function. The CD restricts the LHS of an equation to consist of a function name, constructors, and variables. Also there should be no new variables on the RHS. So CD permits function to be defined and prohibits general assertions which are more in the domain of a specification language. Question 1: Is the above a reasonable understanding of CD? Question 2: I have read that the lack of dependent types (DT) prevents writing general assertions in Haskell. Is CD related to DT? If so how are they related? Regards, Pat This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] partial inheritance
Hi, Is it possible to model partial inheritance using Haskell type classes? For example, if the class Bird has a flying method can we represent Penguins as a sub-class of Bird without a flying method? Regards, Pat This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial inheritance
On 17 July 2011 11:36, Patrick Browne wrote: > Hi, > Is it possible to model partial inheritance using Haskell type classes? > For example, if the class Bird has a flying method can we represent > Penguins as a sub-class of Bird without a flying method? Possibly with duck typing[1], but that's not vanilla Haskell type classes. FWIW I think you'd have to have: class (Flying a,Wings a,Feathers a,Beak a) => Bird a class (Wings a,Feathers a,Beak a) => Penguin a But I think that's nice anyway. Your functions, IMHO, should ask for only the properties of the object it needs, so: nomOnCorn :: Beak a => a -> Corn -> a nomOnCorn = ... Rather than nomOnCorn :: Bird a => a -> Corn -> a nomOnCorn = ... As there's no need to restrict yourself by having a Bird class, IMHO. I don't think the subclassing/hierarchy concept scales as well as a graph. [1]: http://chrisdone.com/posts/2010-11-22-duck-typing-in-haskell.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial inheritance
Patrick Browne : > For example, if the class Bird has a flying method can we represent Penguins > as a sub-class of Bird without a flying method? The silliest - from the pedagogical perspective - answer to any question, is "you don't need it". But ... in most cases you really don't need it... When instancing your Bird class you may "forget" to define the flying methods. Is this unsuitable for you? The compiler will yell, but this is harmless. Jerzy Karczmarczuk PS. Penguins DO fly. http://www.telegraph.co.uk/news/worldnews/1583517/Flying-penguins-found-by-BBC-programme.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Please take the State of Haskell, 2011 survey
Hi all, I've put together a quick, 12-question State of Haskell, 2011 survey: http://blog.johantibell.com/2011/07/its-time-for-this-years-state-of.html The survey will hopefully give us some insight into how people use Haskell and perhaps also some ideas on how Haskell tools and libraries could be improved. This is the second year I run this survey. New from last year are specific questions on library support and reasoning about run-time performance. P.S. Please direct replies to this email to haskell-cafe@haskell.org. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Contacting Planet Haskell admins
Hi, I just sent an email to the Planet Haskell admins, and it bounced back. Apparently it's still forwarding to Don's old email address. Anyone able to update it? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why aren't files flushed at exit?
If you open a file for writing and then exit with output unflushed, then Haskell does not flush the file for you. In ghci the program seems to work, but then when you compile it in ghc it mysteriously fails. I've just been bitten by this, but when I went to the bug tracker I found http://hackage.haskell.org/trac/ghc/ticket/4119 ticket 4119, which describes this behaviour and was resolved as "invalid". So presumably this behaviour is by design. Given that most environments get this right, why doesn't Haskell? Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why aren't files flushed at exit?
On Sun, Jul 17, 2011 at 10:41 AM, Paul Johnson wrote: > If you open a file for writing and then exit with output unflushed, then > Haskell does not flush the file for you. In ghci the program seems to work, > but then when you compile it in ghc it mysteriously fails. > > I've just been bitten by this, but when I went to the bug tracker I found > http://hackage.haskell.org/trac/ghc/ticket/4119 ticket 4119, which describes > this behaviour and was resolved as "invalid". So presumably this behaviour > is by design. > > Given that most environments get this right, why doesn't Haskell? If you are asking why finalizers are not guaranteed to run, I don't really know the answer for sure. But if you are asking why that bug was marked invalid, then that's because it's good practice anyway to know the lifetime of you handles, specially since they are a scarce resource. If you need a handle for the whole lifetime of your program, use withFile on the main function. If you don't need it for the whole lifetime, then you already should be careful about not leaving it opened. If your program is a long-running process, maybe you should also hFlush at some points to minimize damage on hardware failures and system reboots. Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Constructor discipline and dependent types.
On 17 July 2011 10:03, Patrick Browne wrote: > Question 1: Is the above a reasonable understanding of CD? >From a brief look, constructor discipline (CD) restricts left-hand sides of equations to have no function calls themselves. http://users.dsic.upv.es/~gvidal/german/pepm97/paper.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and Databases
Thanks Greg, both references are very interesting. If I understand correctly, the DSH approach is to convert Haskell programs into SQL and run them inside the database. This seems a good solution when the program objective is to change data in the database according to some business logic or to preprocess relational data to create a non-relational temporary resultset which is later used by an external procedure. The persistent way, from this perspective, appears to be more "conventional" - data are obtained from the database to be processed by an external program and presented on a website, for instance. Similar to Takusen, the main objective here appears to be compile-time guarantees on database types. Indeed, in a functional program, the string-based embedded SQL is the weakest link in the chain. persistent strengthens this link. On 07/01/2011 08:37 PM, Greg Weber wrote: Hi Tobias, Have you seen DSH [1]? You might also be interested in Persistent [2], but it sounds like it has different goals than what you are after. [1] http://hackage.haskell.org/package/DSH [2] http://www.yesodweb.com/book/persistent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contacting Planet Haskell admins
I think it is only partially bouncing - it emails more than one person, from what I remember the last time I emailed. It is an uncomfortable experience, though. Antoine On Jul 17, 2011 7:22 AM, "Michael Snoyman" wrote: > Hi, > > I just sent an email to the Planet Haskell admins, and it bounced > back. Apparently it's still forwarding to Don's old email address. > Anyone able to update it? > > 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
Re: [Haskell-cafe] Contacting Planet Haskell admins
Hi Michael, Don is no longer involved in planet AFAIK. The administrator of planet-haskell is Antti-Juhani Kaijanaho. I'll send you his email address off list. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contacting Planet Haskell admins
Thanks, Antti-Juhani already contacted me. I hadn't realized the planet email address forwards to multiple people. On Sun, Jul 17, 2011 at 6:15 PM, Yitzchak Gale wrote: > Hi Michael, > > Don is no longer involved in planet AFAIK. > > The administrator of planet-haskell is > Antti-Juhani Kaijanaho. I'll send you > his email address off list. > > Regards, > Yitz > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why aren't files flushed at exit?
Quoth Felipe Almeida Lessa , > On Sun, Jul 17, 2011 at 10:41 AM, Paul Johnson wrote: >> If you open a file for writing and then exit with output unflushed, then >> Haskell does not flush the file for you. Â In ghci the program seems to work, >> but then when you compile it in ghc it mysteriously fails. >> >> I've just been bitten by this, but when I went to the bug tracker I found >> http://hackage.haskell.org/trac/ghc/ticket/4119 ticket 4119, which describes >> this behaviour and was resolved as "invalid". Â So presumably this behaviour >> is by design. >> >> Given that most environments get this right, why doesn't Haskell? > > If you are asking why finalizers are not guaranteed to run, I don't > really know the answer for sure. > > But if you are asking why that bug was marked invalid, then that's > because it's good practice anyway to know the lifetime of you handles, > specially since they are a scarce resource. If you need a handle for > the whole lifetime of your program, use withFile on the main function. > If you don't need it for the whole lifetime, then you already should > be careful about not leaving it opened. If your program is a > long-running process, maybe you should also hFlush at some points to > minimize damage on hardware failures and system reboots. The use of withFile on the main function is a good practice in Haskell only because of this defect in the GHC library implementation. There's no question, if there were two competing Haskell library implementations, GHC and one that worked like buffered I/O in other languages, which one would better support Haskell programmers. It's too bad that doesn't qualify it as "valid" bug. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why aren't files flushed at exit?
On Sun, Jul 17, 2011 at 1:40 PM, Donn Cave wrote: > The use of withFile on the main function is a good practice in Haskell > only because of this defect in the GHC library implementation. Well, I've always closed my handles on all languages I've programmed. Actually, now I remember that some students were bitten by the same bug in Pascal. > There's no question, if there were two competing Haskell library > implementations, GHC and one that worked like buffered I/O in other > languages, which one would better support Haskell programmers. > It's too bad that doesn't qualify it as "valid" bug. Having this feature may be nice if you ever forget to close your handles. But if this is a good practice or not is an orthogonal issue. (Actually it is a non-issue because only one of the practices work today =P). Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Network.Html simpleTable fonts
How does one change the font and size of text in a cells in a simpleTable? As in, to change the height, one could state: x = simpleTable [] [height "5"] exampleTable Thanks, Will ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why aren't files flushed at exit?
Is there really no question? I question the assertion, for one. Just because a language allows a bad habit doesn't mean it's a feature. Leaving your handles open can lead to unpredictable results, which is somewhat anathema to the idea of correct programs, unless broken features are part of your spec. Out of curiosity, which languages `get this right', to your way of thinking? On Jul 17, 2011, at 12:40 PM, Donn Cave wrote: > There's no question, if there were two competing Haskell library > implementations, GHC and one that worked like buffered I/O in other > languages, which one would better support Haskell programmers. > It's too bad that doesn't qualify it as "valid" bug. > > Donn > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe Jack Henahan jhena...@uvm.edu == Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra == 398E692F.gpg Description: application/apple-msg-attachment PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why aren't files flushed at exit?
On Sun, Jul 17, 2011 at 18:03, Jack Henahan wrote: > Is there really no question? I question the assertion, for one. Just because > a language allows a bad habit doesn't mean it's a feature. Leaving your > handles open can lead to unpredictable results, which is somewhat anathema to > the idea of correct programs, unless broken features are part of your spec. > > Out of curiosity, which languages `get this right', to your way of thinking? It's not languages; it's system libraries. And system libraries — *not* the programs that use them — that don't clean up after themselves are broken. That kind of thing used to lead to lots of resource leakage in older Windows, for example. This is not to say that programs that rely on it are correct; it *is* to say that, by the exact same reasoning, it is incorrect for runtime libraries to assume that the *programs that use them* are correct. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Html simpleTable fonts
Here's the description of simpleTable: http://hackage.haskell.org/packages/archive/xhtml/3000.2.0.1/doc/html/Text-XHtml-Table.html (note the attribute lists) and here's a working example, for a light at the end of the tunnel: import Network.CGI import Text.XHtml main :: IO () main = runCGI $ handleErrors $ (output . renderHtml) ourTable ourTable = body << simpleTable [cellpadding 30, cellspacing 10, border 2, bordercolor gray] [bgcolor aqua, align "right", align "bottom"] ourTable' ourTable' = map (map lineToHtml) [["J\nJ\nJay y", "Jay", "Jay"], ["Leno", "-Z", "Dilla"]] Tom On Jul 17, 2011 3:34 PM, "william murphy" wrote: > How does one change the font and size of text in a cells in a simpleTable? > As in, to change the height, one could state: > > x = simpleTable [] [height "5"] exampleTable > > Thanks, > > Will ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Html simpleTable fonts
Sorry, forgot the important part:
import Network.CGI
import Text.XHtml
main :: IO ()
main = runCGI $ handleErrors $ (output . renderHtml) ourTable
ourTable = body << ourStyle +++ simpleTable [cellpadding 30,
cellspacing 10, border 2, bordercolor gray] [bgcolor aqua, align
"right", align "bottom"] ourTable'
ourTable' = map (map lineToHtml) [["Jay", "Jay", "Jay"], ["Leno",
"-Z", "Dilla"]]
ourStyle = style (stringToHtml "body { font-size: 50px }") ! [thetype
"text/css"]
On 7/17/11, Tom Murphy wrote:
> Here's the description of simpleTable:
> http://hackage.haskell.org/packages/archive/xhtml/3000.2.0.1/doc/html/Text-XHtml-Table.html
> (note the attribute lists)
>
> and here's a working example, for a light at the end of the tunnel:
>
>
> import Network.CGI
> import Text.XHtml
>
> main :: IO ()
> main = runCGI $ handleErrors $ (output . renderHtml) ourTable
>
> ourTable = body << simpleTable [cellpadding 30, cellspacing 10, border
> 2, bordercolor gray] [bgcolor aqua, align "right", align "bottom"]
> ourTable'
>
> ourTable' = map (map lineToHtml) [["J\nJ\nJay y", "Jay", "Jay"],
> ["Leno", "-Z", "Dilla"]]
>
>
> Tom
>
>
>
> On Jul 17, 2011 3:34 PM, "william murphy" wrote:
>> How does one change the font and size of text in a cells in a
>> simpleTable?
>> As in, to change the height, one could state:
>>
>> x = simpleTable [] [height "5"] exampleTable
>>
>> Thanks,
>>
>> Will
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] derive + quickCheck
Hi, all,
I found derive + quickCheck very useful but I came across some problems.
I used derive to derive instance of Arbitrary immeditaely, but sometimes the
sample is non-terminating, which I mean the result is very very big.
I used
samples <- take 10 <$> sample' in ghci to test the result,
it's non-terminating..
another problem is that $(derive makeArbitrary ''JValue) uses reify, so
I can not see the generated code,
any better way to have a look at the generated code in ghci?
my sample code
{-# LANGUAGE
FlexibleInstances
,MultiParamTypeClasses
,GeneralizedNewtypeDeriving
,FunctionalDependencies
,TypeSynonymInstances
,TemplateHaskell
#-}
module JsonParse where
import Text.ParserCombinators.Parsec
import Text.Parsec.String()
import Control.Applicative hiding ( (<|>) , many, optional )
import Control.Monad
import Test.QuickCheck -- unGen, sample
-- import Language
import Data.DeriveTH
import Data.Binary
import Data.Derive.Arbitrary
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
data JValue = JString String
| JNumber Double
| JBool Bool
| JNull
| JObject [(String, JValue)] --
| JArray [JValue] --
deriving (Eq,Ord,Show)
$(derive makeArbitrary ''JValue)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] derive + quickCheck
On 17 July 2011 23:42, bob zhang wrote: > Hi, all, > I found derive + quickCheck very useful but I came across some problems. > I used derive to derive instance of Arbitrary immeditaely, but sometimes the > sample is non-terminating, which I mean the result is very very big. > > [snip] > > data JValue = JString String > | JNumber Double > | JBool Bool > | JNull > | JObject [(String, JValue)] -- > | JArray [JValue] -- > deriving (Eq,Ord,Show) > $(derive makeArbitrary ''JValue) Your JValue type is recursive; as such I highly suggest you manually create the Arbitrary instances for it (e.g. a helper function with a Bool parameter to indicate whether or not to create recursive calls; see how I do it in http://code.haskell.org/graphviz/Data/GraphViz/Testing/Instances/Canonical.hs where the DotStatements type can have DotSubGraph values, which in turn have DotStatements). -- 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
