Re: [Haskell-cafe] ANN: wizards-1.0: A High level, generic library for interrogative user interfaces
I know it's somewhat evil (:P), but I was unable to implement the subsumption constraints (:<:) in a way that avoided it. It's there because I'm (ab)using the type-class system to do computation (specifically an O(n) search though long chain of coproducts for a specific constructor). E.g, determining Foo :<: Bar :+: Foo :+: Baz. There may be a way to rearrange the type level stuff to make it go away, perhaps with some new type extensions in 7.4 that I haven't studied extensively yet. This is also a problem in Swierstra's original paper where he introduces this technique. In practice, it doesn't pose a problem, because you're not meant to define your own instances of :<: anyway, and you shouldn't care what order the constructors occur. Regards, Liam O'Connor On Sunday, 1 July 2012 at 6:37 PM, Krzysztof Skrzętnicki wrote: > Hello, > > This library looks very nice. Thank you for realeasing it! I realise it took > quite an effort to write it. > > Looking from examples on Github I noticed that you use > -XOverlappingInstances. Why do you need such extension? > > Best regards, > Krzysztof Skrzętnicki > > On Sun, Jul 1, 2012 at 10:17 AM, Liam O'Connor (mailto:lia...@cse.unsw.edu.au)> wrote: > > Hi all, > > > > wizards is an Haskell library designed for the quick and painless > > development of interrogative programs, which revolve around a "dialogue" > > with the user, who is asked a series of questions in a sequence much like > > an installation wizard. > > > > Everything from interactive system scripts, to installation wizards, to > > full-blown shells can be implemented with the support of wizards. > > > > It is developed transparently on top of a free monad (see Swierstra's > > excellent paper on this topic at > > http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf > > (http://www.cs.ru.nl/%7EW.Swierstra/Publications/DataTypesALaCarte.pdf)), > > which separates out the semantics of the program from the wizards > > interface. A variety of backends exist, including a full featured backend > > for Haskeline, a debug-friendly simpler implementation in terms of > > System.IO primitives, and a completely pure implementation modelled as a > > function from an input string to output. It is also possible to write your > > own backends, or extend the existing back-ends with new features. > > > > While both built-in IO backends operate on a console, there is no reason > > why wizards cannot also be used for making GUI wizard interfaces. > > > > The library is highly extensible - back-ends can be written or extended > > with the type system helpfully tracking what features are supported by > > which back-ends. > > > > Installation instructions and some educational examples are at the github > > page: > > > > https://github.com/liamoc/wizards > > > > Information on how to write backends or extend backends, as well as > > structured API documentation is available on Hackage: > > > > http://hackage.haskell.org/package/wizards > > > > (Or, you can just run cabal haddock to generate the documentation from the > > source). > > > > Regards, > > Liam O'Connor > > > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org (mailto: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] ANN: wizards-1.0: A High level, generic library for interrogative user interfaces
Hi all, wizards is an Haskell library designed for the quick and painless development of interrogative programs, which revolve around a "dialogue" with the user, who is asked a series of questions in a sequence much like an installation wizard. Everything from interactive system scripts, to installation wizards, to full-blown shells can be implemented with the support of wizards. It is developed transparently on top of a free monad (see Swierstra's excellent paper on this topic at http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf), which separates out the semantics of the program from the wizards interface. A variety of backends exist, including a full featured backend for Haskeline, a debug-friendly simpler implementation in terms of System.IO primitives, and a completely pure implementation modelled as a function from an input string to output. It is also possible to write your own backends, or extend the existing back-ends with new features. While both built-in IO backends operate on a console, there is no reason why wizards cannot also be used for making GUI wizard interfaces. The library is highly extensible - back-ends can be written or extended with the type system helpfully tracking what features are supported by which back-ends. Installation instructions and some educational examples are at the github page: https://github.com/liamoc/wizards Information on how to write backends or extend backends, as well as structured API documentation is available on Hackage: http://hackage.haskell.org/package/wizards (Or, you can just run cabal haddock to generate the documentation from the source). Regards, Liam O'Connor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell: hiding declarations
Perhaps try importing the huge module with lots of imports in another module, and then only export the ones you want. Cheers. ~Liam 2010/10/4 Vo Minh Thu : > 2010/10/4 Jonas Almström Duregård : >> Hi Café, >> >> I'm doing some code generation with Template Haskell that results in >> few hundred top level declaration, of which only 10 or so should >> actually be exposed to the user (the rest are only used by generated >> code). >> >> Since I cant splice stuff into the module header (i.e. into the export >> list), I cant think of a good way to hide the internal declarations. >> One way would be to put all the declarations into one or several >> where-clauses, but this doesn't work very well when several functions >> share the hidden declarations. Also I might want to hide a few data >> types. >> >> Does anyone have a clever solution? Has anyone had a similar problem >> (maybe TH needs to be extended with support for hidden declarations)? > > Maybe this, although I guess this is what you mean by "doesn't work very > well": > > (a,b,c,d,...) = (a,b,c,d,...) -- those areyour top-level declarations > where > a = ... > b = ... > c = ... > d = ... > ... > all you other code > > Cheers, > Thu > ___ > 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] Re: [web-devel] statically compiled css
@Michael: Have you seen the JSMacro package on hackage? I think it might be a better fit as it adds some nice syntactic goodies to JS in addition to variable interpolation. Cheers. ~Liam On 9 August 2010 22:59, Michael Snoyman wrote: > OK, I declare myself officially unable to make a decision on this one: > there's just too many good options ;). I beseech the community to aid me in > my plight, by taking a survey on the names available[1]. > > Michael > > [1] > https://spreadsheets.google.com/viewform?formkey=dHVOU2p6OVRkcWVQVG10d01OWk8yU2c6MQ > > > On Mon, Aug 9, 2010 at 8:19 AM, wren ng thornton wrote: > >> Alexander Dunlap wrote: >> >>> CaSSius and JSaesar? >>> >> >> +1 for Cassius. >> >> -- >> Live well, >> ~wren >> >> ___ >> 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
Re: [Haskell-cafe] [C Binding] Turning the mutable to immutable?
Making an immutable API from a mutable one generally damages performance (on von neumann architectures) somewhat, the goal is to minimize that impact. Cheers. ~Liam On 7 July 2010 19:40, Yves Parès wrote: > That's indeed an advice I've read [1]. > But wouldn't it damage the performances, since code will have to go through > an extra layer? > > [1] http://blog.ezyang.com/2010/06/principles-of-ffi-api-design > > 2010/7/7 Chris Eidhof >> >> On 5 jul 2010, at 23:48, Yves Parès wrote: >> >> > Hello, >> > >> > I don't know if some of you are familiar with the SFML library (stands >> > for Simple and Fast Multimedia Library) --> http://sfml-dev.org >> > As SDL, SFML is a 2D graphics library, but conversely to SDL it provides >> > a hardware-accelerated drawing, through OpenGL. >> > Well, I'm currently writing its Haskell binding, and I'm stuck with >> > design issues. >> > What I'm heading to is a full IO binding, and that's what I'd like to >> > avoid. >> >> Have you considered writing a low-level binding and building a high-level >> library on top of that? >> >> -chris > > ___ > 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] Type-Level Programming
We most certainly do have type-level functions. See type families. Cheers. ~Liam On 26 June 2010 17:33, Jason Dagit wrote: > > > On Sat, Jun 26, 2010 at 12:27 AM, Jason Dagit wrote: >> >> >> On Sat, Jun 26, 2010 at 12:07 AM, Andrew Coppin >> wrote: >>> >>> wren ng thornton wrote: And, as Jason said, if you're just interested in having the same programming style at both term and type levels, then you should look into dependently typed languages. >>> >>> Out of curiosity, what the hell does "dependently typed" mean anyway? >> >> The types can depend on values. For example, have you ever notice we have >> families of functions in Haskell like zip, zip3, zip4, ..., and liftM, >> liftM2, ...? >> Each of them has a type that fits into a pattern, mainly the arity >> increases. Now imagine if you could pass a natural number to them and have >> the type change based on that instead of making new versions and >> incrementing the name. That of course, is only the tip of the iceberg. >> Haskell's type system is sufficiently expressive that we can encode many >> instances of dependent types by doing some extra work. Even the example I >> just gave can be emulated. See this paper: >> http://www.brics.dk/RS/01/10/ >> Also SHE: >> http://personal.cis.strath.ac.uk/~conor/pub/she/ >> Then there are languages like Coq and Agda that support dependent types >> directly. There you can return a type from a function instead of a value. > > I just realized, I may not have made this point sufficiently clear. Much of > the reason we need to do extra work in Haskell to emulate dependent types is > because types are not first class in Haskell. We can't write terms that > manipulate types (type level functions). Instead we use type classes as > sets of types and newtypes/data in place of type level functions. But, in > dependently typed languages types are first class. Along this line, HList > would also serve as a good example of what you would/could do in a > dependently type language by showing you how to emulate it in Haskell. > Jason > ___ > 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] Type-Level Programming
I prefer Agda to Epigram, but different strokes for different folks.
In agda, you could define a list indexed by its size like this:
data Vec : (A : Set) → ℕ → Set where
[] : Vec A 0
_∷_ : ∀ {n : ℕ} → A → Vec A n → Vec A (1 + n)
So, we have a Vec data type, and on the type level it is a function
from some type A (which itself is of type Set) and a natural number
(the length) to a new type (of type Set).
The empty list is defined as a zero length vector, and cons therefore
increases the type-level length of the vector by one. Using this
method, Agda can be used to make a fully safe "head" implementation
that is statically verified not to crash:
head : ∀ { A : Set } { n : ℕ} → Vec A (1 + n) → A
head (x :: xs) = x
This uses the type system to ensure that the vector includes at least
one element.
Note that a similar thing can be achieved in Haskell with the right
extensions, however type-level naturals must be used:
data S n
data Z
data Vec a :: * -> * where
Empty :: Vec a 0
Cons :: a -> Vec a b -> Vec a (S b)
safeHead :: forall b. Vec a (S b) -> a
safeHead (Cons x xs) = x
(note: not tested)
The main difference here between Haskell and Agda is that the types
themselves are typed, and that the types contain real naturals not
fake ones like in Haskell
Cheers.
~Liam
On 26 June 2010 22:04, Andrew Coppin wrote:
> Tony Morris wrote:
>>
>> http://www.cs.nott.ac.uk/~txa/publ/ydtm.pdf
>>
>
> Ah yes, it was definitely Epigram I looked at. The intro to this looked
> promising, but by about 3 pages in, I had absolutely no clue what on Earth
> the text is talking about...
>
> ___
> 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] Type-Level Programming
It means that not only can values have types, types can have values. An example of the uses of a dependent type would be to encode the length of a list in it's type. Due to the curry-howard isomorphism, dependent types open the gateway for lots of type-level theorem proving. On 26 June 2010 17:07, Andrew Coppin wrote: > wren ng thornton wrote: >> >> And, as Jason said, if you're just interested in having the same >> programming style at both term and type levels, then you should look into >> dependently typed languages. > > Out of curiosity, what the hell does "dependently typed" mean anyway? > > ___ > 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] Mapping a list of functions
swing map :: forall a b. [a -> b] -> a -> [b] swing any :: forall a. [a -> Bool] -> a -> Bool swing foldr :: forall a b. b -> a -> [a -> b -> b] -> b swing zipWith :: forall a b c. [a -> b -> c] -> a -> [b] -> [c] swing find :: forall a. [a -> Bool] -> a -> Maybe (a -> Bool) -- applies each of the predicates to the given value, returning the first predicate which succeeds, if any swing partition :: forall a. [a -> Bool] -> a -> ([a -> Bool], [a -> Bool]) Essentially, the main use case seems to be transforming HOFs that operate on a list of values and a single function into HOFs that operate on a list of functions and a single value. Cheers. ~Liam On 19 June 2010 19:30, Limestraël wrote: > ??? > What does exactly swing do ? > > 2010/6/18 Bulat Ziganshin >> >> Hello Martin, >> >> Thursday, June 17, 2010, 11:02:31 PM, you wrote: >> >> > But what if I want to apply a list of functions to a single argument. I >> > can >> >> one more answer is "swing map": >> >> http://www.haskell.org/haskellwiki/Pointfree#Swing >> >> >> >> -- >> Best regards, >> Bulat mailto:bulat.zigans...@gmail.com >> >> ___ >> 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
Re: [Haskell-cafe] Re: How does one get off haskell?
One way to avoid explicit, per-type unmarshalling is to use the existentialquantification extension to make a box type that you can store in a map, thus producing a heterogenous map of any types (with constraints). Cheers. ~Liam On 19 June 2010 04:08, aditya siram wrote: > I've written code with less bugs in Haskell than any other language > I've used. And that's a credit to GHC and not because I'm a great > programmer. > > But I still don't know how to deal with the situation where you don't > have a clear picture of your data or heterogenous data that you are > wrapping up in a type just to make the compiler happy? > > Here's an example of the latter: I was writing some Haskell web app > code where continuations are used to compose multi-step web > transactions. The continuations were stored in a map keyed with a > unique session id and invoked when the user POST'ed back that session > id. The problem was that the map would only accept functions of one > intermediate type and one result type. So I had to marshall/unmarshall > all my functions to some common type (ContT () IO String in my case) > just so I could store it in the map - which felt kind of dirty. > > While pointers on this particular problem would be appreciated, I > think this is the kind of issue (needing to be flexible about data > types) is a stumbling block for many beginning Haskell programmers. > > -deech > > > On Fri, Jun 18, 2010 at 12:44 PM, Andy Stewart > wrote: >> "Edward Z. Yang" writes: >> >>> Excerpts from Bryan O'Sullivan's message of Fri Jun 18 13:16:58 -0400 2010: I'm inclined to disagree. It's precisely when the code is in a state of constant upheaval that I want the type system to be pointing out my dumb errors. >>> >>> In my experience, the type system has forced me to care about thing that I >>> don't want to care about (yet). It's a different mindset: in the words of >>> the >>> prototyper: being first is valued over being correct. >>> >>> This does mean that Haskell forces you to write long-term maintainable >>> code from the get-go, yes. :-) >> Haha, that's true. :) >> >> When i write Haskell code, it force me write *framework* code. >> >> Sometimes, i wrote dirty code quickly, >> Haskell will told me : >> >> "Hey, bad code! Rewrite it! I don't accept dirty code ... bla bla ...". >> >> Then i rewrite my code to make it flexible and maintainable. >> >> Once you build beautiful framework code, you will find your life is so >> simple. :) >> >> Cheers, >> >> -- Andy >> >> ___ >> 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] Strange GHC messages?
Hi all, I've got some strange GHC output that doesn't seem to be
affecting my program adversely but I thought I should post about it
cos it's disquieting
mkUsageInfo: internal name? r{tv aIR}
mkUsageInfo: internal name? s{tv aIS}
It seems to be complaining about this newtype declaration:
> newtype ThreadStateM r s v = ThreadState { unbox :: StateT s (ReaderT r IO) v
> }
>deriving (Monad, Functor, MonadIO, MonadState s, MonadReader r)
(uses newtype deriving)
I'm not sure what the problem here is?
Cheers.
~Liam
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Work on Video Games in Haskell
If you guys get a nice library layer going between the Java APIs and Android NDK Haskell, I would very much like it if you could post it up somewhere. I think the entire community could benefit. Cheers. ~Liam On 26 May 2010 19:51, Ryan Trinkle wrote: > Hi guys, > I don't think this licensing issue will be a problem for us. It's not clear > to me that our game violates this new term, and we certainly don't violate > any of the principles Steve Jobs used to justify it. If Apple wants to > reject our app, they already have a variety of excuses at their disposal, as > they've demonstrated on many occasions. Frankly, it'd be their loss; > Android is now the fastest-growing smartphone market, and we'll be more than > happy to focus on it (and other friendlier markets) if Apple's not > interested in having our product on their platform. > > Ryan Trinkle > iPwn Studios > On Wed, May 26, 2010 at 4:18 AM, Brandon S. Allbery KF8NH > wrote: >> >> On May 26, 2010, at 04:14 , David Virebayre wrote: >>> >>> On Wed, May 26, 2010 at 9:58 AM, Brandon S. Allbery KF8NH >>> wrote: You might want to reread that license agreement. Specifically: >>> >>> Ah, yes. Ouch, that's abusive. >>> Can they tell the difference though ? >> >> >> I suspect GHC-generated code is fairly distinctive even as machine code. >> But they don't have to go to that extent; all they have to do is use Google >> to find this thread. :( >> >> -- >> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com >> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu >> electrical and computer engineering, carnegie mellon university KF8NH >> >> >> >> ___ >> 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
Re: [Haskell-cafe] TDD in Haskell
QuickCheck is great for TDD. I have used it for such purposes. You literally encode the contract of the function as quickcheck properties. It's very lovely. Cheers. ~Liam > > > > On 25 May 2010 21:36, Ionut G. Stan wrote: >> Hi, >> >> I'm doing TDD in pretty much all of the languages that I know, and I want to >> introduce it early in my Haskell learning process. I wonder though, if >> there's some established process regarding TDD, not unit testing. >> >> I've heard of QuickCheck and HUnit, but I've also read that QuickCheck is >> used mostly for testing pure code, while HUnit for impure code? >> >> What framework lends itself better for writing tests before the actual >> production code? Can you point out to some resources regarding this? >> >> >> Oh, and a small off-topic question? Is it considered a good practice to use >> implicit imports in Haskell? I'm trying to learn from existing packages, but >> all those "import all" statements drive me crazy. >> >> Thanks, >> -- >> Ionuț G. Stan | http://igstan.ro >> ___ >> 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] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Ah, looks as though we'll have to write a C layer between Java and Haskell.. doing all of this in the FFI seems like hard: http://www.koushikdutta.com/2009/01/jni-in-android-and-foreword-of-why-jni.html Cheers. ~Liam On 19 April 2010 14:33, Liam O'Connor wrote: > Also worth mentioning that the Android docs explicitly warn against > "allocating frequently" suggesting reuse of objects is by far more > preferable than regularly allocating stuff. If we go the Dalvik/Java > route, then we'll have alot of work to do to make the GC work for us > nicely, whereas compiling to native code gives us full control. > > The problem (and why I believe compiling to Java would be better) is > that it is quite tedious and difficult to interact with Java APIs > using native code. You write a shell of your application in java and > put calls in to native code everywhere. It ruins alot of the glamor of > Haskelling for android. That said, if we can somehow expose some Java > functions to haskell (rather than the other way around) then we could > eventually write an android API library for native haskell, giving us > both the performance benefits and the android api. > > Cheers. > ~Liam > > > > On 19 April 2010 14:25, Liam O'Connor wrote: >> On 19 April 2010 05:29, Don Stewart wrote: >>> That's great info -- we do have an unregisterised ARM port of GHC in >>> Debian, iirc. (And the LLVM backend can generate ARM code too) >> >> >> Sounds good. With regards to LLVM, what dependencies does LLVM ARM >> code have? Android has gnu libraries not llvm, i don't know if that is >> okay. >> >> A superior approach would be to compile haskell to Java or Dalvik >> bytecode (or even JVM bytecode if it doesn't use any JIT features; >> then we can compile that to dalvik bytecode), but this is obviously >> more work if we already have an ARM port. >> >> Here's the docs about the ABI we need to conform to in order to use the NDK. >> >> -- snip -- >> >> This is the name of an ABI for ARM-based CPUs that support *at* *least* >> the ARMv5TE instruction set. Please refer to following documentation for >> more details: >> >> - ARM Architecture Reference manual (a.k.a ARMARM) >> - Procedure Call Standard for the ARM Architecture (a.k.a. AAPCS) >> - ELF for the ARM Architecture (a.k.a. ARMELF) >> - ABI for the ARM Architecture (a.k.a. BSABI) >> - Base Platform ABI for the ARM Architecture (a.k.a. BPABI) >> - C Library ABI for the ARM Architecture (a.k.a. CLIABI) >> - C++ ABI for the ARM Architecture (a.k.a. CPPABI) >> - Runtime ABI for the ARM Architecture (a.k.a. RTABI) >> >> - ELF System V Application Binary Interface >> (DRAFT - 24 April 2001) >> >> - Generic C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi.html) >> >> Note that the AAPCS standard defines 'EABI' as a moniker used to specify >> a _family_ of similar but distinct ABIs. Android follows the little-endian >> ARM GNU/Linux ABI as documented in the following document: >> >> http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf >> >> With the exception that wchar_t is only one byte. This should not matter >> in practice since wchar_t is simply *not* really supported by the Android >> platform anyway. >> >> This ABI does *not* support hardware-assisted floating point computations. >> Instead, all FP operations are performed through software helper functions >> that come from the compiler's libgcc.a static library. >> >> Thumb (a.k.a. Thumb-1) instructions are supported. Note that the NDK >> will generate thumb code by default, unless you define LOCAL_ARM_MODE >> in your Android.mk (see docs/ANDROID-MK.TXT for all details). >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Also worth mentioning that the Android docs explicitly warn against "allocating frequently" suggesting reuse of objects is by far more preferable than regularly allocating stuff. If we go the Dalvik/Java route, then we'll have alot of work to do to make the GC work for us nicely, whereas compiling to native code gives us full control. The problem (and why I believe compiling to Java would be better) is that it is quite tedious and difficult to interact with Java APIs using native code. You write a shell of your application in java and put calls in to native code everywhere. It ruins alot of the glamor of Haskelling for android. That said, if we can somehow expose some Java functions to haskell (rather than the other way around) then we could eventually write an android API library for native haskell, giving us both the performance benefits and the android api. Cheers. ~Liam On 19 April 2010 14:25, Liam O'Connor wrote: > On 19 April 2010 05:29, Don Stewart wrote: >> That's great info -- we do have an unregisterised ARM port of GHC in >> Debian, iirc. (And the LLVM backend can generate ARM code too) > > > Sounds good. With regards to LLVM, what dependencies does LLVM ARM > code have? Android has gnu libraries not llvm, i don't know if that is > okay. > > A superior approach would be to compile haskell to Java or Dalvik > bytecode (or even JVM bytecode if it doesn't use any JIT features; > then we can compile that to dalvik bytecode), but this is obviously > more work if we already have an ARM port. > > Here's the docs about the ABI we need to conform to in order to use the NDK. > > -- snip -- > > This is the name of an ABI for ARM-based CPUs that support *at* *least* > the ARMv5TE instruction set. Please refer to following documentation for > more details: > > - ARM Architecture Reference manual (a.k.a ARMARM) > - Procedure Call Standard for the ARM Architecture (a.k.a. AAPCS) > - ELF for the ARM Architecture (a.k.a. ARMELF) > - ABI for the ARM Architecture (a.k.a. BSABI) > - Base Platform ABI for the ARM Architecture (a.k.a. BPABI) > - C Library ABI for the ARM Architecture (a.k.a. CLIABI) > - C++ ABI for the ARM Architecture (a.k.a. CPPABI) > - Runtime ABI for the ARM Architecture (a.k.a. RTABI) > > - ELF System V Application Binary Interface > (DRAFT - 24 April 2001) > > - Generic C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi.html) > > Note that the AAPCS standard defines 'EABI' as a moniker used to specify > a _family_ of similar but distinct ABIs. Android follows the little-endian > ARM GNU/Linux ABI as documented in the following document: > > http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf > > With the exception that wchar_t is only one byte. This should not matter > in practice since wchar_t is simply *not* really supported by the Android > platform anyway. > > This ABI does *not* support hardware-assisted floating point computations. > Instead, all FP operations are performed through software helper functions > that come from the compiler's libgcc.a static library. > > Thumb (a.k.a. Thumb-1) instructions are supported. Note that the NDK > will generate thumb code by default, unless you define LOCAL_ARM_MODE > in your Android.mk (see docs/ANDROID-MK.TXT for all details). > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On 19 April 2010 05:29, Don Stewart wrote: > That's great info -- we do have an unregisterised ARM port of GHC in > Debian, iirc. (And the LLVM backend can generate ARM code too) Sounds good. With regards to LLVM, what dependencies does LLVM ARM code have? Android has gnu libraries not llvm, i don't know if that is okay. A superior approach would be to compile haskell to Java or Dalvik bytecode (or even JVM bytecode if it doesn't use any JIT features; then we can compile that to dalvik bytecode), but this is obviously more work if we already have an ARM port. Here's the docs about the ABI we need to conform to in order to use the NDK. -- snip -- This is the name of an ABI for ARM-based CPUs that support *at* *least* the ARMv5TE instruction set. Please refer to following documentation for more details: - ARM Architecture Reference manual(a.k.a ARMARM) - Procedure Call Standard for the ARM Architecture (a.k.a. AAPCS) - ELF for the ARM Architecture (a.k.a. ARMELF) - ABI for the ARM Architecture (a.k.a. BSABI) - Base Platform ABI for the ARM Architecture (a.k.a. BPABI) - C Library ABI for the ARM Architecture (a.k.a. CLIABI) - C++ ABI for the ARM Architecture (a.k.a. CPPABI) - Runtime ABI for the ARM Architecture (a.k.a. RTABI) - ELF System V Application Binary Interface (DRAFT - 24 April 2001) - Generic C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi.html) Note that the AAPCS standard defines 'EABI' as a moniker used to specify a _family_ of similar but distinct ABIs. Android follows the little-endian ARM GNU/Linux ABI as documented in the following document: http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf With the exception that wchar_t is only one byte. This should not matter in practice since wchar_t is simply *not* really supported by the Android platform anyway. This ABI does *not* support hardware-assisted floating point computations. Instead, all FP operations are performed through software helper functions that come from the compiler's libgcc.a static library. Thumb (a.k.a. Thumb-1) instructions are supported. Note that the NDK will generate thumb code by default, unless you define LOCAL_ARM_MODE in your Android.mk (see docs/ANDROID-MK.TXT for all details). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Our best bet is to compile to ARM native code and then use the NDK to talk to the Java APIs. Cheers. ~Liam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
