November 2012 - Haskell-Cafe

GHC for mobile devices?
by Andrew Pennebaker 12 Nov '12

12 Nov '12

I'd love to use Haskell directly for making mobiles apps. How can we make this happen, porting GHC to Android, iOS, and Windows Phone? -- Cheers, Andrew Pennebaker www.yellosoft.us

4 3

Re: [Haskell-cafe] Motion to unify all the string data types
by John Lato 12 Nov '12

12 Nov '12

> > From: Francesco Mazzoli <f(a)mazzo.li> > > At Sat, 10 Nov 2012 15:16:30 +0100, > Alberto G. Corona wrote: > > There is a ListLike package, which does this nice abstraction. but I > don't > > know if it is ready for and/or enough complete for serious usage. I?m > > thinking into using it for the same reasons. > > > > Anyone has some experiences to share about it? > > I've used it in the past and it's solid, it's been around for a while and > the > original author knows his Haskell. > > Things I don't like: > > * The classes are huge: > < > http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-Li… > >. > I'd much rater prefer to have all those utilities functions outside the > type > class, for no particular reason other then the ugliness of the type > class. > Speaking as the ListLike maintainer, I'd like this too. But it's difficult to do so without sacrificing performance. In some cases, sacrificing *a lot* of performance. So they have to be class members. However, there's no reason ListLike has to remain a single monolithic class. I'd prefer an API that's split up into several classes, as was done in Edison. Then 'ListLike' itself would just be a type synonym, or possibly a small type class with the appropriate superclasses. However this seems like a lot of work for relatively little payoff, which makes it a low priority for me. * It defines its own wrappers for `ByteString': > < > http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-Li… > >. > The community's view on newtypes is funny. On the one hand, I see all the time the claim "Just use a newtype wrapper to write instances for ..." (e.g. the recent suggestion of 'instance Num a => Num (a,a)'. On the other, nobody actually seems to want to use these newtype wrappers. Maybe it clutters the code? I don't know. I couldn't think of a better way to implement this functionality, patches would be gratefully accepted. Anyway, you really shouldn't use these wrappers unless you're using a ByteString to represent ASCII text. Which you shouldn't be doing anyway. If you're using a ByteString to represent a sequence of bytes, you needn't ever encounter CharString. > * It doesn't have instances for `Text', you have to resort to the > `listlike-instances' package. > Given that text and vector are both in the Haskell Platform, I wouldn't object to these instances being rolled into the main ListLike package. Any comments on this? John L.

2 2

Motion to unify all the string data types
by Andrew Pennebaker 12 Nov '12

12 Nov '12

Frequently when I'm coding in Haskell, the crux of my problem is converting between all the stupid string formats. You've got String, ByteString, Lazy ByteString, Text, [Word], and on and on... I have to constantly lookup how to convert between them, and the overloaded strings GHC directive doesn't work, and sometimes ByteString.unpack doesn't work, because it expects [Word8], not [Char]. AAAAAAAAAAAAAAAAAAAH!!! Haskell is a wonderful playground for experimentation. I've started to notice that many Hackage libraries are simply instances of typeclasses designed a while ago, and their underlying implementations are free to play around with various optimizations... But they ideally all expose the same interface through typeclasses. Can we do the same with String? Can we pick a good compromise of lazy vs strict, flexible vs fast, and all use the same data structure? My vote is for type String = [Char], but I'm willing to switch to another data structure, just as long as it's consistently used. -- Cheers, Andrew Pennebaker www.yellosoft.us

7 7

Re: [Haskell-cafe] GHC for mobile devices?
by Casey Basichis 11 Nov '12

11 Nov '12

I've been looking for the last two days through every nook and cranny of google to find information about building for iOS. It seems to be the case that it was once possible to get ios running and now its a bit questionable. I've tried ghc-ios, ghc-iphone and a few others which are all somewhat out of date. If anyone has any experience on that platform I would greatly appreciate some guidance in getting it up and running. As for you notion of "hard truth," and "dumb apps acting as web front ends" its pretty blase to assume that anyone interested in this thread will share that perspective in terms of their own goals on these platforms. I compose professionally on my phone, its certainly not a toy for my purposes. I also have no interest whatsoever in getting Cocoa commands into Haskell. I just want a functional way of working with data. I would greatly prefer to go the Haskell route, but have been considering OCaml as well as they seem to have an active and enthused interest in iOS. I would love a bit of perspective on whether OCaml would be worth pursing in the long run for the short term benefit of having a more mature mobile implementation.' Thanks, Casey >Yes, I've seen some of the work done on this and I think he's also >looked into OCaml on Android. > >To be completely honest it's not really the language that's such the >barrier: the hard truth is that any Android app doing anything of >interest is necessarily going to be using the Android framework. >Android programming (at least, presubaly iOS too) is not a lot of >advanced construction, it's mostly dumb apps acting as web frontends, >I'd posit that this is probably why people have been mostly content >with the Android API for so long anyway. > >So the main barrier is being able to interface with the Java side of >things (obviously) in a way that doesn't completely kill perf either >(this sounds nontrivial...). Then you need to give a sane >reimplementation of the Android API within Haskell. > >kris -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasichis(a)gmail.com 310.387.7540

3 6

size of Haskell Platform
by Doug McIlroy 11 Nov '12

11 Nov '12

This note is an offshoot of "curl package broken in Windows", where this item appeared: > Did you know that Strawberry Perl includes a cygwin gcc? > ... > Maybe Haskell Platform could do the same. The suggestion brought to mind a true-life parable: the pump station at Tok. (Tok is the third corner--after Anchorage and Fairbanks--of Alaska's triangular core of long-distance highways.) When I visited Tok long ago, it was a village of several hundred souls, almost all of whom were employed by one government agency or another, principal among which were the highway department, the Alaska Communication Service and the pump station, which kept fuel flowing to Eielson Air Force Base. The mission of the station was to keep one pump running 24 hours a day. Most of the time, of course, the pump hummed along by itself. To assure that, there had to be a standby machine, an operator to watch over both, and a mechanic who could fix them if need be. For such a lonely job it was deemed well to have two operators. And there had to be two operators for each of several shifts. A little redundancy on the mechanical side seemed wise, too. The crew and their families, say nothing of the pumps themselves, needed to be housed, and the installation needed to be supplied with the necessities of life. (The nearest supermarket was in Fairbanks, 300 miles away.) These needs demanded a motor pool and property maintenance cadre, whose very presence reinforced the need. Thus the support team to keep one pump going ballooned to about 100 people--a chain reaction that barely avoided criticality. So it seems to be with Haskell Platform, which aims to include "all you need to get up and running"--"an extensive set of standard libraries and utilities with full documentation." I get the impression that the Platform is bedeviled by the same prospect of almost unfettered growth. [One ominous sign: the description of the Haskell Platform at lambda.haskell.org/platform/doc/current/start.html suggests that one must join some mysterious Cabal, whose nature is hidden by a link to nowhere, simply to get started.] What principles guide the selection of components for "all you need to get up and running"? Doug McIlroy

4 3

Not exporting a class
by Joachim Breitner 11 Nov '12

11 Nov '12

Hi, dear package authors. If you define a useful class, please think twice before you do not export the methods, otherwise something like this will happen: Am Samstag, den 10.11.2012, 21:39 -0800 schrieb David Fox: > It looks like there is an export copy of the whole prettyprint system > in template-haskell. I could switch over to that. Oh, and another > one in uulib. And also in ansi-wl-pprint. I think I will switch to > this last one. > > On Sat, Nov 10, 2012 at 6:17 PM, David Fox <dsf(a)seereason.com> wrote: > It may belong in Text.PrettyPrint. > > On Sat, Nov 10, 2012 at 6:16 PM, David Fox <dsf(a)seereason.com> > wrote: > About as small as a package can get! Yeah, the Pretty > class is in haskell-src, but they don't export the > pretty method. I will drop them a line, but I sort of > assumed they had a reason for doing it that way > > > On Thu, Nov 8, 2012 at 2:02 PM, Joachim Breitner > <mail(a)joachim-breitner.de> wrote: > Hi David, > > your pretty-class package is pretty small. In > the interest of preventing > package proliferation: Have you talked to the > maintainers of pretty or > haskell-src-exts whether they’d include the > class in their code? Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 1

Re: [Haskell-cafe] curl package broken in Windows
by Andrew Pennebaker 10 Nov '12

10 Nov '12

Yes, that's a very good point. Did you know that Strawberry Perl includes a cygwin gcc? http://strawberryperl.com Maybe Haskell Platform could do the same. On Nov 10, 2012 5:28 PM, "Stephen Tetley" <stephen.tetley(a)gmail.com> wrote: > The only short cut would be to have it in the Platform - otherwise it > is DIY I'm afraid. > > This is as much Microsoft's "fault" as Haskell's for not providing a C > compiler, build tools etc. in the baseline environment. >

1 0

Profiling a project with cabal and cabal-dev
by Mike Craig 10 Nov '12

10 Nov '12

Hi all, So I've been working on a project and I'd like to run it with profiling to diagnose the performance hotspots. It's a cabal project and I've been using cabal-dev for sandboxing. Normally I would just run `cabal-dev install` to get everything built and the executables "installed" in ./cabal-dev/bin. Since I want to compile with profiling, I tried this: $ cabal-dev install enable-executable-profiling The build fails with an error log that includes something like "Perhaps you haven't installed the profiling libraries for package `http-types-0.7.3.0.1'?" If I then try ... $ cabal-dev install -p --reinstall --force-reinstalls http-types-0.7.3.0.1 ... I find myself walking down the dependency tree. (http-types -> case-insensitive -> hashable -> etc.) Presumably this would eventually walk me out of the sandbox and I would be reinstalling the base libraries in my sandbox with profiling enabled. This doesn't seem right. (And if it is right, it doesn't seem like I should have to do it manually, package by package.) What am I doing wrong? Cheers, Mike

3 3

Re: [Haskell-cafe] Motion to unify all the string data types
by Tobias Brandt 10 Nov '12

10 Nov '12

On 10 November 2012 04:00, Johan Tibell <johan.tibell(a)gmail.com> wrote: > As for type classes, I don't think we use them enough. Perhaps because > Haskell wasn't developed as an engineering language, some good software > engineering principles (code against an interface, not a concrete > implementation) aren't used in out base libraries. One specific example is > the lack of a sequence abstraction/type class, that all the string, list, > and vector types could implement. Right now all these types try to > implement a compatible interface (i.e. the traditional list interface), > without a language mechanism to express that this is what they do. > Data.Collections<http://hackage.haskell.org/packages/archive/collections-api/1.0.0.0/doc/htm…> has (among others) a Sequence type class and provides instances for the base data types in a separate package. However, it appears that not many people are using it.

1 0

Computed promoted natural
by Arie Peterson 10 Nov '12

10 Nov '12

Hi, I'm trying to use data kinds, and in particular promoted naturals, to simplify an existing program. The background is as follows: I have a big computation, that uses a certain natural number 'd' throughout, which is computed from the input. Previously, this number was present as a field in many of my data types, for instance > data OldA = OldA Integer … . There would be many values of this type (and others) floating around, with all the same value of 'd'. I would like to move this parameter to the type level, like this: > data NewA (d :: Nat) = NewA … The advantage would be, that the compiler can verify that the same value of 'd' is used throughout the computation. Also, it would then be possible to make 'NewA' a full instance of 'Num', because 'fromInteger :: Integer -> NewA d' has a natural meaning (where the value of 'd' is provided by the type, i.e. the context in which the expression is used), while 'fromInteger :: Integer -> OldA' does not, because it is not possible to create the right value of 'd' out of thin air. Is this a sane idea? I seem to get stuck when trying to /use/ the computation, because it is not possible to create 'd :: Nat', at the type level, from the computed integer. Can one somehow instantiate the type variable 'd :: Nat' at an integer that is not statically known? Formulated this way, it sounds like this should not be possible, because all types are erased at compile time. However, it feels as though it might not be unreasonable in this situation, because the computation is polymorphic in the type 'd :: Nat'. I just want to substitute a specific value for 'd'. Maybe there is another way to approach this? Thanks for any advice, Arie

3 7