[Haskell-cafe] Last CFP: 12th International Workshop on Language Descriptions, Tools, and Applications (LDTA 2012)
LDTA 2012 Call for Papers 12th International Workshop on Language Descriptions, Tools, and Applications www.ldta.info Tallinn, Estonia March 31 April 1, 2012 an ETAPS workshop LDTA is an application and tool-oriented workshop focused on grammarware - software based on grammars in some form. Grammarware applications are typically language processing applications and traditional examples include parsers, program analyzers, optimizers and translators. A primary focus of LDTA is grammarware that is generated from high-level grammar-centric specifications and thus submissions on parser generation, attribute grammar systems, term/graph rewriting systems, and other grammar-related meta-programming tools, techniques, and formalisms are encouraged. LDTA is also a forum in which theory is put to the test, in many cases on real-world software engineering challenges. Thus, LDTA also solicits papers on the application of grammarware to areas including, but not limited to, the following: - program analysis, transformation, generation, and verification, - implementation of Domain-Specific Languages, - reverse engineering and re-engineering, - refactoring and other source-to-source transformations, - language definition and language prototyping, and - debugging, profiling, IDE support, and testing. Note that LDTA is a well-established workshop similar to other conferences on (programming) language engineering topics such as SLE and GPCE, but is solely focused on grammarware. Paper Submission - LDTA solicits papers in the following categories. - research papers: original research results within the scope of LDTA with a clear motivation, description, analysis, and evaluation. - short research papers: new innovative ideas that have not been completely fleshed out. As a workshop, LDTA strongly encourages these types of submissions. - experience report papers: description of the use of a grammarware tool or technique to solve a non-trivial applied problem with an emphasis on the advantages and disadvantages of the chosen approach to the problem. - tool demo papers: discussion of a tool or technique that explains the contributions of the tool and what specifically will be demonstrated. Each submission must clearly state in which of these categories it falls, and must not be published or submitted elsewhere. Papers are to use the standard LaTeX article style and the authblk style for affiliations; a sample of which is provided at www.ldta.info. Research and experience papers are limited to 15 pages, tool demonstration papers are limited to 10 pages, and short papers are limited to 6 pages. The final version of the accepted papers will, pending approval, be published in the ACM Digital Library and will also be made available during the workshop. Please submit your abstract and paper using EasyChair at http://www.easychair.org/conferences/?conf=ldta2012. The authors of each submission are required to give a presentation at LDTA 2011 and tool demonstration paper presentations are intended to include a significant live, interactive demonstration. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, assuming acceptance, be published in journal form. As in past years this will be done in a special issue of the journal Science of Computer Programming (Elsevier Science). Invited Speaker - Janis Voigtländer (University of Bonn, Germany). Important Dates - Abstract submission: Nov. 28, 2011 Full paper submission: Dec. 5, 2011 Author notification: Jan. 20, 2012 Camera-ready papers: Feb. 05, 2012 LDTA Workshop: Mar. 31 - Apr. 1, 2012 LDTA Tool Challenge - The 2011 Workshop pioneered the LDTA Tool Challenge where tool developers were invited to develop solutions to a range of language processing tasks over a simple but evolving set of imperative programming languages. We expect a challenge to form part of LDTA every two years. The 2012 workshop will feature presentations devoted to a de-brief of the 2011 challenge, based on the paper currently being prepared by challenge participants. Program Committee --- Suzana Andova, Eindhoven University of Technology, The Netherlands (co-chair) Anya Helene Bagge, University of Bergen, Norway Kyung-Goo Doh, Hanyang University, Ansan, South Korea Jeff Gray, University of Alabama, USA Görel Hedin, Lund Institute of Technology, Sweden Zoltán Horváth, Eötvös Loránd University, Budapest, Hungary Zhenjiang Hu, National Institute of Informatics, Japan Roberto Ierusalimschy, Pontifícia Universidade Católica do Rio de Janeiro, Brazil Ivan Kurtev, University of Twente, The
Re: [Haskell-cafe] Poll: Do you want a mascot?
Yes. 2011/11/24 Colin Adams colinpaulad...@gmail.com No. On 23 November 2011 19:11, heathmatlock heathmatl...@gmail.com wrote: Question: Do you want a mascot? Answers: Yes No -- This is an attempt to figure out if this idea is going anywhere. ___ 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
[Haskell-cafe] FGL custom node identification (Label - Node lookup)
All, The containers library has a somewhat primitive but certainly useful Data.Graph library. Building a graph with this library simultaneously results in the lookup functions: m1 :: Vertex - (node, key, [key]) m2 :: key - Maybe Vertex (where 'key' is like FGL's 'label' but is assumed to be unique) This is exactly what I wanted when building and analyzing a call graph in FGL. To that end, I started making a graph type that tracked label to Node mappings, wrapping Data.Graph.Inductive.Gr, and assuming the labels are all unique. The classes for such a graph actually aren't possible. The ability to build a mapping from a node's 'label' to the 'Node' requires extra context (ex: Hashable, Ord, or at least Eq), but such context can not be provided due to the typeclass construction. Is there any chance we can change the Graph and DiaGraph classes to expose the type variables 'a' and 'b'? class Graph gr a b where ... class (Graph gr) = DynGraph gr a b where ... This would allow instances to provide the needed context: instance (Hashable a, Hashable b) = Graph UniqueLabel a b where ... buildGraph = ... some use of containers libraries that require context ... ... lookupNode :: Hashable a = UniqueLabel a b - a - Node -- etc Cheers, Thomas P.S. Please do educate me if I simply missed or misunderstood some feature of FGL. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FGL custom node identification (Label - Node lookup)
On 24 November 2011 20:33, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: All, The containers library has a somewhat primitive but certainly useful Data.Graph library. Building a graph with this library simultaneously results in the lookup functions: m1 :: Vertex - (node, key, [key]) m2 :: key - Maybe Vertex (where 'key' is like FGL's 'label' but is assumed to be unique) This is exactly what I wanted when building and analyzing a call graph in FGL. To that end, I started making a graph type that tracked label to Node mappings, wrapping Data.Graph.Inductive.Gr, and assuming the labels are all unique. The classes for such a graph actually aren't possible. The ability to build a mapping from a node's 'label' to the 'Node' requires extra context (ex: Hashable, Ord, or at least Eq), but such context can not be provided due to the typeclass construction. Is there any chance we can change the Graph and DiaGraph classes to expose the type variables 'a' and 'b'? class Graph gr a b where ... class (Graph gr) = DynGraph gr a b where ... This would allow instances to provide the needed context: instance (Hashable a, Hashable b) = Graph UniqueLabel a b where ... buildGraph = ... some use of containers libraries that require context ... ... lookupNode :: Hashable a = UniqueLabel a b - a - Node -- etc Cheers, Thomas P.S. Please do educate me if I simply missed or misunderstood some feature of FGL. Well, there *is* the NodeMap module, but I haven't really used it so I'm not sure if it does what you want. We did start upon a version of FGL which had these type variables in the class, but it got a little fiddly; the ability to have superclass constraints should solve this but I haven't touched FGL for a while, as I've been working on some other graph library code for planar graphs, with the plan to take my experience from writing this library into a successor to FGL. However, my experience with designing this planar graph library has led me to using abstract (i.e. non-exported constructor) ID types for nodes and edges and finding them rather useful, but then I'm more concerned about the _structure_ of the graph rather than the items stored within it. As such, I'd appreciate you explaining to me (off-list is OK) why you want/need such a label - node mapping so that I can try and work out a way to incorporate such functionality. -- 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
Re: [Haskell-cafe] FGL custom node identification (Label - Node lookup)
On 24 November 2011 20:42, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 24 November 2011 20:33, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: All, The containers library has a somewhat primitive but certainly useful Data.Graph library. Building a graph with this library simultaneously results in the lookup functions: m1 :: Vertex - (node, key, [key]) m2 :: key - Maybe Vertex (where 'key' is like FGL's 'label' but is assumed to be unique) This is exactly what I wanted when building and analyzing a call graph in FGL. To that end, I started making a graph type that tracked label to Node mappings, wrapping Data.Graph.Inductive.Gr, and assuming the labels are all unique. The classes for such a graph actually aren't possible. The ability to build a mapping from a node's 'label' to the 'Node' requires extra context (ex: Hashable, Ord, or at least Eq), but such context can not be provided due to the typeclass construction. Is there any chance we can change the Graph and DiaGraph classes to expose the type variables 'a' and 'b'? class Graph gr a b where ... class (Graph gr) = DynGraph gr a b where ... This would allow instances to provide the needed context: instance (Hashable a, Hashable b) = Graph UniqueLabel a b where ... buildGraph = ... some use of containers libraries that require context ... ... lookupNode :: Hashable a = UniqueLabel a b - a - Node -- etc Cheers, Thomas P.S. Please do educate me if I simply missed or misunderstood some feature of FGL. Well, there *is* the NodeMap module, but I haven't really used it so I'm not sure if it does what you want. We did start upon a version of FGL which had these type variables in the class, but it got a little fiddly; the ability to have superclass constraints should solve this but I haven't touched FGL for a while, as I've been working on some other graph library code for planar graphs, with the plan to take my experience from writing this library into a successor to FGL. However, my experience with designing this planar graph library has led me to using abstract (i.e. non-exported constructor) ID types for nodes and edges and finding them rather useful, but then I'm more concerned about the _structure_ of the graph rather than the items stored within it. As such, I'd appreciate you explaining to me (off-list is OK) why you want/need such a label - node mapping so that I can try and work out a way to incorporate such functionality. To be more clear: we wanted superclass constraints because we had the main classes be of kind * with associated-types for the node and edge labels (which could possibly just be `()'); but to be able to do mapping over the nodes and edges we needed to be able to specify a mapping from (g a b) to g a b (where g is of kind * - * - *). -- 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
[Haskell-cafe] Munich Haskell Meeting
Dear all, next week on Tuesday, 29 November, our monthly Haskell get-together will be held at Cafe Puck in Munich. Starting time is 19h30. Please feel free to join us. We are always happy to see someone new. There have been lots of people last time and we did not have enough tables. Therefore, if you plan to join us, please go to this page and hit the button. This well help to reserve places: http://www.haskell-munich.de/dates There is also the question, what to do in December. Any suggestions? We hope to see you soon, Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type level strings?
Evan Laforge has defined
data Thing {
thing_id :: ThingId
, thing_stuff :: Stuff
}
newtype ThingId = ThingId String
and wishes to statically preclude binary operations with things that
have different ThingIds. However, Things and their Ids can be loaded
from files and so cannot be known to the compiler. He wished for
type-level strings -- which is what the enclosed code gives.
When we've got two Things loaded from two different files we must do a
run-time check to see if these two things have in fact the same
ThingId. That is inevitable. The question is how frequently do we have
to make such a test?
One approach is to do such a ruin-time test on each binary operation
on things. The original Thing above was of that approach:
instance Monoid Thing where
mappend (Thing id1 stuff1) (Thing id2 stuff2)
| id1 /= id2 = error ...
| otherwise = Thing id1 (stuff1 `mappend` stuff2)
Every time we mappend things, we must check their ids.
It has been suggested to use existentials. We get the the following code:
maybeAppend :: Exists Thing - Exists Thing - Maybe (Exists Thing)
maybeAppend (Exists t1) (Exists t2) =
case thing_id t1 `equal` thing_id t2 of
Just Refl - Just $ Exists (t1 `mappend` t2)
Nothing - Nothing
How different is this from the original mappend? Every time we wish to
mappend two things, we have to do the run-time test of their ids!
We added phantom times, existentials, GADTs -- and got nothing in
return. No improvement to the original code, and no static guarantees.
When we have to mappend things several times, it seems optimal to do
the run-time ID check only once (we have to do that check anyway) and
then mappend the results without any checks, and with full static
assurance that only Identical things are mappended. The enclosed code
implements that approach. The instance for Monoid makes patent only
things with the same id may be mappended. Moreover, there is no
run-time id check, and we do not have to think up the id to give to
mempty. The test does read two things from a `file' (a string) and
does several operations on them. The run-time test is done only once.
The ideas of the code are described in the papers with Chung-chieh
Shan on lightweight static capabilities and implicit configurations.
{-# LANGUAGE RankNTypes, ScopedTypeVariables #-}
module Thing where
import Data.Monoid
import Data.Char
-- The data constructor Thing should not be exported
newtype Thing id = Thing{ thingStuff :: Stuff }
type Stuff = [Int] -- or any monoid
class IDeal id where get_id :: id - String
-- The user should use make_thing
make_thing :: IDeal id = id - Stuff - Thing id
make_thing _ t = Thing t
-- It is statically assured that only things with the same id
-- may be mappended. Moreover, there is no run-time id check
-- And we do not have to think up the id to give to mempty
instance Monoid (Thing id) where
Thing t1 `mappend` Thing t2 = Thing (t1 `mappend` t2)
mempty = Thing mempty
instance IDeal id = Show (Thing id) where
show (Thing t) = show $ (get_id (undefined::id),t)
-- A statically-known Id (just in case)
data Id1 = Id1
instance IDeal Id1 where get_id _ = Id1
-- Reading a thing from a file (or at least, a string)
data DynId id = DynId
instance Nat id = IDeal (DynId id) where
get_id _ = int_to_str $ nat (undefined::id)
read_thing :: String - (forall id. IDeal id = Thing id - w) - w
read_thing str k = reify_ideal i (\iD - k (make_thing iD t))
where (i,t) = read str
-- Run-time equality check
-- If id and id' are the same, cast the second to the same id
eqid_check :: forall id id'. (IDeal id, IDeal id') =
Thing id - Thing id' - Maybe (Thing id)
eqid_check _ (Thing t) | get_id (undefined::id) == get_id (undefined::id')
= Just (Thing t)
eqid_check _ _ = Nothing
test file1 file2 =
read_thing file1 (\t1 -
read_thing file2 (\t2 -
do_things t1 t2))
where
-- A run-time test is inevitable, but it is done only once
do_things t1 t2 | Just t2' - eqid_check t1 t2 = do_things' t1 t2'
do_things _ _ = error bad things
-- Now it is assured we have the same id
-- we can do things many times
do_things' :: IDeal id = Thing id - Thing id - String
do_things' t1 t2 = show $
mempty `mappend` t1 `mappend` t2 `mappend` t2 `mappend` t1
t1 = test (\id1\,[1,2]) (\id1\,[3,4])
-- (\id1\,[1,2,3,4,3,4,1,2])
t2 = test (\id1\,[1,2]) (\id2\,[3,4])
-- *** Exception: bad things
-- Reifying strings to types
-- They say String kinds are already in a GHC branch.
-- Edward Kmett maintains a Hackage package for these sort of things
-- Assume ASCII for simplicity
str_to_int :: String - Integer
str_to_int = 0
str_to_int (c:t) = fromIntegral (ord c) + 128 * str_to_int t
int_to_str :: Integer - String
int_to_str = loop
where
loop acc 0 = reverse acc
loop acc n | (n',c) - quotRem n 128 = loop (chr (fromIntegral c) : acc) n'
data Z = Z
data S a = S a
data T a = T a
class Nat a where nat :: a - Integer
Re: [Haskell-cafe] A Mascot
Am Mittwoch, den 16.11.2011, 10:46 +0100 schrieb Bas van Dijk: Is ⊥ the right symbol to express the non-strict evaluation of the language? Is it true that non-strict evaluation requires that ⊥ inhabits every type? In typical strict languages, ⊥ also inhabits every type. The difference is that the domains of all types except function types are flat. That is, they don’t contain any partially defined values like ⊥ : ⊥, but only ⊥ and completely defined values. Where a Haskell expression would result in a partially defined value, the same expression in a corresponding strict language would result in ⊥. So strict languages are “more ⊥” than Haskell. Thus I cannot see why ⊥ should be used as a symbol for non-strictness at all. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Do you want a mascot?
No. Am Mittwoch, den 23.11.2011, 13:11 -0600 schrieb heathmatlock: Question: Do you want a mascot? Answers: Yes No -- This is an attempt to figure out if this idea is going anywhere. ___ 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] Poll: Do you want a mascot? -- please stop this
2011/11/23 Giovanni Tirloni gtirl...@sysdroid.com: 2. It floods people with email they don't care (unless they care to keep track of the results) Not that I care that much about a mascot (I like the lamb though), but a few threads about it hardly counts for a flooding. Besides, a good email client would allows to group emails that belong together (a thread) and mute them. Also, this is café, right ? Aren't people subscribed to this list supposed to expect a broad range of topics ? David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Do you want a mascot?
I have the same position. want a good mascot... Count this as yes. 2011/11/23 Gábor Lehel illiss...@gmail.com: I don't want a bad mascot. I do want a good mascot. If you must count me down for one side or the other, count this as a yes. On Wed, Nov 23, 2011 at 8:11 PM, heathmatlock heathmatl...@gmail.com wrote: Question: Do you want a mascot? Answers: Yes No -- This is an attempt to figure out if this idea is going anywhere. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Victor Nazarov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Do you want a mascot? -- please stop this
David Virebayre dav.vire+hask...@gmail.com writes: Also, this is café, right ? Aren't people subscribed to this list supposed to expect a broad range of topics ? I don't mind a broad range of topics, but using it to collect polls is IMHO abusing it. I guess I can dust off the killfiling features in Gnus to deal with this, but I still think it's very annoying. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.2.2 package
I update the package to 1.0.2.3 addid several changes from Elliott Hird, in special a better install proccess with includes added to package tree. On Wed, Nov 23, 2011 at 4:00 PM, Luis Cabellos cabel...@ifca.unican.eswrote: Hello, all. I update the OpenCL package with a better error handle using Control.Exception. Thanks all comments in the previous version, and issues in github. # Where to get it * Hackage page (http://hackage.haskell.org/package/OpenCL) * Repository (https://github.com/zhensydow/opencl) * Bugs (https://github.com/zhensydow/opencl/issues) # Changes: * Changed LICENSE to BSD3 * Changed error from 'IO (Either CLError a)' to IO a + CLError exceptions * Added creation of programs using precompiled binaries (added example program) * Better documentation. Thanks, Luis Cabellos ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Platform
Dear Gurus, A. Why the Haskell Platform is still based on ghc 7.03? (At least on WinXP) B. Does anybody care about wxHaskell? Thanks. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FGL custom node identification (Label - Node lookup)
My thinking on this was that something akin to NodeMap should be _part_ of the graph structure. This would be more convenient and allow the graph and nodemap operations to apply to a single data structure. Instead of: insMapNode_ :: (Ord a, DynGraph g) = NodeMap a - a - g a b - g a b You could have: insMapNode_ :: (Ord a, DynGraph g) = a - g a b - g a b The only think stopping us from making a product data type like this is the inflexibility of the type classes, right? Were we able to define () to update the nodemap too then we could keep these to structures in sync automatically instead of expecting the programmer to keep them paired correctly. Cheers, Thomas On Thu, Nov 24, 2011 at 1:42 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 24 November 2011 20:33, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: All, The containers library has a somewhat primitive but certainly useful Data.Graph library. Building a graph with this library simultaneously results in the lookup functions: m1 :: Vertex - (node, key, [key]) m2 :: key - Maybe Vertex (where 'key' is like FGL's 'label' but is assumed to be unique) This is exactly what I wanted when building and analyzing a call graph in FGL. To that end, I started making a graph type that tracked label to Node mappings, wrapping Data.Graph.Inductive.Gr, and assuming the labels are all unique. The classes for such a graph actually aren't possible. The ability to build a mapping from a node's 'label' to the 'Node' requires extra context (ex: Hashable, Ord, or at least Eq), but such context can not be provided due to the typeclass construction. Is there any chance we can change the Graph and DiaGraph classes to expose the type variables 'a' and 'b'? class Graph gr a b where ... class (Graph gr) = DynGraph gr a b where ... This would allow instances to provide the needed context: instance (Hashable a, Hashable b) = Graph UniqueLabel a b where ... buildGraph = ... some use of containers libraries that require context ... ... lookupNode :: Hashable a = UniqueLabel a b - a - Node -- etc Cheers, Thomas P.S. Please do educate me if I simply missed or misunderstood some feature of FGL. Well, there *is* the NodeMap module, but I haven't really used it so I'm not sure if it does what you want. We did start upon a version of FGL which had these type variables in the class, but it got a little fiddly; the ability to have superclass constraints should solve this but I haven't touched FGL for a while, as I've been working on some other graph library code for planar graphs, with the plan to take my experience from writing this library into a successor to FGL. However, my experience with designing this planar graph library has led me to using abstract (i.e. non-exported constructor) ID types for nodes and edges and finding them rather useful, but then I'm more concerned about the _structure_ of the graph rather than the items stored within it. As such, I'd appreciate you explaining to me (off-list is OK) why you want/need such a label - node mapping so that I can try and work out a way to incorporate such functionality. -- 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
Re: [Haskell-cafe] Poll: Do you want a mascot?
@Wolfgang Jeltsch: I'm sorry, that was indeed my intension. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Do you want a mascot?
And also: Yes! (sorry for double post) On 24 November 2011 20:51, philipp siegmantel philipp.siegman...@googlemail.com wrote: @Wolfgang Jeltsch: I'm sorry, that was indeed my intension. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform
On 11/24/2011 04:57 PM, Jerzy Karczmarczuk wrote: A. Why the Haskell Platform is still based on ghc 7.03? (At least on WinXP) IIRC 7.2 is some kind of technology preview. So it won't be included in the haskell platform. The next version that is planed for the haskell platform is 7.4 Please correct me if I'm wrong. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FGL custom node identification (Label - Node lookup)
On 25 November 2011 05:13, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: My thinking on this was that something akin to NodeMap should be _part_ of the graph structure. This would be more convenient and allow the graph and nodemap operations to apply to a single data structure. Instead of: insMapNode_ :: (Ord a, DynGraph g) = NodeMap a - a - g a b - g a b You could have: insMapNode_ :: (Ord a, DynGraph g) = a - g a b - g a b The only think stopping us from making a product data type like this is the inflexibility of the type classes, right? Were we able to define () to update the nodemap too then we could keep these to structures in sync automatically instead of expecting the programmer to keep them paired correctly. My thinking is to (eventually) make more fine-grained classes, and have newtype wrappers that would add this kind of functionality (which would even let you choose the type of constraint); i.e. adding a node to a `(Hashable (NodeLabel g)) = HashableNodeMap g` would also add a `NodeLabel g - Node g` mapping to some internal lookup; is this what you're after? -- 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
Re: [Haskell-cafe] A Mascot
On 23/11/2011, at 4:40 AM, Karol Samborski wrote: And what about a cat? The cat is associated with elegance and a kind of magic. Please take a look: http://origami.bieszczady.pl/images/kot.png I could never in my whole life draw as well as that. But they are *skittles*, just like Lamb Da. Cute. Stiff. Lifeless. Easy to knock over. Reminds me of a salt shaker and pepper pot of my mother's. The collar's good, but the lambda is just pasted on for no intrinsic reason. How about a relatively smart animal _in motion_ with the lambda formed naturally by the positions of its limbs? Maybe a leaping gelada with its hind legs forming the \ of the lambda and its tail and back forming the / ? Smart, social, moving, and of course, furry. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] blaze-textual-native and aeson-native are being deprecated
Hi all, In the last Yesod release, we created two new packages: blaze-textual-native and aeson-native. These were direct forks of their source packages, with just two changes: blaze-textual-native did not include a double-conversion dependency, and aeson-native depended on blaze-textual-native instead of blaze-textual. The reason for all this is that there is a GHC bug which prevents C++ code from working correctly with GHCi and Template Haskell[1]. Bryan recently released a new version of blaze-textual which no longer uses double-conversion by default (it's still available with compile-time flags if you want the extra speed and don't need TH/GHCi), and as a result, we are very happy to be deprecating the native siblings. Fortunately, there are not that many packages on Hackage using these libraries; in fact, the only packages for which I'm not a maintainer are dingo-core, dingo-widgets and hledger-web. However, since these are Yesod dependencies, I'm guessing many Yesod users reference aeson-native in their site cabal files. Technically speaking, switching from aeson-native to aeson in a library should constitute a major version bump. However, in this case, I think we want these deprecated packages to die as quickly as possible. So my plan is to switch all of my packages from using aeson-native to aeson some time next week. The result will likely be broken builds for some people; all you'll need to do is edit your cabal file and replace aeson-native with aeson (likewise for blaze-textual). Are there any objections to this course of action, or better ideas on how to handle the situation? Michael [1] Please don't ask me for details, I don't know them. And for all I know, the bug has already be fixed in newer GHCs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
2011/11/25 Richard O'Keefe o...@cs.otago.ac.nz: I could never in my whole life draw as well as that. But they are *skittles*, just like Lamb Da. Cute. Stiff. Lifeless. Easy to knock over. Reminds me of a salt shaker and pepper pot of my mother's. The collar's good, but the lambda is just pasted on for no intrinsic reason. I agree with you but it was drawn by my sister and she thought that the lambda and other expressions just must be on the mascot. I think she didn't have any idea where to draw it :) How about a relatively smart animal _in motion_ with the lambda formed naturally by the positions of its limbs? Maybe a leaping gelada with its hind legs forming the \ of the lambda and its tail and back forming the / ? Smart, social, moving, and of course, furry. OK, I will send her your idea. Best, Karol Samborski ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
