March 2014 - Haskell-Cafe

Re: [Haskell-cafe] Overcome type restrictions?
by Dušan Kolář 07 Mar '14

07 Mar '14

Well, for the case, we even do not need RankNTypes, as the type of the list is known, so newtype Wrap = Wrap { unwrap :: [Wrap] -> Wrap } wself (h:t) = unwr $ unwr h t will work, which is not too far from encoding function into data :-) This solution saves space, of course. Best regards, Dušan On 03/07/2014 10:35 AM, Tobias Brandt wrote: > The problem is, that the type parameter 'a' of the functions in the > list is fixed. You can work around that with RankNTypes: > > newtype Wrap = Wrap { unwrap :: forall a. [a] -> a } > > unwrap $ (\(h:t) -> (unwrap h) t) [Wrap head, Wrap last] > > This specializes the type of the functions at every point of use > separately. > > > On 7 March 2014 09:14, Kolář Dušan <kolar(a)fit.vutbr.cz > <mailto:kolar@fit.vutbr.cz>> wrote: > > Well my fault, the example should have been like this: > > We have and error of infinite type for > Prelude> :t ((\(h:t) -> h t) [head, last, head, last, head, last]) > > Of course, head and tail are incompatible on type level... > > Dušan > > > > On Fri, 07 Mar 2014 07:57:09 +0100, Kolář Dušan > <kolar(a)fit.vutbr.cz <mailto:kolar@fit.vutbr.cz>> wrote: > > : > : > > But we have an error of infinite type construction for > > Prelude> :t ((\(h:t) -> h t) [head,tail, head, tail, head, > tail]) > > Well I can overcome this by encoding functions into data > types and then performing "conversion" back and forth, > nevertheless, is there any way how to overcome this? > > > It seems like you need heterogenous collections[0] > > Regards, > Henk-Jan van Tuyl > > > [0] http://www.haskell.org/haskellwiki/Heterogenous_collections > > > -- > Folding@home > What if you could share your unused computer power to help > find a cure? In just 5 minutes you can join the world's > biggest networked computer and get us closer sooner. Watch the > video. > http://folding.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org <mailto:Haskell-Cafe@haskell.org> > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

SystemF, universal quantification, and rigid type variables
by David Rush 07 Mar '14

07 Mar '14

In short, I'm trying to decide if there is a real difference between the types: (forall a.a) -> b a -> b and frankly, I'm not seeing a difference. But ghc apparently does *SystemF.Tests> :t ((\u (x::forall a. a) y -> u x y) (\x y -> y)) True <interactive>:1:49: Couldn't match type `a' with `Bool' `a' is a rigid type variable bound by a type expected by the context: a at <interactive>:1:1 In the second argument of `\ u (x :: forall a. a) y -> u x y', namely `True' In the expression: ((\ u (x :: forall a. a) y -> u x y) (\ x y -> y)) True *SystemF.Tests> Since this is a 'rigid type variable' complaint, I am inclined to think that this is a limitation of ghc, rather than a particular issue with the logic of System F. I'd actually love to be wrong. Is there an actual difference between the types? - david rush

3 3

Overcome type restrictions?
by Kolář Dušan 07 Mar '14

07 Mar '14

Hello Café, Is there any way to overcome this other way then by introducing some helper data types etc. etc.? We have: Prelude> :t ([head, last, head, last, head, last]) ([head, last, head, last, head, last]) :: [[a] -> a] Prelude> :t (\(h:t) -> head t) (\(h:t) -> head t) :: [a] -> a Prelude> :t ((\(h:t) -> head t) [head, last, head, last, head, last]) ((\(h:t) -> head t) [head, last, head, last, head, last]) :: [a] -> a But we have an error of infinite type construction for Prelude> :t ((\(h:t) -> h t) [head,tail, head, tail, head, tail]) Well I can overcome this by encoding functions into data types and then performing "conversion" back and forth, nevertheless, is there any way how to overcome this? My real problem is not about head/tail, but head/tail is the simplest way how to explain. Thanks for any references, Dušan

5 6

gloss-raster: Couldn't figure out LLVM version! (osx 10.8.5)
by Miro Karpis 06 Mar '14

06 Mar '14

Hi, please can you help me with following: I'm unable to install gloss-raster. Output is: dev$ cabal install gloss-raster Resolving dependencies... Configuring gloss-raster-1.8.1.2... Building gloss-raster-1.8.1.2... Preprocessing library gloss-raster-1.8.1.2... [1 of 2] Compiling Graphics.Gloss.Raster.Array ( Graphics/Gloss/Raster/Array.hs, dist/build/Graphics/Gloss/Raster/Array.o ) <no location info>: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt Failed to install gloss-raster-1.8.1.2 cabal: Error: some packages failed to install: gloss-raster-1.8.1.2 failed during the building phase. The exception was: ExitFailure 1 llvm seems to be installed: $ brew install llvm Warning: llvm-3.3 already installed cheers, m.

5 6

Short survey re: use of haskell.org funds to drive development -- please help!
by Brent Yorgey 06 Mar '14

06 Mar '14

The haskell.org committee is trying to figure out how to use some of its newfound power (the Power of Collecting Money) to best benefit the open-source Haskell community. You can help us by filling out a very short survey (it should only take you about 5 minutes): https://docs.google.com/forms/d/1rEobhHwFpjzPnra9L1TmrozWNFFyAVNPmdUMCcT--3… Please do fill it out, especially if you have opinions about what parts of the Haskell open-source world need more work, and could benefit by having some people paid to work on them. Thanks! -Brent, for the haskell.org committee

2 2

question about show
by k＠ioctl.it 06 Mar '14

06 Mar '14

Hello! I'm sure this has been answered many times before, but I can't find an explanation for this behavior anywhere. The question I have is a general one regarding 'show'. Why does main = do putStrLn "ü" ➜ ~ runhaskell test.hs ü and: main = do putStrLn $ show "ü" ➜ ~ runhaskell test.hs "\252" Thank you all for an enlightening answer already! Best, k

8 10

In Windows, it is better to install development environments outside of the Programs Files folder ...
by KC 06 Mar '14

06 Mar '14

In Windows, it is better to install development environments outside of the Programs Files folder because Windows has protections on that folder plus some other folders. I suppose another alternative is to use the Wubi installer for Ubuntu or is there a better Linux one should be using. :) Oooops! The Wubi installer is not recommended for a computer sporting the Windows 8 logo or using UEFI firmware. -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey

1 0

2013.2 on Win8.1 64 bit
by james 04 Mar '14

04 Mar '14

Hi, Does the current latest Haskell Platform install on Win8.1? I don't seem to have luck. I have it installed on my portable, which runs Win7. On my desktop I have 8.1, and the installers asks me whether I want to stop and restart with elevated permissions. It does this however I start it, including from a command prompt running as administrator, or from the 'right click' run as administrator. Continuing then fails to write to Program Files (x86). Any ideas? James

2 2

question re: FFI and ensuring unwrapped values are present on stack
by Charles Strahan 03 Mar '14

03 Mar '14

Hello all, This is probably going to be a pretty niche question, but I'm hoping someone here can lend a hand. I'm working on a binding for the YARV Ruby VM, and I'm struggling to come up a with a good interop story with respect to its GC implementation. I have two options to prevent premature GC of Ruby object pointers: 1) Guarantee that the pointers reside on the stack or in registers, 2) or copy the pointer itself to another static area of memory and register that address with the GC. So, the big question is: is there a way to make #1 a reality, while operating in the IO monad? I can picture something like the following: newtype RValue = RValue (Ptr RValue) deriving (Storable) withObject :: IO RValue -- e.g. result of some ccall, or some further transformation thereof -> (RValue -> IO a) -- the RValue is now on the stack (or in a register), available for use without worry of premature GC -> IO a -- the result of computation With Haskell being a non-strict language, I understand that there are a lot of instances where a value could end up on the heap, with a thunk being passed via stack/registers. For my needs, I'd need some way to guarantee that the RValues being passed to and from withObject are at all times kept unwrapped and off the heap, and likewise within the second argument. Given my rather limited knowledge of Haskell (I've been programming in Haskell for about a month now), I think the best I can come up with is the second option suggested above: withObject :: (Ptr RValue -> IO ()) -- e.g. void some_fun(VALUE* out) {...} -> (RValue -> IO a) -- e.g. do something with `out` derefed -> IO a withObject f g = alloca $ \ptr -> do rb_gc_register_address ptr -- prevent GC f ptr -- call wrapped native function val <- peek ptr -- deref the VALUE* res <- g val -- pass to function rb_gc_unregister_address ptr -- clean up res So, while the above would work, it's really, really ugly (IMO). That, and I'd have to wrap all the native functions so that instead of returning VALUE, they'd write to some out ptr and return void. And there's the otherwise unnecessary alloca. I hope that was clear enough - any advice would be super duper appreciated! I'm assuming that there isn't a way I can get away with using the typical monadic bind syntax while keeping the RValues off the heap; if I'm wrong, and I can skip the whole withObject/HOF approach, I'd love to know it! I'm not (yet) familiar enough with the compiler / language spec to know about such guarantees, should they exist... - Charles

2 2

CFP: FHPC 2014: 3rd workshop on Functional High-Performance Computing [w/ICFP]
by Ryan Newton 03 Mar '14

03 Mar '14

===================================================================== CALL FOR PAPERS FHPC 2014 The 2nd ACM SIGPLAN Workshop on Functional High-Performance Computing Gothenburg, Sweden September 4, 2014 https://sites.google.com/site/fhpcworkshops/ Co-located with the International Conference on Functional Programming (ICFP 2014) Submission Deadline: Sunday, 15 May, 2014 (anywhere on earth) ===================================================================== The FHPC workshop aims at bringing together researchers exploring uses of functional (or more generally, declarative or high-level) programming technology in application domains where high performance is essential. The aim of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative specifications of computationally challenging problems can serve as maintainable and portable code that approaches (or even exceeds) the performance of machine-oriented imperative implementations. All aspects of performance critical programming and parallel programming are in-scope for the workshop, irrespective of hardware target. This includes both traditional large-scale scientific computing (HPC), as well as work targeting single node systems with SMPs, GPUs, FPGAs, or embedded processors. It is becoming apparent that radically new and well founded methodologies for programming such systems are required to address their inherent complexity and to reconcile execution performance with programming productivity. Every year, the FHPC workshop has an application area as a theme. Papers touching on this topic are especially encouraged, though all in-scope papers are welcomed. For FHPC 2014, the theme is "Heterogeneous computing". In the systems and parallelism communities, there has been a lot of work on programming systems with CPUs and GPUs (or other mixed parallel architectures), but in the programming languages community this idea has not received as much attention. At their best, high-level languages can have the degrees of flexibility necessary to abstract over platform differences. Proceedings: ============ Accepted papers will be published by the ACM and will appear in the ACM Digital Library. * Submissions due: Sunday, 15 May, 2014 (anywhere on earth) * Author notification: Friday, 15 June, 2014 * Final copy due: Sunday, 22 June, 2014 Submitted papers must be in portable document format (PDF), formatted according to the ACM SIGPLAN style guidelines (2 column, 9pt format). See http://www.sigplan.org/authorInformation.htm for more information and style files. Typical papers are expected to be 8 pages (but up to four additional pages are permitted). Contributions to FHPC 2014 should be submitted via Easychair, at the following URL: * https://www.easychair.org/conferences/?conf=fhpc14 The submission site is now open. The FHPC workshops adhere to the ACM SIGPLAN policies regarding programme committee contributions and republication. Any paper submitted must adhere to ACM SIGPLAN's republication policy. PC member submissions are welcome, but will be reviewed to a higher standard. http://www.sigplan.org/Resources/Policies/Review http://www.sigplan.org/Resources/Policies/Republication Travel Support: =============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page (http://www.sigplan.org/PAC.htm) Programme Committee: ==================== Mary Sheeran (co-chair), Chalmers University of Technology, SE Ryan Newton (co-chair), Indiana University, USA Lennart Augustsson, Standard Chartered Bank, UK Jost Berthold, University of Copenhagen, Denmark Guy Blelloch, Carnegie Mellon University, USA Marius Eriksen, Twitter, USA Clemens Grelck, University of Amsterdam, Netherlands Vinod Grover, Nvidia, USA Kevin Hammond, University of St. Andrews, UK Ben Lippmeier, University of New South Wales, Australia Liu (Paul) Hai, Intel, USA Rita Loogen, University of Marburg, Germany Greg Michaelson, Heriot-Watt University, UK Marc Pouzet, ENS Paris, France John Reppy, Univesity of Chicago, USA Tiark Rompf, Oracle Labs and EPFL, Switzerland Satnam Singh, Google, USA Dimitrios Vytiniotis, Microsoft Research, UK General Chairs: ==================== Jost Berthold University of Copenhagen

1 0