- Haskell-Cafe - Haskell.org

cabal update : getHostByName
by minh thu 01 Sep '08

01 Sep '08

Hi, I've followed the instruction from the upcoming book Real World Haskell to install cabal. Now, when I enter "cabal update", it answers this: Downloading package list from server 'http://hackage.haskell.org/packages/archive' cabal: getHostByName: does not exist (no such host entry) What's the problem ? Thanks a lot, Thu

3 4

Types in bounds
by Brettschneider, Matthias 01 Sep '08

01 Sep '08

Hey there, i was just thinking about types in Haskell and I asked myself, Is there a mechanism, that allows me to define a new type out of an existing one with some restrictions? So that the new type is a subset of the existing one. Lets imagine I want a type for a point like: type Point = (Int, Int) But what, if I can predict that the X and Y values are in a range between 0 and 100? If someone defines a new point like: p :: Point p = (200, 400) that is totally fine with the type definition above, but not correct in my context. Is it possible, to put this information into the type? So that the compiler is able to recognize my mistake? -- Matthias

3 3

Re: [Haskell-cafe] Re: Research language vs. professional language
by Sean Leather 01 Sep '08

01 Sep '08

> >> > This concept of `day-to-day work' is a curious one. Haskell is not a > >> > mature language, and probably shouldn't ever be one. > >> > >> I see where you are coming from here, but I think that train has > >> already started and can't be stopped. > > > > Yeah, it's too late. Too many people have their pay checks riding on > > GHC, the Hackage library set (now up to 740 libraries and tools!), and > > the continued development of the language in general. > > > > If Haskell's not "mature" yet, then perhaps it has reached its early > > twenties, with an reliable heavy duty optimizing compiler, fast runtime, > > large library set, standard documentation, testing, debugging and > > packaging tools, and large community. > > > > We're serious about this thing. > > So, what fills its shoes as a great research language with great tools? > I think the great thing about Haskell is that it works so well now and yet there's room for growth as well. That means that not only is research with the language more efficient, but also that the research tends to be more applicative to people using it. Consider, for example, the fact that the Haskell Workshop has grown into a symposium [1] and that there are so many relevant workshops affiliated with ICFP [2]. [1] http://www.haskell.org/haskell-symposium/ [2] http://www.icfpconference.org/#Affiliated Sean

1 0

Re: [Haskell-cafe] language proposal: ad-hoc overloading
by Philippa Cowderoy 01 Sep '08

01 Sep '08

Oops, forgot to send to list. On Mon, 2008-09-01 at 01:27 +0100, Philippa Cowderoy wrote: > On Mon, 2008-09-01 at 01:11 +0100, David House wrote: > > 2008/8/31 Ryan Ingram <ryani.spam(a)gmail.com>: > > > My proposal is to allow "ad-hoc" overloading of names; if a name is > > > ambiguous in a scope, attempt to type-check the expression against > > > each name. It is only an error if type-checking against all names > > > fails. If type-checking succeeds for more than one then the > > > expression is ambiguous and this is also an error. > > > > -1, at least for now. > > > > Haskell already has one method of overloading: type classes. What you > > propose is a seemingly innocent extension that I now doubt has > > extremely far-reaching consequences into the language. Such a feature > > should be properly researched before it is added to the language. > > Here's an example of such a concern: you write the following: > > > > import Data.Map > > foo = map > > > > What is the type of `foo'? > > If I've understood the proposal, that wouldn't check unless foo was used > in a way (within the module) that makes it clear which of Prelude.map or > Data.Map.map to use and uses it consistently. So if that's the entire > module, it wouldn't check. > > I'm still not keen, but in a sense the idea here is to avoid this > variety of overloading leaking into the type system itself: it could be > implemented (extremely naively) as "typecheck with each possible > permutation for resolving the overloading, use any unique solution or > fail if there isn't one". -- Philippa Cowderoy <flippa(a)flippac.org>

2 1

ANN: wavconvert 0.1.1
by Tim Chevalier 31 Aug '08

31 Aug '08

Hi all, I uploaded to Hackage a little program I wrote to organize my music file collection in the hopes that someone else might find it useful too: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wavconvert I had a directory tree full of .wav files that I ripped from CDs at times when I didn't want to wait for an .mp3 or .ogg encoder to run. The trouble is that .wav files don't have metadata (ID3 tags) that specify artist, album and track names. So, wavconvert takes a directory tree as an argument, and converts any .wav files in it to .ogg (using an external OGG encoder) while filling in the ID3 tags based on the directory names. The name is a bit misleading, since this is not an OGG encoder written in Haskell; it just handles invoking an existing encoder with the right flags to set the metadata. I'd welcome any patches to make this more generally useful (as it is, it assumes a particular file structure and OGG encoder.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Research is what I'm doing when I don't know what I'm doing."--Wernher von Braun

18 35

Re: [Haskell] Compiler Construction course using Haskell?
by Krasimir Angelov 31 Aug '08

31 Aug '08

Hi Johannes, There is a similar course in Chalmers. The home page is here: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/progs/current/ There students were required to implement full parser, partial typechecker and partial interpreter for C++ in either C++, Java or Haskell. We used BNFC for the parser: http://www.cs.chalmers.se/Cs/Research/Language-technology/BNFC/ which was easier for most students I think. In any way I would recomend Happy+Alex or BNFC instead of Parsec but this is only my personal preference. Best Regards, Krasimir 2008/8/20 Johannes Waldmann <waldmann(a)imn.htwk-leipzig.de>: > Hello. > > I plan to give a course in compiler construction, > using Haskell as the implementation language > (not as source or target language). > > Something along these lines: > 1. combinator parsers (Parsec), > 2. simple interpreter (arithmetical expressions) > 3. add algebraic data types, functions > 4. type checker > 5. code generator. > Ideally, 2..5 would be using the very same tree traversal code > and just change the monad for evaluation. > > Any comments appreciated. Have you given such a course? Taken? > > If I really decide to do it, > then slides (in German) will be made available. > > Best regards, J.W. > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > >

5 4

Re: [Haskell-cafe] Re: [Haskell] Top Level <-
by Adrian Hey 31 Aug '08

31 Aug '08

Ganesh Sittampalam wrote: > On Sun, 31 Aug 2008, Adrian Hey wrote: > >> Thanks for taking the time to do this Dan. I think the safety >> requirement has been met, but I think it fails on the improved API. >> The main complaint would be what I see as loss of modularity, in that >> somehow what should be a small irrelevant detail of the implementation >> of some obscure module somewhere has propogated it's way all the way >> upto main. > > That's the key point, as I see it - they aren't "irrelevant details of > the implementation", they are requirements the implementation places on > its context in order for that implementation to be correct. So they > should be communicated appropriately. Eh? Please illustrate your point with Data.Unique. What requirements does it place on it's context? (whatever that might mean :-) It just does what it says on the tin AFAICS. There are no requirements it places on "clients" (to use an OO term), as should any halfway decent API IMO. >> To me this seems completely at odds with what I thought was generally >> accepted wisdom of how to write good maintainable, modular software. >> Namely hiding as much implemention detail possible and keeping APIs >> as simple and stable as they can be. I don't know if I'm alone in >> that view nowadays. > > It's no problem to hide implementation detail, but I don't think you > should hide the *requirement* of the implementation that it has > constraints on how it is called, namely that it requires once-only > initialisation or whatever. No decent API should require this. Data.Unique certainly doesn't. In fact is debatable whether any API should requre an initalisation call at all before other stuff should be called (the other stuff check initialisation has occured and do it itself if necessary). The real irony of your remark is that making APIs this robust is practically impossible *without* using global variables, and you're now saying that because they've done this work to eliminate these constraints they now have to be held to account for this with an absurd API. Seems like a clear case of "no good deed going unpunished" :-) Regards -- Adrian Hey

1 0

Calling Lockheed, Indra, Thales, Raytheon
by Paul Johnson 31 Aug '08

31 Aug '08

This is a strange question, I know, but is there anyone working in any of the above companies on this mailing list? Everyone will no doubt be wondering what they have in common. I'm afraid I can't discuss that. Paul.

6 6

idea: TH calculating type level function results / binary types?
by Marc Weber 31 Aug '08

31 Aug '08

Hi, Maybe you've noted that I've started writing an XML library which validates the generated XML against a given DTD at compile time. Not everything is implemented right now and it would be quite usable if it didn't take that much time. The problem: To see some details have look at my small announcement on haskellcafe. type checking 12 lines of XML code has taken > 3hourse using some TypeToNat type equality comparison > 35sec using an implementation proposed by Oleg > 30sec no longer using HLists to check wether an attribute may be added but an AttrOk tag attr class (proposed by Oleg) > ?sec after finishing a state transformation implementation propably generating thausands of intermediate state or a mixture of this and the parser like apporach. Even if the last approach works it's a pity because: * it took much time to write * hard to read code * no error messages.. In the 30sec apprach I've used some instances such as class Consume elType state state' | elType state -> state' class FailHelper state' state'' | state' -> state'' instance FailHelper (Fail a) => FailHelper (F a) () -- F indicating sub element could not be consumed, failure instance FailHelper a a -- So I got error messages telling me no instance for MoreElementsExpected (Or (E Html_T) (E Body_T)) or such.. that's nice and usable. I can't think of a nice way reporting errors when transforming a dtd line (a,b,c) (= tag sequence a b c) into data State1 data State2 data State3 instance Conseme State1 A_T State2 -- consume tag a instance Conseme State2 B_T State3 -- consume tag b instance Conseme State3 C_T ConsumedEnd -- consume tag c in a convinient way without adding much bloat. The XHMTL spec has about 150 ! tags.. So even if creating this kind of state transforming instances this will result in a lot of bloat. So if the compiler has to load a some MB large .hi file it will spend unnecessary time just loading them. an idea: (new?) solution: What about enhancing ghc so that a) you can define type level functions and calculate the result using template haskell functions: benefits: * speed (it can even be compiled! ) * nice error messages on failure * mantainable code * reusing known source (such as parser combinator libraries) syntax could look like this: class Bar a b c d | a b -> c, a b -> d instance (Maybe x) z $(calculateC) $(calculateD) calculateC :: Type -> Type -> Type calculateD :: Type -> Type -> Type an efficient implementation for TypeEq a b typebool | a b -> typebool could be done by everyone with ease without reading HList source or Olegs papers.. (you should do so anyway ..) b) add some binary serialization support so that you don't have to do expensive data -> type level -> data (de)serializations. .hi files wouldn't blow much this way as well. So a parse specification such as (1) could really be included within types and could become even more complex. Than an exisiting parser combinator library could be used and a validating XML library could be written within some hours.. I think ghc is already a superiour compiler because it allows such advanced technics thereby making users such as me even ask for more :-) I consider this a good sign. So has anyone thought about this before? Would someone help / guide me implementing this extension in the near future? Of course it will clash with some instance -X extensions.. but I think that in everyday use you'd probably use either this template haskell approach or use normal class instance declarations so it I guess it could be handled. Maybe this does already exist in one or the other way? Sincerly Marc Weber (1) (Seq (Elem Title_T) (Seq (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T)))))) (Query (Seq (Elem Base_T) (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T))))))))))

1 0

Discussing FFI
by Maurício 31 Aug '08

31 Aug '08

Hi, I saw the (a?) page about FFI on Haskell: http://www.cse.unsw.edu.au/~chak/haskell/ffi It shows a link to a mailing list but, checking the list archives at: http://www.haskell.org/pipermail/ffi , it seems it's dead since 2007. Is there a new list about FFI? Where should I discuss my begginer issues about it? Thanks, Maurício

2 1