headers
Daan Leijen | 1 May 2005 16:53
Picon

Haskell workshop 2005: second call for papers.

[I apologize for cross-postings. Please forward to interested colleagues]

                     2005 Haskell Workshop
          Tallinn, Estonia, 30 September, 2005
           http://www.cs.uu.nl/~daan/hw2005

                     Second Call for papers

 -- Important Dates ---------------------------------------------------

Submission deadline    : June 10
Acceptance notification: July  5
Final version due      : July 19
Haskell workshop       : September 30

-- The Haskell Workshop ----------------------------------------------

The Haskell Workshop 2005 is an ACM SIGPLAN sponsored workshop 
affiliated with
the 2005 International Conference on Functional Programming (ICFP). Previous
Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris
(1999), Montreal (2000), Firenze (2001), Pittsburgh (2002), Uppsala 
(2003), and
Snowbird (2004).

-- Scope -------------------------------------------------------------

The purpose of the Haskell Workshop is to discuss experience with 
Haskell, and
future developments for the language.  The scope of the workshop
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shae Matijs Erisson | 2 May 2005 08:16

http://www.haskell.org/tmrwiki/IssueTwo

For issue two, the subjects are Template Haskell, better module compatibility,
exploring dark corners of GHC, domain specific languages, and the Foreign
Function Interface.

We've also switched to an experimental wikipublishing format, in hopes of
removing the bottlenecks that showed up in the first issue, and encouraging
more peer review. We'd like to hear your feedback!

http://www.haskell.org/tmrwiki/IssueTwo
--

-- 
It seems I've been living two lives. One life is a self-employed web developer
In the other life, I'm shapr, functional programmer.  | www.ScannedInAvian.com
One of these lives has futures (and subcontinuations!)|  --Shae Matijs Erisson
Permalink | Reply | 7 comments |
headers
Andreas Fuertig | 2 May 2005 19:31
Picon

rekursive array problem

Hi  <at>  all!

I have a big problem. 
i have a list of variables and now i need something like this

fillArray ["a"]
should be something like this:
[[("a",True)],[("a",False)]]

fillArray ["a","b"]
[[("a",True),("b",True)],[("a",False),("b",True)],[("a",True),("b",False)],
[("a",False),("b",False)]]

and so on. i tried many things, and i dont know how to solve this.

allthesame vars = [(alltrue [] vars)] ++ [(allfalse [] vars)]
alltrue liste [] = liste
alltrue liste (x:xs) = alltrue (liste ++ [(x,True)]) xs
allfalse liste [] = liste
allfalse liste (x:xs) = allfalse (liste ++ [(x,False)]) xs

this works, but whats with the rest :)

it would be very nice, if somebody could help me.

thank you
Andreas
Permalink | Reply | 2 comments |
headers
Mirko Rahn | 2 May 2005 17:47
Picon
Favicon

Re: rekursive array problem

Andreas Fuertig wrote:

> fillArray ["a"]
> [[("a",True)],[("a",False)]]
> 
> fillArray ["a","b"]
> [[("a",True),("b",True)],[("a",False),("b",True)],[("a",True),("b",False)],
> [("a",False),("b",False)]]

A simple solution is:

fill :: [a] -> [[(a,Bool)]]
fill [] = [[]]
fill (x:xs) = do v <- [True,False] ; vs <- fill xs ; return ((x,v):vs)

have fun,

--

-- 
-- Mirko Rahn -- Tel +49-721 608 7504 --
--- http://liinwww.ira.uka.de/~rahn/ ---
Permalink | Reply | 0 comments |
headers
Peter Simons | 2 May 2005 17:52
Picon
Gravatar

Re: rekursive array problem

Andreas Fuertig writes:

 > fillArray ["a"]
 > should be something like this:
 > [[("a",True)],[("a",False)]]

A pretty generic solution using the "Bounded" and "Enum"
type classes to calculate the list of all values for a given
type would be:

enumAll :: (Bounded a, Enum a) => [a]
enumAll = [ minBound .. maxBound ]

fillArray :: (Bounded b, Enum b) => [a] -> [(a,b)]
fillArray xs = [ (x,y) | x <- xs, y <- enumAll  ]

In GHCi, you can use these functions like this:

 | *Main> enumAll :: [Bool]
 | [False,True]
 |
 | *Main> fillArray "abc" :: [(Char, Bool)]
 | [('a',False),('a',True),('b',False),('b',True),('c',False),('c',True)]

Peter
Permalink | Reply | 0 comments |
headers
Sven Moritz Hallberg | 2 May 2005 18:26
Picon
Picon

Eternal Compatibility In Theory

On Mon, May 02, 2005 at 08:16:12AM +0200, Shae Matijs Erisson wrote:
> 
> http://www.haskell.org/tmrwiki/IssueTwo
>

Dear Haskellers,

Even though it's a plug, I'd like to seperately announce my article
for this issue, because it grew out of discussion on this list.

I'd posted some thoughts on the versioning of module interfaces
a few months back, in reply to a post by Alexander Jacobson.
Subsequent discussion and re-thinking have lead to the idea that,
basically by appending version numbers to module names,
the compatibility problem can be solved without any language
extensions, in perfect synergy with Cabal and Hackage, and with
very little effort on part of the programmer.

It's not a ground-breaking discovery. It's a trivial idea, really;
but strangely, it seems that nobody does it. So I tried to think
the scenario through, to find problems and clarify my idea.
The result is the article

  Eternal Compatibility in Theory
  http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

In short, I didn't find any problems and adopted the scheme
for one of my own modules.

I think it would be great if we could solve the problem of
(Continue reading)

Permalink | Reply | 6 comments |
headers
robert dockins | 2 May 2005 19:59

Re: Eternal Compatibility In Theory

 >   Eternal Compatibility in Theory
 >   http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

Some thoughts:

Is there a way to reliably and automatically check if two versions of a 
haskell module are interface compatible?  This would greatly aid the 
process of deciding when to create a new numbered version of the module. 
  It would be interesting to see if this process could be 
(semi)automated using the darcs "trackdown" command with such a test.
Permalink | Reply | 5 comments |
headers
Marcin 'Qrczak' Kowalczyk | 2 May 2005 21:24
X-Face
Picon

Re: Eternal Compatibility In Theory

robert dockins <robdockins <at> fastmail.fm> writes:

> Is there a way to reliably and automatically check if two versions of
> a haskell module are interface compatible?

No, because it would have to check whether the semantics of functions
is the same, even if they are written differently.

--

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak <at> knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/
Permalink | Reply | 4 comments |
headers
robert dockins | 2 May 2005 21:57

Re: Eternal Compatibility In Theory

>>Is there a way to reliably and automatically check if two versions of
>>a haskell module are interface compatible?
>  
> No, because it would have to check whether the semantics of functions
> is the same, even if they are written differently.

Of course, we cannot expect the computer to examine the semantics.  We 
must rely on people to know when semantics change.

Suppose I want to ask the easier question "do these two text files 
implement haskell modules which are _type_ compatable?", how would I do 
it?  Ie, I want the test to fail if I change the type of some function 
foo, or if I add a method to a class declaration etc.
Permalink | Reply | 3 comments |
headers
Philippa Cowderoy | 2 May 2005 22:08

Re: Eternal Compatibility In Theory

On Mon, 2 May 2005, robert dockins wrote:

> Suppose I want to ask the easier question "do these two text files implement 
> haskell modules which are _type_ compatable?", how would I do it?  Ie, I want 
> the test to fail if I change the type of some function foo, or if I add a 
> method to a class declaration etc.
>

A test module containing code that uses every function and has an instance 
of every class would do that much. You can extend that to check various 
other properties you expect to hold.

--

-- 
flippa <at> flippac.org

"My religion says so" explains your beliefs. But it doesn't explain 
why I should hold them as well, let alone be restricted by them.
Permalink | Reply | 0 comments |

Gmane