- Haskell-Cafe - Haskell.org

Request for maintainer(s) : language-javascript / hjsmin
by Alan & Kim Zimmerman 08 Jul '15

08 Jul '15

Hi all I am the author of language-javascript and its companion hjsmin. Unfortunately I do not use the libraries myself, and I am falling behind in maintaining them, all the more so with the new ECMASCRIPT spec out. So I am calling for volunteers to take over maintenance of these two packages. Regards Alan

4 8

ambiguous module name Network.URI
by Kees Bleijenberg 08 Jul '15

08 Jul '15

If i import these 2 packages in a project: import Network.HTTP import qualified Network.URI as NU I get: testNetw.hs:7:18: Ambiguous module name `Network.URI': it was found in multiple packages: network-uri-2.6.0.3 network-2.4.2.3 I'am using the latest 32 bits haskell platform on Windows 7 64 bits. I need the NU.parseURI function. What can I do? Kees

2 1

References on haskellwiki
by Alexis Praga 07 Jul '15

07 Jul '15

Hi, I've begun to do some formatting on old Monad Readers editions on Haskell Wiki. Unfortunately, there is no support for proper references support. Can the admin add the "Cite" extension ? It would help a lot. Thanks -- Alexis Praga, PhD Student (CERFACS) GPG key : AD4A AF6D BB5C 042F 9422 1223 06E1 C1BF E287 65D0

2 2

The world actually IS insane.
by Stefan Reich 07 Jul '15

07 Jul '15

So if I think "hey, these people are insane and I'm not" - I'm actually right. Because I woke up from insanity. Come join me, it's better here. You lose the pain. Cheers Stefan PS: Somebody now tell me that "this list is only for Haskell!!11!!!", once again proving your insanity. :)

2 1

The sad thing is, you don't see the new stuff.
by Stefan Reich 07 Jul '15

07 Jul '15

Haskell was - maybe - the most elegant mathematical logic-oriented language out there. It's why I used it. Now there is my approach, which is reciprocal simplification of the programming process. THAT is elegant. Cheers

1 0

Symmetric Difference for Data.Set and Data.IntSet?
by Zemyla 07 Jul '15

07 Jul '15

Could this be implemented as a primitive? I know it can be made from union and difference, or doing toList on both of them, taking the symmetric difference, and using fromDistinctAscList on the result, but it'd probably be much faster if it could be done natively, like can be done with Data.Map.mergeWithKey. Alternatively, could we get a merge interface for Set and IntSet roughly matching Map and IntMap?

5 4

Strange "ambiguity" problems thanks to GADTs
by wren romano 07 Jul '15

07 Jul '15

Hi all, In my latest project I've been using a bunch of GADTs, which unfortunately disables let-polymorphism (i.e., where-polymorphism) in the most annoying way. For the most part I've been able to hack around that limitation via judicious use of ScopedTypeVariables, but I've run into an issue that I can't for the life of me figure out why GHC doesn't like it. I have something like the following function, where @a@ and @b@ happen to be GADTs: foo :: (A a, B b) => a i -> M (b i) foo a = case view a of ... SomePattern a1 a2 -> do b1 <- foo a1 b2 <- foo a2 return . unview $ SomePattern b1 b2 It seems to me that the recursive calls should work just fine, using the same @b@ as we'll ultimately be returning. However, for some reason GHC complains about the recursive calls using some other @b0@ can can't deduce @B b0@ from @B b@. Why doesn't GHC unify these two types? How can I force them to unify without adding type annotations at every recursive call? -- Live well, ~wren

2 1

stm onCommit
by Silvio Frischknecht 06 Jul '15

06 Jul '15

I need a onCommit functionality for stm. I know there is the stm-io-hooks [1] package. But it seems so big for such a small thing and then I have to translate everything to their monad. lift lift lift ... So I thought of a little hack to solve the issue and I'm wondering if this is safe to use. My understanding of stm internals is very limited. It's basically just a TChan with IO actions in it and there is another thread waiting to execute anything inserted into it. import Control.Concurrent.STM.TChan onCommitChan :: TChan (IO ()) {-# NOINLINE onCommit #-} onCommitChan = unsafePerformIO $ do chan <- newTChanIO forkIO $ forever $ atomically $ readTChan chan return chan onCommit :: IO () -> STM () onCommit = writeTChan onCommitChan It would be cool if an onCommit hook could be directly added to the stm package. Silvio [1] https://hackage.haskell.org/package/stm-io-hooks-1.0.1

5 9

OCL 2015: Final Call for Papers - Only 10 Days Left
by Achim D. Brucker 06 Jul '15

06 Jul '15

(Apologies for duplicates) If you are working on the foundations, methods, or tools for OCL or textual modelling, you should now prepare your submission for the OCL workshop! CALL FOR PAPERS 15th International Workshop on OCL and Textual Modeling Tools and Textual Model Transformations Co-located with ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS 2015) September 28th, 2015, Ottawa, Canada http://ocl2015.lri.fr Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but some of their features are difficult to formalize and lack the level of precision required to create complete and unambiguous specifications. Limitations of the graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. Topics of interest include (but are not limited to) =================================================== - Mappings between textual modeling languages and other languages/formalisms - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for -- validation, verification, and testing, -- model transformation and code generation, -- meta-modeling and DSLs, and -- query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports -- usage of textual modeling languages and tools in complex domains, -- usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks This year, we particularly encourage submissions describing tools that support - in a very broad sense - textual modeling languages (if you have implemented OCL.js to run OCL in a web browser, this is the right workshop to present your work) as well as textual model transformations. Venue ===== The workshop will be organized as a part of MODELS 2015 Conference in Ottawa, Canada. It continues the series of OCL workshops held at UML/MODELS conferences: York (2000), Toronto (2001), San Francisco (2003), Lisbon (2004), Montego Bay (2005), Genova (2006), Nashville (2007), Toulouse (2008), Denver (2009), Oslo (2010), Zurich (2011, at the TOOLs conference), 2012 in Innsbruck, 2013 in Miami, and 2014 in Valencia, Spain. Similar to its predecessors, the workshop addresses both people from academia and industry. The aim is to provide a forum for addressing integration of OCL and other textual modeling languages, as well as tools for textual modeling, and for disseminating good practice and discussing the new requirements for textual modeling. Workshop Format =============== The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. Submissions =========== Three types of papers will be considered: * short papers (between 6 and 8 pages) describing ideas, * tool papers (between 6 and 8 pages), and * full papers (between 12 and 16 pages) in LNCS format. Submissions should be uploaded to EasyChair (https://easychair.org/conferences/?conf=ocl20150) The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online in a pre-conference edition of CEUR (http://www.ceur-ws.org) Important Dates =============== Submission of papers: July 17, 2015 Notification: August 21, 2015 Workshop date: September 28, 2015 Organizers ========== Achim D. Brucker, SAP SE, Germany Marina Egea, Indra Sistemas S.A., Spain Martin Gogolla, University of Bremen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Programme Committee =================== Mira Balaban, Ben-Gurion University of the Negev, Israel Tricia Balfe, Nomos Software, Ireland Achim D. Brucker, SAP SE, Germany Fabian Buettner, Inria - Ecole des Mines de Nantes, France Jordi Cabot, Inria - Ecole des Mines de Nantes, France Dan Chiorean, Babes-Bolyai University, Romania Robert Clariso, Universitat Oberta de Catalunya, Spain Tony Clark, Middlesex University, UK Manuel Clavel, IMDEA Software Institute, Spain Carolina Dania, IMDEA Software Institute, Spain Birgit Demuth, Technische Universitat Dresden, Germany Marina Egea, Indra Sistemas S.A., Spain Geri Georg, Colorado State University, USA Martin Gogolla, University of Bremen, Germany Shahar Maoz, Tel Aviv University, Israel Istvan Rath, Budapest University of Technology and Economics, Hungary Bernhard Rumpe, RWTH Aachen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Claas Wilke, Technische Universitat Dresden, Germany Edward Willink, Willink Transformations Ltd., UK Burkhart Wolff, Univ. Paris-Sud - LRI, France Steffen Zschaler, King's College, UK -- Dr. Achim D. Brucker, SAP SE, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch/

1 0

Fwd: Efficient records with arbitrarily many fields [was: Extensible states]
by Alexander V Vershilov 06 Jul '15

06 Jul '15

(forgot to reply to cafe list Hi. You can take a look at vector-fixed-hetero [1], that can act as anonymous structure with arbitrary number of fields, convertion to and from datatypes with the same structure and many more features. It's missing field names though and syntactic sugar that 'records' package have. If you like to reinvent a wheel, then you can use following appoach: introduce some typelevel info data a :? (b :: Symbol) data FieldName (t :: Symbol) = FieldName introduce generic structure for records with any number of fiels newtype ARec (m :: [*]) = ARec { unRec :: Array Any } type instance TProxy (ARec m) = m type instance VProxy (ARec m) = ARec rerec :: ARec a -> ARec b rerec = ARec . unRec indexRec :: (KnownNat (FieldIndex name m), FieldType name m ~ a) => proxy name -> ARec m -> a indexRec name v = unsafeCoerce $ indexArray (unRec v) (fromIntegral (natVal (indexProxy name v))) updateRec :: (KnownNat (Length m), KnownNat (FieldIndex name m), FieldType name m ~ a) => proxy name -> a -> ARec m -> ARec m updateRec name b v = runST $ do out <- newArray len undefined copyArray out 0 (unRec v) 0 len writeArray out idx (unsafeCoerce b) ARec <$> unsafeFreezeArray out where idx = fromIntegral (natVal (indexProxy name v)) len = fromIntegral (natVal (lengthProxy v)) you'll need some typelevel magic for that: type family FieldType (n :: Symbol) m where FieldType n ((a :? n) ': z) = a FieldType n (b ': z) = FieldType n z type family FieldIndex (n::Symbol) m :: Nat where FieldIndex n ((a :? n) ': z) = 0 FieldIndex n ( b ': z) = 1 + FieldIndex n z indexProxy :: (KnownNat c, FieldIndex n m ~ c) => proxy1 n -> proxy2 m -> Proxy c indexProxy _ _ = Proxy type family Length m where Length '[] = 0 Length (x ': xs) = 1 + Length xs lengthProxy :: (KnownNat c, Length n ~ c) => proxy n -> Proxy c lengthProxy _ = Proxy then you can implement lenses: instance (KnownNat (FieldIndex n m), KnownNat (Length m), FieldType n m ~ a) => HasField (n :: Symbol) (ARec m) a where getField = indexRec updateField p = flip (updateRec p) fieldLens' :: (HasField name z a, FieldType name (TProxy z) ~ a) => FieldName name -> Lens z z a a fieldLens' name = \f m -> fmap (updateField name m) (f $ getField name m) type family UpdateType (n :: Symbol) z a b where UpdateType n ((a :? n) ': z ) a b = (b :? n) ': z UpdateType n ( z ': zs) a b = z ': UpdateType n zs a b fieldLens :: ( ARec m ~ z, ARec m' ~ z', m' ~ UpdateType name m a b , FieldType name m ~ a, FieldType name m' ~ b , KnownNat (FieldIndex name m), KnownNat (FieldIndex name m') , KnownNat (Length m), KnownNat (Length m') ) => FieldName name -> Lens z z' a b fieldLens name = \f m -> fmap (updateField name (rerec m)) (f $ getField name m) this approach is more or less the same as records package with only one datastructure and almost the same syntactic sugar can be applied, the only missing thing is that pattern matching will be more difficult that with records. At this point it's not possible to write strict fields, but it can be easily extended. If someone is interested in this sort of wheel, I can prepare a package and some docs about and with coercion with other solutions like fixed-vector-hetero and records. [1] https://hackage.haskell.org/package/fixed-vector-hetero On Sat, Jul 4, 2015, 16:08 Ben Franksen <ben.franksen(a)online.de> wrote: > > Marcin Mrotek wrote: > > Okay, perhaps I'm too newbie to understand the big picture, but it > > seems to me you can get either: > > > > a) O(1) access to any, arbitrarily selected (at runtime) field > > b) O(1) append > > > > I guess option a) is better performance-wise, as appending is usually > > done less often than selecting (an O(1) slice is already possible with > > independently typed regular Haskell records) but > > dependently-typed-list-based implementation, or at the very least > > Vinyl (I haven't ever used HList) has the advantage of being dead > > simple in both implementation and usage. I mean, with Vinyl, you can > > write manual recursion over Rec's like: > > > > foo :: Rec ... -> Rec ... > > foo RNil = ... > > foo (r :& rs) = ... > > > > whenever GHC's typechecker gives up and goes on a strike; and I dare > > to say, with commonly used record sizes (have you ever used a record > > with more than, let's say, 10 fields?) the speed tradeoff is not > > noticeable. > > While more than 10 fields in a record is uncommon for typical library APIs > and simple programs, real world projects can grow much larger records. One > example is configuration data for complex programs (like Darcs or even GHC) > with many options. It would be so nice if we could use record types for the > configuration! Another application could in control system toolkits like > EPICS [1], which currently has (actually: generates) C records with > potentially hundreds of fields. > > If lookup is / remains linear we can never efficiently support these kinds > of applications and that would be very sad. > > I think the most reasonable default is O(1) for lookup and O(n) for > extension, like in Nikita Volkov's record package. It is quite unfortunate > that this package limits the number of fields! If GHC would offer generic > support for tuples of arbitrary size (with the same efficiency as today) > this limitation could be avoided and all would be well. > > Cheers > Ben > > [1] http://www.aps.anl.gov/epics/ > -- > "Make it so they have to reboot after every typo." ― Scott Adams > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Alexander

3 5