[Haskell] Announcing Djinn, new version 2004-12-13
There is a new version of Djinn available, with two notable new features: Haskell data types can be defined and the found functions are sorted (heuristically) to present the best one first. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. `-- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ECT and SearchPath
On Tue, 13 Dec 2005, Sven Moritz Hallberg wrote: is a good scheme. For it to _really_ work, however, we should form a registry of "officially assigned" module names (i.e. ones without a disambiguation suffix) and also one for the author and/or organization names to be used as suffixes. I for example am known by the nickname Pesco, or (more recently) by the mnemonic SM at domain KHJK.ORG. My solution to this problem in SearchPath is module maps. SearchPath lets you use multiple module maps simultaneously. So you can for example simultaneously use a global module map as haskell.org, an industry module map at yourassociate.org, an internal company map located on your_intranet, and a personal map located on your computer. Conflicts are handled by the order in which you invoke the maps. So a map is official to the extent your community shares it. Different entities can also compete to provide maps of differing qualities e.g. is the map audited for security issues? does the map point to the repository head of all modules or a static version? etc. Clay Shirky famously observed that in namespace construction there is a pretty direct tradeoff between have names be memorable, global, and non-political. I think shared module maps represents a good compromise. I just read your ECT article which seems to start with the same assumption and takes the theory to its logical conclusion. I take that as a compliment. ;) Thank you. It was intended that way! :-) The main issue that springs to my mind is authenticity control. How do I know the module I'm downloading is the one I want? Note that this question is always there, even in the local case, but it is usually not seen as a problem until module sources are distributed over the Net. I think https URLs solve this problem. You choose module maps from authors you trust and access those maps via https. These "friendly" module maps then point to "friendly" modules that you can also access via https. Since, you choose which CAs you trust to sign server keys, you are safe from MITM attacks. Note, I thought about supporting pgp but there is no obvious way to sign a CVS/SVN/darcs repository and what I like about ECT is that you can point to such repositories rather than specific checked out versions in the comfort that things won't break. I LOVE that in combination with ECT, you get notified that you are using a deprecated version on the next compile without having to check all your imports manually. FYI, the main thing that I would really like, but don't have and can't implement, is for :r in ghci to invoke SearchPath to hunt for missing modules rather than forcing you to quit out and restart ghci every time you add an import of an undownloaded module in your code. Using searcpath make thing very smooth, but this feature would make it completely so. -Alex- __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ETAPS 2007 - Call for Satellite Events
--- ETAPS 2007: CALL FOR SATELLITE EVENT PROPOSALS deadline: January 20, 2006 --- ETAPS 2007 European Joint Conferences on Theory And Practice of Software March 24 - April 1, 2007 Braga, Portugal http://www.di.uminho.pt/etaps07/ -- ABOUT ETAPS -- The European Joint Conferences on Theory and Practice of Software (ETAPS) is the primary European forum for academic and industrial researchers working on topics relating to Software Science. ETAPS is an annual event which takes place in Europe each spring since 1998. The tenth meeting, ETAPS 2007, will take place March 24 till April 1 2007 in Braga, Portugal, hosted by the University of Minho. The main conferences of ETAPS are: - FOSSACS: Foundations of Software Science and Computation Structures - FASE:Fundamental Approaches to Software Engineering - ESOP:European Symposium on Programming - CC: International Conference on Compiler Construction - TACAS: Tools and Algorithms for the Construction and Analysis of Systems These conferences will take place March 26-30, 2007. -- SATELLITE EVENTS -- The ETAPS 2007 Organizing Committee invites proposals for Satellite Events (workshops, tutorials, etc.) that will complement the main ETAPS conferences. They should fall within the scope of ETAPS. This encompasses all aspects of the system development process, including specification, design, implementation, analysis and improvement, as well as the languages, methodologies and tools which support these activities, covering a spectrum from practically-motivated theory to soundly-based practice. Satellite Events provide an opportunity to discuss and report on emerging research approaches and practical experience relevant to theory and practice of software. ETAPS 2007 Satellite Events will be held immediately before and after the main conferences, on March 24-25 and March 31, and April 1, 2007. -- SUBMISSION OF SATELLITE EVENT PROPOSALS -- Researchers and practitioners wishing to organize Satellite Events are invited to submit proposals in ASCII, PDF or Postscript format by e-mail to the Satellite Events Co-chairs, Luis Barbosa and Joost Visser, mailto:[EMAIL PROTECTED] A proposal should not exceed two pages and should include: - Satellite Event name / acronym - the names and contact information of the organizers - the preferred period: 24-25 March or 31 March-1 April - the duration of the workshop: one-day or two-day event - 120-word description of the workshop topic for later use in publicity material - a brief explanation of the workshop topic and its relevance to ETAPS - a schedule for paper submission, notification of acceptance and final versions (the latter no later than the early registration deadline of February 12, 2007) - expected number of participants - any other relevant information, like event format, invited speakers, publication policy, demo sessions, special space requirements, etc. The proposals will be evaluated by the ETAPS 2007 organizing committee on the basis of their assessed benefit for prospective participants to ETAPS 2007. The titles and brief information about accepted Satellite Events will be included in the ETAPS 2007 web site, call for papers and call for participation. Satellite Events organizers will be responsible for - producing the event's call for papers and call for participations - publicising the event through specialist mailing lists etc. to complement publicity for ETAPS as a whole - hosting and maintaining a web site for the event - reviewing and making acceptance decisions on submitted papers - producing the event proceedings, if any; facilities for printing will be made available by the ETAPS organizers - scheduling workshop activities in consultation with the local organizers Prospective organizers may wish to consult the web pages of previous satellite events as examples: ETAPS 2006: http://www.complang.tuwien.ac.at/etaps06/ ETAPS 2005: http://www.etaps05.inf.ed.ac.uk/ ETAPS 2004: http://www.lsi.upc.es/etaps04/ ETAPS 2003: http://www.mimuw.edu.pl/etaps03/ -- IMPORTANT DATES -- Satellite Event Proposals Deadline: 20 January 2006 Notification of acceptance: 6 February 2006 -- FURTHER INFORMATION AND ENQUIRIES -- http://www.di.uminho.pt/etaps07/ [EMAIL PROTECTED] Luis Barbosa Joost Visser ETAPS 2007 Satellite Events Co-chairs [EMAIL PROTECTED], [EMAIL PROTECTED] -- THE HOST CITY -- Braga, capital of the Minho province, is an ancient city in the heart of the green and fertile region known as the Costa Verde. The region is known for its attractiveness in terms of climate, gastronomy, prices, and culture. The region is served by the Oporto international airport, providing direct flights to many major European cities. Braga is known for its barroque churche
Re: [Haskell] TArray?
On 12/13/05, Simon Marlow <[EMAIL PROTECTED]> wrote: > On 13 December 2005 13:11, Sebastian Sylvan wrote: > > > On 12/13/05, Tomasz Zielonka <[EMAIL PROTECTED]> wrote: > >> On Tue, Dec 13, 2005 at 01:32:46PM +0100, Sebastian Sylvan wrote: > >>> Are there plans to include a mutable array for use in the STM monad, > >>> or a good reason for why this is not needed? Also, an unboxed > >>> version would be nice. > >> > >> Why not use an (Array idx (TVar a)) ? > > > > Ah.. Good thinking! > > This should work for in the STM monad for anything you would IOArray > > for in the IO monad, if you write proper instances for MArray of > > course... > > > > It's a bit inefficient, an extra indirection (compared to a primitive > > implementation) but that shouldn't matter too much for the general > > case. And the TVars themselves introduces some extra overhead, I would > > suppose (which could be per-array rather than per-element, without > > losing the property that only writes to the same element causes > > retries). > > It gets even trickier if you want an unboxed mutable array in the STM > > monad. > > > > But still, it's useful and I think a mutable array for the STM monad > > should be in the libraries. It could be implemented as an Array at > > first, and perhaps later switch to a more efficient representation. > > In the past I have used arrays of TVars, as Thomasz suggested. It would > indeed be better to have a primitive STM array, the only problem with > this is the extra complexity. One simplifying assumption is that it > should consider changes at the level of the whole array, rather than > per-element (otherwise you'd use an array of TVars). There is no plan to provide an implementation of this (the Array-of-TVar approach) in the libs? With an MArray instance? It would be nice if you could just plug i into existing functions operating on MArray... /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] HWN this week
Hi everyone, We had a fire at my workplace last night. It is unlikely that I will be able to get HWN out this week. (Sorry about missing it last week as well.) We'll just call the next one the Special Holiday Edition, eh? -- John ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] TArray?
On Dec 13, 2005, at 8:46 AM, Simon Marlow wrote: [In response to another plea for TArrays] In the past I have used arrays of TVars, as Thomasz suggested. It would indeed be better to have a primitive STM array, the only problem with this is the extra complexity. One simplifying assumption is that it should consider changes at the level of the whole array, rather than per-element (otherwise you'd use an array of TVars). Actually, in that case it might be more useful to have a TMVar containing an array. But I suspect the need for this use case is small. I know a ton of uses for transactionally-updated arrays for which the goal is to permit concurrent access to independent array elements (concurrent hash tables come to mind as an obvious use case where transactions make life vastly simpler). You might ask Tim Harris whether there's a reasonably simple, clever way to do this using arrays + CAS. I believe such a trick exists---you might end up waking too many threads on a write, but you'd get read/write concurrency at least. -Jan Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] TArray?
On Dec 13, 2005, at 8:46 AM, Simon Marlow wrote: [In response to another plea for TArrays] In the past I have used arrays of TVars, as Thomasz suggested. It would indeed be better to have a primitive STM array, the only problem with this is the extra complexity. One simplifying assumption is that it should consider changes at the level of the whole array, rather than per-element (otherwise you'd use an array of TVars). Actually, in that case it might be more useful to have a TMVar containing an array. But I suspect the need for this use case is small. I know a ton of uses for transactionally-updated arrays for which the goal is to permit concurrent access to independent array elements (concurrent hash tables come to mind as an obvious use case where transactions make life vastly simpler). You might ask Tim Harris whether there's a reasonably simple, clever way to do this using arrays + CAS. I believe such a trick exists---you might end up waking too many threads on a write, but you'd get read/write concurrency at least. -Jan Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] TArray?
On 13 December 2005 13:11, Sebastian Sylvan wrote: > On 12/13/05, Tomasz Zielonka <[EMAIL PROTECTED]> wrote: >> On Tue, Dec 13, 2005 at 01:32:46PM +0100, Sebastian Sylvan wrote: >>> Are there plans to include a mutable array for use in the STM monad, >>> or a good reason for why this is not needed? Also, an unboxed >>> version would be nice. >> >> Why not use an (Array idx (TVar a)) ? > > Ah.. Good thinking! > This should work for in the STM monad for anything you would IOArray > for in the IO monad, if you write proper instances for MArray of > course... > > It's a bit inefficient, an extra indirection (compared to a primitive > implementation) but that shouldn't matter too much for the general > case. And the TVars themselves introduces some extra overhead, I would > suppose (which could be per-array rather than per-element, without > losing the property that only writes to the same element causes > retries). > It gets even trickier if you want an unboxed mutable array in the STM > monad. > > But still, it's useful and I think a mutable array for the STM monad > should be in the libraries. It could be implemented as an Array at > first, and perhaps later switch to a more efficient representation. In the past I have used arrays of TVars, as Thomasz suggested. It would indeed be better to have a primitive STM array, the only problem with this is the extra complexity. One simplifying assumption is that it should consider changes at the level of the whole array, rather than per-element (otherwise you'd use an array of TVars). Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] TArray?
On 12/13/05, Tomasz Zielonka <[EMAIL PROTECTED]> wrote: > On Tue, Dec 13, 2005 at 01:32:46PM +0100, Sebastian Sylvan wrote: > > Are there plans to include a mutable array for use in the STM monad, > > or a good reason for why this is not needed? Also, an unboxed version > > would be nice. > > Why not use an (Array idx (TVar a)) ? Ah.. Good thinking! This should work for in the STM monad for anything you would IOArray for in the IO monad, if you write proper instances for MArray of course... It's a bit inefficient, an extra indirection (compared to a primitive implementation) but that shouldn't matter too much for the general case. And the TVars themselves introduces some extra overhead, I would suppose (which could be per-array rather than per-element, without losing the property that only writes to the same element causes retries). It gets even trickier if you want an unboxed mutable array in the STM monad. But still, it's useful and I think a mutable array for the STM monad should be in the libraries. It could be implemented as an Array at first, and perhaps later switch to a more efficient representation. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] TArray?
On Tue, Dec 13, 2005 at 01:32:46PM +0100, Sebastian Sylvan wrote: > Are there plans to include a mutable array for use in the STM monad, > or a good reason for why this is not needed? Also, an unboxed version > would be nice. Why not use an (Array idx (TVar a)) ? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] TArray?
Are there plans to include a mutable array for use in the STM monad, or a good reason for why this is not needed? Also, an unboxed version would be nice. A workaround is IOArray with unsafePerformIO wrapped in the STM monad, but it would be preferable if multiple threads could write to the same array without causing conflicts unless they write to the same index. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] existential type synonyms
Hello John, Tuesday, December 13, 2005, 6:27:53 AM, you wrote: >> areSame :: AnyType -> AnyType -> Bool JM> which would expand to >> areSame :: forall a b . Type a -> Type b -> Bool it is not easier to just define areSame as areSame :: Type a -> Type b -> Bool without even declaring AnyType? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type problem
That's good enough until GHC 6.6.
Thank you very much!
/ Emil
Tomasz Zielonka skrev:
On Tue, Dec 13, 2005 at 09:46:31AM +0100, Emil Axelsson wrote:
Is this just a limitation of the current GATDs, or is it unreasonable of me
to expect this to work?
AFAIK it is a current limitation of GADTs, which will be removed in GHC
6.6.
Is there any workaround, such as coercing the type of the value function?
I've had the same problem myself. The workaround is to replace some of
type-class constraints with "witness" GADTs. The code I attached
shows how you can do it. I chose to make HasX a GADT, and introduce
the HasX' type-class, but the latter is only for convenience. Note
the subtle change in Val's definition:
data Val a where
...
X :: HasX a -> Val a -- Unconstrained
^^
Best regards
Tomasz
{-# OPTIONS -fglasgow-exts #-}
data Number = XN -- Unconstrained
| N Int -- Constrained
data HasX a where
HasX_Number :: HasX Number
xVal :: HasX a -> a
xVal HasX_Number = XN
class HasX' a where
hasX :: HasX a
instance HasX' Number where
hasX = HasX_Number
x :: HasX' a => Val a
x = X hasX
data Val a where
P :: a -> Val a -- Primitive
T2 :: (Val a1, Val a2) -> Val (a1,a2)
X :: HasX a -> Val a -- Unconstrained
value :: Val a -> a
value (X hx) = xVal hx
value (P a)= a
value (T2 (a1,a2)) = (value a1, value a2)
ex1 :: Val (Number,(Number,Number))
ex1 = T2 (P (N 3), T2 (x, P (N 5)))
-- ex2 :: Val (Number,Number)
-- ex2 = X
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type problem
On Tue, Dec 13, 2005 at 10:42:15AM +0100, Tomasz Zielonka wrote: > On Tue, Dec 13, 2005 at 09:46:31AM +0100, Emil Axelsson wrote: > > Is this just a limitation of the current GATDs, or is it unreasonable of me > > to expect this to work? > > AFAIK it is a current limitation of GADTs, which will be removed in GHC > 6.6. Of course it is the limitation that will be removed, not GADTs ;-) Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type problem
On Tue, Dec 13, 2005 at 09:46:31AM +0100, Emil Axelsson wrote:
> Is this just a limitation of the current GATDs, or is it unreasonable of me
> to expect this to work?
AFAIK it is a current limitation of GADTs, which will be removed in GHC
6.6.
> Is there any workaround, such as coercing the type of the value function?
I've had the same problem myself. The workaround is to replace some of
type-class constraints with "witness" GADTs. The code I attached
shows how you can do it. I chose to make HasX a GADT, and introduce
the HasX' type-class, but the latter is only for convenience. Note
the subtle change in Val's definition:
data Val a where
...
X :: HasX a -> Val a -- Unconstrained
^^
Best regards
Tomasz
--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
{-# OPTIONS -fglasgow-exts #-}
data Number = XN -- Unconstrained
| N Int -- Constrained
data HasX a where
HasX_Number :: HasX Number
xVal :: HasX a -> a
xVal HasX_Number = XN
class HasX' a where
hasX :: HasX a
instance HasX' Number where
hasX = HasX_Number
x :: HasX' a => Val a
x = X hasX
data Val a where
P :: a -> Val a -- Primitive
T2 :: (Val a1, Val a2) -> Val (a1,a2)
X :: HasX a -> Val a -- Unconstrained
value :: Val a -> a
value (X hx) = xVal hx
value (P a)= a
value (T2 (a1,a2)) = (value a1, value a2)
ex1 :: Val (Number,(Number,Number))
ex1 = T2 (P (N 3), T2 (x, P (N 5)))
-- ex2 :: Val (Number,Number)
-- ex2 = X
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type problem
I found an acceptable, but not too nice workaround: * Add another class without methods: class HasX a => HasX' a * Make all types that may be unconstrained an instance of this class: instance HasX' Number * Make pairs an instance of HasX (this feels wrong): instance HasX (a1,a2) where xVal = undefined * Add appropriate constraints to the GADT types (X has constraint HasX'): data Val a where P :: a -> Val a-- Primitive T2 :: (HasX a1, HasX a2) => (Val a1, Val a2) -> Val (a1,a2) X :: HasX' a => Val a -- Unconstrained * Add (HasX a => ) to the value type. At least this is safe. The undefined xVal will never be run. I still wonder if the original idea couldn't work somehow... Thank you, / Emil Emil Axelsson skrev: Hello all, Could I please get some guidance with this? I'm working on implementing a simple relational language in Haskell. I'm trying to construct a data type that can represent values and patterns for a small set of supported types. See code below. HasX is a class of types that have an unconstrained value (xVal). Number is a typical member of that class. Val is my value/pattern data type. P represents a primitive value and T2 is used to make structure. X represents the unconstrained value or a wildcard pattern. It can only be used for types in HasX. The problem is the commented line in the value function. I want to use the xVal method to get the value for X. This is only allowed if I add the constraint (HasX a => ). But I don't want value to have that constraint, since then I cannot run it on pairs. Furthermore, it should be safe without the constraint. ex2 shows that we cannot use X to construct values that are not in HasX. Is this just a limitation of the current GATDs, or is it unreasonable of me to expect this to work? Is there any workaround, such as coercing the type of the value function? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Type problem
Hello all,
Could I please get some guidance with this?
I'm working on implementing a simple relational language in Haskell.
I'm trying to construct a data type that can represent values and patterns for a
small set of supported types. See code below.
HasX is a class of types that have an unconstrained value (xVal).
Number is a typical member of that class.
Val is my value/pattern data type.
P represents a primitive value and T2 is used to make structure.
X represents the unconstrained value or a wildcard pattern. It can only be used
for types in HasX.
The problem is the commented line in the value function. I want to use the xVal
method to get the value for X. This is only allowed if I add the constraint
(HasX a => ). But I don't want value to have that constraint, since then I
cannot run it on pairs.
Furthermore, it should be safe without the constraint. ex2 shows that we cannot
use X to construct values that are not in HasX.
Is this just a limitation of the current GATDs, or is it unreasonable of me to
expect this to work?
Is there any workaround, such as coercing the type of the value function?
--
/ Emil
{-# OPTIONS -fglasgow-exts #-}
class HasX a where
xVal :: a
data Number = XN -- Unconstrained
| N Int -- Constrained
instance HasX Number where
xVal = XN
data Val a where
P :: a -> Val a -- Primitive
T2 :: (Val a1, Val a2) -> Val (a1,a2)
X :: HasX a => Val a -- Unconstrained
value :: Val a -> a
-- value X= xVal
value (P a)= a
value (T2 (a1,a2)) = (value a1, value a2)
ex1 :: Val (Number,(Number,Number))
ex1 = T2 (P (N 3), T2 (X, P (N 5)))
-- ex2 :: Val (Number,Number)
-- ex2 = X
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
