- Haskell-Cafe - Haskell.org

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 04 Mar '14

04 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 04 Mar '14

04 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

Type checking string literal in Haskell?
by KwangYul Seo 03 Mar '14

03 Mar '14

In Java, the Checker Framework ( http://types.cs.washington.edu/checker-framework/) provides a way to type check string literals. For example, Java signatures type system differentiates strings literals in different forms: 1. Unqualified strings : "Hello, world!" -> @Unqualified String 2. Fully qualified names: "package.Outer.Inner" -> @FullyQualifiedString String 3. Binary names: "package.Outer$Inner" -> @BinaryName String 4. Field descriptors: "Lpackage/Outer$Inner;" -> @FieldDescriptor String It can do the similar checks with regular expressions or SQL statements. Is it possible to type check string literals in Haskell? I think it would be nice if we can check if a given string literal is a valid URL or an email address at compile time. Regards, Kwang Yul Seo

4 4

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 03 Mar '14

03 Mar '14

============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 30th April 2014 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year, but there is currently no common location in which to promote and advertise the resulting work. The Journal of Functional Programming would like to change that! As a service to the community, JFP is launching a new feature, in the form of a yearly publication of abstracts from PhD dissertations that were completed during the previous year. To start this new feature off, we would like to reach back three years for the first round of abstracts. The abstracts will be freely available on the JFP website, i.e. not behind any paywall, and will not require any transfer for copyright, merely a license from the author. Please submit dissertation abstracts according to the instructions below. A dissertation is eligible if parts of it have or could appear in JFP, that is, if it is in the general area of functional programming. JFP will not have these abstracts reviewed. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 30th April 2014. o Student: (full name) o Advisor/supervisor: (full names) o Dissertation title: (including any subtitle) o Dissertation abstract: (plain text, maximum 1000 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting in the abstract, but do get in touch if this causes significant problems) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Awarding institution: (full name and location) o Date of PhD award: (depending on the institution, this may be the date of the viva, date when corrections were approved, date of graduation ceremony, or otherwise) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kindgdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0