[Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool
I would like to propose the development of source code refactoring tool
that operates on Haskell source code ASTs and lets you formulate rewrite
rules written in Haskell.
Objective
-
The goal is to make refactorings easier and allow global code changes
that might be incredibly tedious to do in a non-automated way.
By making these transformations convenient, we can make it easier to
maintain clean code, add new features or clean up leftovers faster, and
reduce the fear and effort to upgrade to newer versions of packages and
APIs.
Transformations
---
First, here are a few operations you would use this tool for. Some of
them are common operations you would also do in other programming
languages, some are more specific to Haskell.
* Changing all occurrences of import Prelude hiding (catch) to import
qualified Control.Exception as E
* Replacing all uses of a function with that function being imported
qualified or the other way around
* Adding a field to data constructor a record, setting user-supplied
defaults for construction and destruction:
-- Suppose you want to change one of these
data User = User { name :: String, age :: Int }
data User = User String Int
-- into one of these
data User = User { name :: String, age :: Int, active :: Bool }
data User = User String Int Bool
-- the refactoring tool could perform, in all relevant locations:
show (User name age) = ...
show (User name age _) = ...
-- and also this transformation:
... u { name = deleted } ...
... u { name = deleted, active = False } ...
-- or equivalently with records.
-- Special cases could be taken care of as specified, such as
-- whenever an object of [this User type] has
--of its records passed into some function 'email', do this
--now only if the user is active, so modify all relevant code
--email (name u)
--to
--if (active u) then email (name u) else return ()
-- Other examples include adding a position counter to attoparsec.
* Adding a type parameter to a type
-- This happens a lot on monad transformer stacks, e.g.
newtype MyMonad a b c = MyMonad (ReaderT a (WriterT b ...
-- and as you would probably agree on, this is not the most
-- comfortable change to make; in big project this can mean
-- hour-long grinding.
-- It has also recently happened in the basic underlying types
-- of packages like conduit and pipes.
* Adding a new transformer around a monad
* Addressing problems like mentioned in
http://blog.ezyang.com/2012/01/modelling-io/:
There is one last problem with this approach: once the primitives
have been selected, huge swaths of the standard library have to be
redefined by “copy pasting” their definitions ...
* Extracting a value into a let or where clause
* Renaming a variable, and all its occurrences that are semantically
same variable (based on its scope)
* Changing the way things are done, such as:
* Replacing uses of fmap with $, also taking care of the
corresponding import, and such cases were partial application
is involved
* Replacing uses of when (isJust) to forM_
* Making imports clearer by adding all functions used to the file to the
import list of the module that gets them in scope
* Finding all places where an exported function does not have all its
arguments haddock-documented.
* Performing whole-project refactorings instead of operating on single
files only, allowing operations like
Find me all functions of this type, e.g.
Maybe a - (a - m a) - m a
in the project and extract them into this new module,
with the name 'onJust'.
Some of the problems above can be tried to address using regex-based
search and replace, but this already fails in the simplest case of
import Prelude hiding (catch) in case there is more than that imported
from Prelude or newlines involved in the import list.
Transformation on the AST are much more powerful, and can guarantee that
the result is, at least syntactically, valid. No text base tool can do that.
Other uses
--
In addition to being able to perform transformations as mentioned above,
the refactoring tool as a library can be leveraged to:
* Support or be the base of code formatting tools such as
haskell-stylish, linters, style/convention checkers, static analyzers,
test coverage tools etc.
* Implement automatic API upgrades.
Imagine the author of a library you use deprecates some functions,
introduces replacements, adds type parameters. In these cases, it is
very clear and often well-documented which code has to be replaced by
what. The library author could, along with the new release, publish
upgrade transformations that you can apply to your code base to save
most of the manual work.
These upgrade transformations could be either parts of the packages
themselves or be separately maintained and refined on the feedback of
users
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
I should add that as a consumer of Haddock documentation I can testify that fancier styling (in whatever format) would be of little benefit to _me_. What I need is more plain text and more examples. To be perfectly honest, most of the time when looking at a Haddock page, I end up clicking on the Source button because there are things I need to know that are in the source but not the documentation. So I do agree that markup that doesn't get in the way of a _reader_ who is looking at the source code is an excellent thing. I say this as someone who had to read some Java today and ended up stuffing it through a comment stripper so that I could easily find what I needed to find. This thread is not about the visually lightweight aspect of Markdown. That's a good thing. No argument there. The thread is about how well documented the notation should be. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partially applied data constructor and corresponding type
Thanks for pointing to type level integers. With that I have found: http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue5/Number_Param_Types For example: --- data Zero = Zero data Succ a = Succ a class Card c where c2num:: c - Integer cpred::(Succ c) - c cpred = undefined instance Card Zero where c2num _ = 0 instance (Card c) = Card (Succ c) where c2num x = 1 + c2num (cpred x) main = do putStrLn $ show $ c2num (Succ (Succ Zero)) --- I will continue to examine the topic in the following days, according to my needs. Thanks a lot, TP On Sunday, April 28, 2013 07:58:58 Stephen Tetley wrote: What you probably want are type level integers (naturals) Yury Sulsky used them in the message above - basically you can't use literal numbers 1,2,3,... etc as they are values of type Int (or Integer, etc...) instead you have to use type level numbers: data One data Two Work is ongoing for type level numbers in GHC and there are user libraries on Hackage so there is a lot of work to crib from. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool
On 29 Apr 2013, at 07:00, Niklas Hambüchen wrote: I would like to propose the development of source code refactoring tool that operates on Haskell source code ASTs and lets you formulate rewrite rules written in Haskell. Seen this? http://www.haskell.org/haskellwiki/HaRe Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool
* Niklas Hambüchen m...@nh2.me [2013-04-29 14:00:23+0800] I would like to propose the development of source code refactoring tool that operates on Haskell source code ASTs and lets you formulate rewrite rules written in Haskell. Hi Niklas, This is a great idea. I talked about it at HIW last year[1] and have been working on it since then. [1]: http://www.youtube.com/watch?v=Ae-6uIMQPmU 1. What you call a full-source AST is already present in haskell-src-exts (under Annotated subtree). It /almost/ satisfies pretty . parse = id, (one thing it fails to do is to preserve tabs), and fixing it should be definitely easier than starting from scratch. 2. HSE has two pretty-printers: an exact one, and one that ignores annotations and pretty-prints in its own style. It's important to have a mixture of both, so that we can pretty-print generated snippets and splice them into an already formatted AST. A friend of mine, Pavel Poukh, is working on a pretty-printer that produces an annotated tree instead of a flat string, and AFAIK that work is close to done. [2]: https://github.com/Pnom/haskell-ast-pretty 3. A major thing that I devoted my time to is name resolution and package management [3,4], which are necessary for the tool to work. [3]: https://github.com/feuerbach/haskell-names [4]: https://github.com/feuerbach/haskell-packages They are also close to done. 4. As for the tool itself, I have a crude prototype [5], but I haven't updated it for a while. [5]: https://github.com/feuerbach/hasfix 5. The user interface is, of course, an important topic by itself. I was thinking of something less expressive and more declarative, but your idea is also interesting. Let's discuss this separately. Regarding this topic as a GSoC project, I'm not so sure this is a good idea. As a past GSoC student myself, I feel that new projects (as opposed to established projects with existing user base and development team) have much greater risks. (This is also backed up by data [6].) But if you (or anyone else who happens to read this) would like to get involved, please get in touch with me! [6]: http://www.gwern.net/Haskell Summer of Code Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool
Hello Malcolm, no, I had indeed not seen this! Thanks for the link. It goes very much in the direction I was thinking of, but it does not seem to maintained and does not cabal install either. It also seems very much focused on interactive editor integration as compared to written-out transformations. Do you know to what extent they have built and a modification-friendly AST? Also, do you know if the people involved in this are still active in the community and interested in working further in this direction? Thanks Niklas On 29/04/13 15:36, Malcolm Wallace wrote: On 29 Apr 2013, at 07:00, Niklas Hambüchen wrote: I would like to propose the development of source code refactoring tool that operates on Haskell source code ASTs and lets you formulate rewrite rules written in Haskell. Seen this? http://www.haskell.org/haskellwiki/HaRe Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
I see the pluggable markup being pushed in this thread again. I just want to remind everybody that we currently have a flavor of a markup issue on github. The ghc source code uses literal haskell, and it does not work well on github. http://www.haskell.org/pipermail/ghc-devs/2013-April/001099.html Any markup that is not widely supported makes it harder for third parties to support and parse. The solution is *not* to reimplement github in haskell, but to standardize markup as much as possible. Pluggable markup makes the probability that a github-like service, IDEs and similar can make use of the documentation arbitrarily close to zero. Alexander On Mon, Apr 29, 2013 at 8:04 AM, Richard A. O'Keefe o...@cs.otago.ac.nzwrote: I should add that as a consumer of Haddock documentation I can testify that fancier styling (in whatever format) would be of little benefit to _me_. What I need is more plain text and more examples. To be perfectly honest, most of the time when looking at a Haddock page, I end up clicking on the Source button because there are things I need to know that are in the source but not the documentation. So I do agree that markup that doesn't get in the way of a _reader_ who is looking at the source code is an excellent thing. I say this as someone who had to read some Java today and ended up stuffing it through a comment stripper so that I could easily find what I needed to find. This thread is not about the visually lightweight aspect of Markdown. That's a good thing. No argument there. The thread is about how well documented the notation should be. ___ 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] GSoC proposal: Haskell AST-based refactoring and API upgrading tool
There is another aspect to this: How do you get maintainers to apply the patches? How should hackage be changed to accomodate large-scale refactorings? There was a discussion on this mailing list related to build regressions on GHC 7.6 last year. All of the regressions could be fixed using perl regexps, and it was only a few hours of work, much less than the work involved in the discussion itself. I downloaded all of hackage and did the fixes using perl. http://www.haskell.org/pipermail/haskell-cafe/2012-August/103155.html However, without the community infrastructure to actually apply the patches, the problem is not solved. I think this is mainly a community/organizational issue. Refactoring is not really the problem, but of course better refactoring abilities are good. Alexander On Mon, Apr 29, 2013 at 9:59 AM, Niklas Hambüchen m...@nh2.me wrote: Hello Malcolm, no, I had indeed not seen this! Thanks for the link. It goes very much in the direction I was thinking of, but it does not seem to maintained and does not cabal install either. It also seems very much focused on interactive editor integration as compared to written-out transformations. Do you know to what extent they have built and a modification-friendly AST? Also, do you know if the people involved in this are still active in the community and interested in working further in this direction? Thanks Niklas On 29/04/13 15:36, Malcolm Wallace wrote: On 29 Apr 2013, at 07:00, Niklas Hambüchen wrote: I would like to propose the development of source code refactoring tool that operates on Haskell source code ASTs and lets you formulate rewrite rules written in Haskell. Seen this? http://www.haskell.org/haskellwiki/HaRe Regards, Malcolm ___ 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] Markdown extension for Haddock as a GSoC project
On 29 April 2013 18:16, Alexander Kjeldaas alexander.kjeld...@gmail.com wrote: I see the pluggable markup being pushed in this thread again. I just want to remind everybody that we currently have a flavor of a markup issue on github. The ghc source code uses literal haskell, and it does not work well on github. http://www.haskell.org/pipermail/ghc-devs/2013-April/001099.html Any markup that is not widely supported makes it harder for third parties to support and parse. The solution is *not* to reimplement github in haskell, but to standardize markup as much as possible. Pluggable markup makes the probability that a github-like service, IDEs and similar can make use of the documentation arbitrarily close to zero. If it's pluggable, doesn't it make the situation _worse_, as you choose a plug-in that works with one service but then fails for all the others? I think this is a bit of a non-issue: services like github should _not_ mark-up documentation (as you're going to have some kind of issue where it's rendered when you didn't expect it or vice-versa, thus making it different to read the actual code). I tend to agree with Richard, etc.: I'd rather either extend the existing Haddock mark-up or choose a sane markup language if we wish to replace/augment it (I use markup, but find a lot of its conventions appalling). Alexander On Mon, Apr 29, 2013 at 8:04 AM, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: I should add that as a consumer of Haddock documentation I can testify that fancier styling (in whatever format) would be of little benefit to _me_. What I need is more plain text and more examples. To be perfectly honest, most of the time when looking at a Haddock page, I end up clicking on the Source button because there are things I need to know that are in the source but not the documentation. So I do agree that markup that doesn't get in the way of a _reader_ who is looking at the source code is an excellent thing. I say this as someone who had to read some Java today and ended up stuffing it through a comment stripper so that I could easily find what I needed to find. This thread is not about the visually lightweight aspect of Markdown. That's a good thing. No argument there. The thread is about how well documented the notation should be. ___ 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 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On Mon, 29 Apr 2013 18:04:47 +1200 Richard A. O'Keefe o...@cs.otago.ac.nz wrote: so that there is no possibility of catching errors early; by definition in that processor there are no errors. Haddock's markup isn't any better in that regard. I spent two hours on my first day with haddock figuring out that I needed an empty comment line before a code block. It didn't issue any warnings or errors either. To be perfectly honest, most of the time when looking at a Haddock page, I end up clicking on the Source button because there are things I need to know that are in the source but not the documentation. Besides fixities, orphan instances, type family instances and partially exported records? It would be beneficial of Haddock to list orphan instances on top of the page. In red. Iff adding markdown doesn't require a major restructuring of haddock, then a GSOC might be better spent adding support for all of these instead; someone else could add markdown later on their own after ML bikeshedding came to some conclusion. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool
Hi Niklas,
I haven't read the whole proposal as I'm short of time. But Alan
Zimmerman is doing a lot of work on integrating HaRe with the GHC API
[1]. He is alanz on freenode and a regular in #hspec.
I haven't looked at the code, but maybe it's of interest to you.
Cheers,
Simon
[1] https://github.com/alanz/HaRe/tree/ghc-api
On Mon, Apr 29, 2013 at 02:00:23PM +0800, Niklas Hambüchen wrote:
I would like to propose the development of source code refactoring tool
that operates on Haskell source code ASTs and lets you formulate rewrite
rules written in Haskell.
Objective
-
The goal is to make refactorings easier and allow global code changes
that might be incredibly tedious to do in a non-automated way.
By making these transformations convenient, we can make it easier to
maintain clean code, add new features or clean up leftovers faster, and
reduce the fear and effort to upgrade to newer versions of packages and
APIs.
Transformations
---
First, here are a few operations you would use this tool for. Some of
them are common operations you would also do in other programming
languages, some are more specific to Haskell.
* Changing all occurrences of import Prelude hiding (catch) to import
qualified Control.Exception as E
* Replacing all uses of a function with that function being imported
qualified or the other way around
* Adding a field to data constructor a record, setting user-supplied
defaults for construction and destruction:
-- Suppose you want to change one of these
data User = User { name :: String, age :: Int }
data User = User String Int
-- into one of these
data User = User { name :: String, age :: Int, active :: Bool }
data User = User String Int Bool
-- the refactoring tool could perform, in all relevant locations:
show (User name age) = ...
show (User name age _) = ...
-- and also this transformation:
... u { name = deleted } ...
... u { name = deleted, active = False } ...
-- or equivalently with records.
-- Special cases could be taken care of as specified, such as
-- whenever an object of [this User type] has
--of its records passed into some function 'email', do this
--now only if the user is active, so modify all relevant code
--email (name u)
--to
--if (active u) then email (name u) else return ()
-- Other examples include adding a position counter to attoparsec.
* Adding a type parameter to a type
-- This happens a lot on monad transformer stacks, e.g.
newtype MyMonad a b c = MyMonad (ReaderT a (WriterT b ...
-- and as you would probably agree on, this is not the most
-- comfortable change to make; in big project this can mean
-- hour-long grinding.
-- It has also recently happened in the basic underlying types
-- of packages like conduit and pipes.
* Adding a new transformer around a monad
* Addressing problems like mentioned in
http://blog.ezyang.com/2012/01/modelling-io/:
There is one last problem with this approach: once the primitives
have been selected, huge swaths of the standard library have to be
redefined by “copy pasting” their definitions ...
* Extracting a value into a let or where clause
* Renaming a variable, and all its occurrences that are semantically
same variable (based on its scope)
* Changing the way things are done, such as:
* Replacing uses of fmap with $, also taking care of the
corresponding import, and such cases were partial application
is involved
* Replacing uses of when (isJust) to forM_
* Making imports clearer by adding all functions used to the file to the
import list of the module that gets them in scope
* Finding all places where an exported function does not have all its
arguments haddock-documented.
* Performing whole-project refactorings instead of operating on single
files only, allowing operations like
Find me all functions of this type, e.g.
Maybe a - (a - m a) - m a
in the project and extract them into this new module,
with the name 'onJust'.
Some of the problems above can be tried to address using regex-based
search and replace, but this already fails in the simplest case of
import Prelude hiding (catch) in case there is more than that imported
from Prelude or newlines involved in the import list.
Transformation on the AST are much more powerful, and can guarantee that
the result is, at least syntactically, valid. No text base tool can do that.
Other uses
--
In addition to being able to perform transformations as mentioned above,
the refactoring tool as a library can be leveraged to:
* Support or be the base of code formatting tools such as
haskell-stylish, linters, style/convention checkers, static analyzers,
test coverage tools etc.
* Implement automatic API upgrades.
Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language
I've got ghc working here on a centos 5.5 machine. But without root privilege, I don't know how. Perhaps you can use a virtual machine with centos 5.5 (you'd have root access on this machine), install ghc on this machine, compile your programs there, then transfer that on the first computer ? 2013/4/27 Christopher Howard christopher.how...@frigidcode.com Hi. I've got this work situation where I've got to do all my work on /ancient/ RHEL5 systems, with funky software configurations, and no root privileges. I wanted to install GHC in my local account, but the gnu libc version is so old (2.5!) that I can't even get the binary packages to install. I've had success installing some other simple functional languages (like CLISP) on these same systems, so I was wondering if there was perhaps another language very similar to Haskell (but presumably simpler) with a super portable compiler easily built from source, which I could try. I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick description didn't make it sound much more portable than GHC, but I guess I could try it if I heard some good reasons to think it would be more portable. -- frigidcode.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
Re: [Haskell-cafe] partially applied data constructor and corresponding type
There's a lot of recent work on GHC that might be helpful to you. Is it
possible for your application to use GHC 7.6.x? If so, you could so something
like this:
{-# LANGUAGE DataKinds, GADTs, KindSignatures #-}
data Nat = Zero | Succ Nat
type One = Succ Zero
type Two = Succ One
type Three = Succ Two
-- connects the type-level Nat with a term-level construct
data SNat :: Nat - * where
SZero :: SNat Zero
SSucc :: SNat n - SNat (Succ n)
zero = SZero
one = SSucc zero
two = SSucc one
three = SSucc two
data Tensor (n :: Nat) a = MkTensor { dims :: SNat n, items :: [a] }
type Vector = Tensor One
type Matrix = Tensor Two
mkVector :: [a] - Vector a
mkVector v = MkTensor { dims = one, items = v }
vector_prod :: Num a = Vector a - Vector a
vector_prod (MkTensor { items = v }) = ...
specializable :: Tensor n a - Tensor n a
specializable (MkTensor { dims = SSucc SZero, items = vec }) = ...
specializable (MkTensor { dims = SSucc (SSucc SZero), items = mat }) = ...
This is similar to other possible approaches with type-level numbers, but it
makes more use of the newer features of GHC that assist with type-level
computation. Unfortunately, there are no constructor synonyms or pattern
synonyms in GHC, so you can't pattern match on MkVector or something similar
in specializable. But, the pattern matches in specializable are GADT
pattern-matches, and so GHC knows what the value of n, the type variable, is on
the right-hand sides. This will allow you to write and use instances of Tensor
defined only at certain numbers of dimensions.
I hope this is helpful. Please write back if this technique is unclear!
Richard
On Apr 29, 2013, at 2:55 AM, TP paratribulati...@free.fr wrote:
Thanks for pointing to type level integers. With that I have found:
http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue5/Number_Param_Types
For example:
---
data Zero = Zero
data Succ a = Succ a
class Card c where
c2num:: c - Integer
cpred::(Succ c) - c
cpred = undefined
instance Card Zero where
c2num _ = 0
instance (Card c) = Card (Succ c) where
c2num x = 1 + c2num (cpred x)
main = do
putStrLn $ show $ c2num (Succ (Succ Zero))
---
I will continue to examine the topic in the following days, according to my
needs.
Thanks a lot,
TP
On Sunday, April 28, 2013 07:58:58 Stephen Tetley wrote:
What you probably want are type level integers (naturals)
Yury Sulsky used them in the message above - basically you can't use
literal numbers 1,2,3,... etc as they are values of type Int (or
Integer, etc...) instead you have to use type level numbers:
data One
data Two
Work is ongoing for type level numbers in GHC and there are user
libraries on Hackage so there is a lot of work to crib from.
___
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] Fwd: GSoC Push Notifications project - communicating with mobile devices
Hi, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM ) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be grateful if you could give me your opinion about this project and the proposal I am starting to write. *Proposal GSoC 2013:* *Abstract* The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily. When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are: - Google Cloud Messaging (Android) - Apple Push Notification Service (iPhone / iPad) - Microsoft Push Notification Service (Windows Phone) - BlackBerry Push Service (BlackBerry) - Windows Push Notification Services (Windows 8) - etc. *Motivation and expected benefits* I think my idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them. Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner. Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast). This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed. Once the data is delivered, the application can be launched in the background to process it as needed. This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available. The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc. As all the libraries to access to these services are developed in Java, I thought that it would be a good idea to offer an option to Haskell programmers. Taking advantage of the similarity of these services, I could develop a very adaptable library which fits the necessities for each one and at the same time offer an abstraction to the user. *Deliverables.* * An API library to build and send messages including: - GCM and a demo Android app. - APN and a demo iOS app. - Microsoft Push Notification Service (Windows Phone) and a demo app. - Documentation for all the code developed. Including the explantation on how to use the server library and how to try the demo apps. * A demo server taking advantage of this libraries to communicate with the demo apps through push notifications. * Optionally: (Only in the case that I finalize the rest of the objectives before the deadline) - API for communication through BlackBerry Push Service (BlackBerry). - API for communication through Windows Push Notification Services (Windows 8). *Technical Considerations* I have to complete this *Timeline* May 27: (Accepted students announced) - 'Community Bonding Period' (~1 month) + Get to know mentor(s). + Refine this proposal with mentor(s). + Set up svn accounts. + Set up a wiki page or blog for this project. + Make sure that everything is ready for coding. + Try to involve the community as much as possible, ask for new ideas/suggestions/etc. June 17: (Start
Re: [Haskell-cafe] Stream fusion and span/break/group/init/tails
On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote: On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan b...@serpentine.comwrote: On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: I address it briefly in my thesis [1], Section 4.8.2. I think it's a fundamental limitation of stream fusion. See also concat, where the naive fusion-based implementation has quadratic performance: concat :: [Text] - Text concat txts = unstream (Stream.concat (List.map stream txts)) I've never figured out how to implement this with sensible characteristics within the fusion framework. If you could solve concat, might that also lead to be being able to do without the Skip constructor? Dan is right, we still need Skip. My suggested solution to the concatmap problem is also mostly independent of the skip issue. You shouldn't think of skip as being a hack. It's not. It's how we express a more general class of producers in a way that is productive. You can think of a stream as being a little state machine and sometimes the state machine needs to be able to make transitions without producing any output. One solution to that is to hide those transitions (by running the state machine until it does produce something, ie using recursion/loops) and the other is to expose the transition as a skip. The skip approach where we don't use recursion/loops allows us to do the various transformations we need to be able to effectively optimise the whole thing. If you're interested in this stuff, you can look at the section of my thesis that goes on about this state machine perspective on things. I think it's quite a useful way to understand it (and understand how we optimise stream functions by composing these state machines). More generally, that chapter explains why stream fusion should actually be an optimisation. As for step and the list base functor. Yes, absolutely. And adding skip does make things harder to prove, because it adds more junk values. The other major chapter of my thesis explains why it's all still true, even when we have skip, or rather how we have to do things carefully so that it does still remain valid. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Push Notifications project - communicating with mobile devices
I'm not sure if I understand what you want to do.. Am I correct in thinking that you are looking to provide a Haskell API to interface with these push notification services, so that (e.g.,) a Yesod app could send push notifications to a mobile device? I have a good amount of experience working with Android hacking and know stuff about GCM (formerly the now-deprecated C2DM): I would be willing to (informally) advise you of the details on that side for your project, should this be accepted. Most of the time power efficient means that there are as few things as possible on the device which retain a persistent connection to the server. This is why GCM wins: there's only one app which does the heavy lifting of maintaining frequent contact with the remote server. You might also look at Parse (recently acquired by Facebook), which provides a similar service with a little more flexibility. Unfortunately, I'm not sure how much work this involves, and I'm not certain it is enough to constitue a GSoC projecl. To give you some idea: the corresponding Ruby gem (http://rubygems.org/gems/gcm) is *extremely* small, though it uses metaprogramming on the Ruby side. The thing that makes these APIs simple to write is that implementing GCM is literally just as easy as writing think wrapper around a JSON API provided by Google. I've also never used APNS, but it's corresponding gem looks extremely similar and involves similar techniques. So I don't think this is a bad project, but I think the time estimates may be unrealistic: I would estimate that it should take you around 1 week to get an API for GCM (for example), most of that time would be studying how to do JSON communication with the server (presumably using conduit). One thing you haven't mentioned is this: once you send a push notification to a device, it sometimes calls you back by making a HTTP request to your server. I'm not sure if this code really constitutes as boilerplate or not: maybe it does. I would suggest also adding to your schedule writing up a Yesod app which has back and forth communication with a device, seeing what common problems pop up, and then writing an API for handling *that* as well. (That may broaden the scope of your project enough.) Kris On Sun, Apr 28, 2013 at 5:41 PM, Marcos Pividori marcospivid...@gmail.com wrote: Sorry, I am resending this email because I didn't write a correct title before. --- Greetings, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM ) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be grateful if you could give me your opinion about this project and the proposal I am starting to write. Proposal GSoC 2013: Abstract The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily. When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are: - Google Cloud Messaging (Android) - Apple Push Notification Service (iPhone / iPad) - Microsoft Push Notification Service (Windows Phone) - BlackBerry Push Service (BlackBerry) - Windows Push Notification Services (Windows 8) - etc. Motivation and expected benefits I think my idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them. Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive
Re: [Haskell-cafe] Fwd: Google Summer of Code, news
I second that advice! I can technically read Spanish, but I find the complexity of the language barrier compounded with trying to understand the code becomes more confusing than I'd prefer :-). Kris On Sun, Apr 28, 2013 at 2:19 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/04/13 18:37, Marcos Pividori wrote: Greetings, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM ) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be grateful if you could give me your opinion about this project and the proposal I am starting to write. While I don't have anything to contribute to the project idea itself, I had a look at your code on GitHub and I'd like to recommend that in the future, when writing code that will get published and used by others, you use English. This especially applies to projects aimed to benefit a wider community such as this one. You seem to be mixing the two together which doesn't help readability either. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfWhMAAoJEM1mucMq2pqXJH8P/RqWzAHFlbkLPRSzRK3w+Us2 I+VDOGxF6627RwWSX3P5gY84t8lhGQZ8M9voGptKnNE+2xmArtqQIn6a9Jj01o3n PcV6SuacG5qNpHawQdVXSFoIGkQ9tNhSDu4HYgXTRQD1tptxd31pKi9gN2EE6ieA HgdR6g688edLjdfbGj18CDNnFxIJhzsFYoqaNgBZB4ZpcCisQzdkwGELx8c3+fa2 deSbsvA808q/xPiFZ6DDCOF0aXQmvQwtVdCdhyrn4BPMhGF2da9zqcy3VNPHWMd5 VNnw4USY1vVdsTY6fKts5IyuNhIl7WTGypNUbIMl3gCpH1RWgO8FbKZQmyvosPPv xCA7qpPVkc8sg2qSBiQyJ66upg5503bCoijNYxGmCAaFm83bJdUgwrhnOBoyguPC S86g6zNUrbV6oQDAPy3unOKLlCGJhlQgEx9dbXPDCQiqWeUqhVipqxf0WHDcTPMW prjWzqZTJkm1kq11G4Ues4sXpJDzG0syWroaO4ah0A6aCZzuFFX8NqcQvEufzRCS ydOF9Qgr5nuVcBndjekYw9uxA6UtRDKoyvmvr0y5TDfk7w42dC/qPOhK5xkndz7u pjXnIGanqBur1B5Fw5jfilzc5eViOYDGGtZqz4/mKV6lfQclTljTVI461HrSQW+H SVdK4oqvGU0ZCD94BBHv =+KLZ -END PGP SIGNATURE- ___ 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] Fwd: Google Summer of Code, news
I'll throw in that Marcos mentioned this very issue to me about his code before showing it to me. It was written the way it was for the requirements of his course. He volunteered to translate the comments for me, but I told him it wasn't necessary in order to get an initial feel for the code (I also read Spanish somewhat). On Mon, Apr 29, 2013 at 5:25 PM, Kristopher Micinski krismicin...@gmail.com wrote: I second that advice! I can technically read Spanish, but I find the complexity of the language barrier compounded with trying to understand the code becomes more confusing than I'd prefer :-). Kris On Sun, Apr 28, 2013 at 2:19 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/04/13 18:37, Marcos Pividori wrote: Greetings, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM ) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be grateful if you could give me your opinion about this project and the proposal I am starting to write. While I don't have anything to contribute to the project idea itself, I had a look at your code on GitHub and I'd like to recommend that in the future, when writing code that will get published and used by others, you use English. This especially applies to projects aimed to benefit a wider community such as this one. You seem to be mixing the two together which doesn't help readability either. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfWhMAAoJEM1mucMq2pqXJH8P/RqWzAHFlbkLPRSzRK3w+Us2 I+VDOGxF6627RwWSX3P5gY84t8lhGQZ8M9voGptKnNE+2xmArtqQIn6a9Jj01o3n PcV6SuacG5qNpHawQdVXSFoIGkQ9tNhSDu4HYgXTRQD1tptxd31pKi9gN2EE6ieA HgdR6g688edLjdfbGj18CDNnFxIJhzsFYoqaNgBZB4ZpcCisQzdkwGELx8c3+fa2 deSbsvA808q/xPiFZ6DDCOF0aXQmvQwtVdCdhyrn4BPMhGF2da9zqcy3VNPHWMd5 VNnw4USY1vVdsTY6fKts5IyuNhIl7WTGypNUbIMl3gCpH1RWgO8FbKZQmyvosPPv xCA7qpPVkc8sg2qSBiQyJ66upg5503bCoijNYxGmCAaFm83bJdUgwrhnOBoyguPC S86g6zNUrbV6oQDAPy3unOKLlCGJhlQgEx9dbXPDCQiqWeUqhVipqxf0WHDcTPMW prjWzqZTJkm1kq11G4Ues4sXpJDzG0syWroaO4ah0A6aCZzuFFX8NqcQvEufzRCS ydOF9Qgr5nuVcBndjekYw9uxA6UtRDKoyvmvr0y5TDfk7w42dC/qPOhK5xkndz7u pjXnIGanqBur1B5Fw5jfilzc5eViOYDGGtZqz4/mKV6lfQclTljTVI461HrSQW+H SVdK4oqvGU0ZCD94BBHv =+KLZ -END PGP SIGNATURE- ___ 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] Stream fusion and span/break/group/init/tails
On Mon, Apr 29, 2013 at 4:05 PM, Duncan Coutts duncan.cou...@googlemail.com wrote: On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote: On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: I address it briefly in my thesis [1], Section 4.8.2. I think it's a fundamental limitation of stream fusion. See also concat, where the naive fusion-based implementation has quadratic performance: concat :: [Text] - Text concat txts = unstream (Stream.concat (List.map stream txts)) I've never figured out how to implement this with sensible characteristics within the fusion framework. If you could solve concat, might that also lead to be being able to do without the Skip constructor? Dan is right, we still need Skip. My suggested solution to the concatmap problem is also mostly independent of the skip issue. You shouldn't think of skip as being a hack. It's not. It's how we express a more general class of producers in a way that is productive. You can think of a stream as being a little state machine and sometimes the state machine needs to be able to make transitions without producing any output. One solution to that is to hide those transitions (by running the state machine until it does produce something, ie using recursion/loops) and the other is to expose the transition as a skip. The skip approach where we don't use recursion/loops allows us to do the various transformations we need to be able to effectively optimise the whole thing. If you're interested in this stuff, you can look at the section of my thesis that goes on about this state machine perspective on things. I think it's quite a useful way to understand it (and understand how we optimise stream functions by composing these state machines). More generally, that chapter explains why stream fusion should actually be an optimisation. As for step and the list base functor. Yes, absolutely. And adding skip does make things harder to prove, because it adds more junk values. The other major chapter of my thesis explains why it's all still true, even when we have skip, or rather how we have to do things carefully so that it does still remain valid. Duncan Thanks for the explanation. I looked at your thesis previously, but only read through a couple of sections (including the one about concatMap). I might go through the state machine parts as well now that I know the significance/relevance. The thing in particular that was motivating me is that if it weren't for Skip, it seems that to some extent (I haven't had time to investigate precisely what extent) you could write a stream fusion framework in a datatype-generic way, parameterized over the base functor. But it wasn't obvious to me how (or whether) you would translate Skip. But maybe the state machine perspective will provide some insight into that. I'll think about it. -- Your ship was destroyed in a monadic eruption. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stream fusion and span/break/group/init/tails
On Mon, 2013-04-29 at 20:19 +0200, Gábor Lehel wrote: Thanks for the explanation. I looked at your thesis previously, but only read through a couple of sections (including the one about concatMap). I might go through the state machine parts as well now that I know the significance/relevance. The thing in particular that was motivating me is that if it weren't for Skip, it seems that to some extent (I haven't had time to investigate precisely what extent) you could write a stream fusion framework in a datatype-generic way, parameterized over the base functor. But it wasn't obvious to me how (or whether) you would translate Skip. But maybe the state machine perspective will provide some insight into that. I'll think about it. Oh I think you can write it in a data-type generic way. If your datatype is described by a base functor F, then the skip version is a simple transformation on that functor. F_skip a = F a + a And then the stream type for F is nu a. F_skip a See section 3.6. In most of my theory chapter I write it in this style, rather than using the list functor specifically. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stream fusion and span/break/group/init/tails
On Mon, Apr 29, 2013 at 10:05 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote: On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: I address it briefly in my thesis [1], Section 4.8.2. I think it's a fundamental limitation of stream fusion. See also concat, where the naive fusion-based implementation has quadratic performance: concat :: [Text] - Text concat txts = unstream (Stream.concat (List.map stream txts)) I've never figured out how to implement this with sensible characteristics within the fusion framework. If you could solve concat, might that also lead to be being able to do without the Skip constructor? Dan is right, we still need Skip. My suggested solution to the concatmap problem is also mostly independent of the skip issue. You shouldn't think of skip as being a hack. It's not. It's how we express a more general class of producers in a way that is productive. To further this, note that in a total language, with the type: codata Stream a = End | Yield a (Stream a) filter is not definable; it is not a total function. At least, barring an extra proof of some sort that the predicate will yield true after a finite amount of time. concat is similar. Also, adding Skip (Stream a) is a relatively standard way of explicitly representing lazy, partial values. (This is opposed to the partiality monad, which is like an encoding of strict general recursion). That is, if νF is the type of total values, then ν(F + Id) is the type of partial values. I don't know how easy it is to delete from a more complex tree using just that extension, but in theory you could productively represent arbitrary manipulations with just that, I believe. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool
The latest updates on HaRe with GHC API project seem to be posted on the
google+ community page:
https://plus.google.com/communities/116266567145785623821
On Monday, April 29, 2013 5:09:56 AM UTC-5, Simon Hengel wrote:
Hi Niklas,
I haven't read the whole proposal as I'm short of time. But Alan
Zimmerman is doing a lot of work on integrating HaRe with the GHC API
[1]. He is alanz on freenode and a regular in #hspec.
I haven't looked at the code, but maybe it's of interest to you.
Cheers,
Simon
[1] https://github.com/alanz/HaRe/tree/ghc-api
On Mon, Apr 29, 2013 at 02:00:23PM +0800, Niklas Hambüchen wrote:
I would like to propose the development of source code refactoring tool
that operates on Haskell source code ASTs and lets you formulate rewrite
rules written in Haskell.
Objective
-
The goal is to make refactorings easier and allow global code changes
that might be incredibly tedious to do in a non-automated way.
By making these transformations convenient, we can make it easier to
maintain clean code, add new features or clean up leftovers faster, and
reduce the fear and effort to upgrade to newer versions of packages and
APIs.
Transformations
---
First, here are a few operations you would use this tool for. Some of
them are common operations you would also do in other programming
languages, some are more specific to Haskell.
* Changing all occurrences of import Prelude hiding (catch) to import
qualified Control.Exception as E
* Replacing all uses of a function with that function being imported
qualified or the other way around
* Adding a field to data constructor a record, setting user-supplied
defaults for construction and destruction:
-- Suppose you want to change one of these
data User = User { name :: String, age :: Int }
data User = User String Int
-- into one of these
data User = User { name :: String, age :: Int, active :: Bool }
data User = User String Int Bool
-- the refactoring tool could perform, in all relevant locations:
show (User name age) = ...
show (User name age _) = ...
-- and also this transformation:
... u { name = deleted } ...
... u { name = deleted, active = False } ...
-- or equivalently with records.
-- Special cases could be taken care of as specified, such as
-- whenever an object of [this User type] has
--of its records passed into some function 'email', do this
--now only if the user is active, so modify all relevant code
--email (name u)
--to
--if (active u) then email (name u) else return ()
-- Other examples include adding a position counter to attoparsec.
* Adding a type parameter to a type
-- This happens a lot on monad transformer stacks, e.g.
newtype MyMonad a b c = MyMonad (ReaderT a (WriterT b ...
-- and as you would probably agree on, this is not the most
-- comfortable change to make; in big project this can mean
-- hour-long grinding.
-- It has also recently happened in the basic underlying types
-- of packages like conduit and pipes.
* Adding a new transformer around a monad
* Addressing problems like mentioned in
http://blog.ezyang.com/2012/01/modelling-io/:
There is one last problem with this approach: once the primitives
have been selected, huge swaths of the standard library have to be
redefined by “copy pasting” their definitions ...
* Extracting a value into a let or where clause
* Renaming a variable, and all its occurrences that are semantically
same variable (based on its scope)
* Changing the way things are done, such as:
* Replacing uses of fmap with $, also taking care of the
corresponding import, and such cases were partial application
is involved
* Replacing uses of when (isJust) to forM_
* Making imports clearer by adding all functions used to the file to the
import list of the module that gets them in scope
* Finding all places where an exported function does not have all its
arguments haddock-documented.
* Performing whole-project refactorings instead of operating on single
files only, allowing operations like
Find me all functions of this type, e.g.
Maybe a - (a - m a) - m a
in the project and extract them into this new module,
with the name 'onJust'.
Some of the problems above can be tried to address using regex-based
search and replace, but this already fails in the simplest case of
import Prelude hiding (catch) in case there is more than that imported
from Prelude or newlines involved in the import list.
Transformation on the AST are much more powerful, and can guarantee that
the result is, at least syntactically, valid. No text base tool can do
that.
Re: [Haskell-cafe] partially applied data constructor and corresponding type
Thanks a lot for your message.
I can use a recent version of GHC 7.6.x (I will install the last version of
Kubuntu for that purpose).
However, it will take me some time to understand correctly this code (e.g. I
do not know data kinds), I will go back to you if I encounter difficulties.
Thanks,
TP
On Monday, April 29, 2013 08:19:43 Richard Eisenberg wrote:
There's a lot of recent work on GHC that might be helpful to you. Is it
possible for your application to use GHC 7.6.x? If so, you could so
something like this:
{-# LANGUAGE DataKinds, GADTs, KindSignatures #-}
data Nat = Zero | Succ Nat
type One = Succ Zero
type Two = Succ One
type Three = Succ Two
-- connects the type-level Nat with a term-level construct
data SNat :: Nat - * where
SZero :: SNat Zero
SSucc :: SNat n - SNat (Succ n)
zero = SZero
one = SSucc zero
two = SSucc one
three = SSucc two
data Tensor (n :: Nat) a = MkTensor { dims :: SNat n, items :: [a] }
type Vector = Tensor One
type Matrix = Tensor Two
mkVector :: [a] - Vector a
mkVector v = MkTensor { dims = one, items = v }
vector_prod :: Num a = Vector a - Vector a
vector_prod (MkTensor { items = v }) = ...
specializable :: Tensor n a - Tensor n a
specializable (MkTensor { dims = SSucc SZero, items = vec }) = ...
specializable (MkTensor { dims = SSucc (SSucc SZero), items = mat }) = ...
This is similar to other possible approaches with type-level numbers, but it
makes more use of the newer features of GHC that assist with type-level
computation. Unfortunately, there are no constructor synonyms or pattern
synonyms in GHC, so you can't pattern match on MkVector or something
similar in specializable. But, the pattern matches in specializable are
GADT pattern-matches, and so GHC knows what the value of n, the type
variable, is on the right-hand sides. This will allow you to write and use
instances of Tensor defined only at certain numbers of dimensions.
I hope this is helpful. Please write back if this technique is unclear!
Richard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Push Notifications project - communicating with mobile devices
On Mon, Apr 29, 2013 at 4:46 PM, Marcos Pividori marcospivid...@gmail.com wrote: Hi, thanks for your response! this really help me. * About the code in Spanish: I will replace it for an English version in the next weeks. As Michael said, I had to write it in Spanish because it was a project for my university. Sorry, I know it is not clear now. No worries, I don't think this makes it bad, just harder to read for English speakers * Kristopher, thanks for your comments and availability. Yes, I am looking to provide a Haskell API to interface with these different push notification services. I know that maybe it isn't enough to fill up a summer, so I will get into account this ideas you gave me. I am thinking about some useful tools I could provide to people programming for mobile devices. I would also be interested in hearing about what you come up with. I have a lot of experience with mobile hacking, and I'd be glad to help you validate ideas as they come to you, or point you at related material. I would suggest also adding to your schedule writing up a Yesod app which has back and forth communication with a device, seeing what common problems pop up, and then writing an API for handling *that* as well. (That may broaden the scope of your project enough.) I created this back and forth communication for the project I mentioned before. But, a lot of things could be improved. For example, about mantaining a state of the connection and being able to manage with a lot of devices at the same time. (As I implemented this, I think it wont work really well with a lot of devices). And I could develop a demo app for each OS (Android, iOS, Windows Phone, etc) to manage this communication. I 'll continue investigating, every contribution is welcome! The key aspects are to use Haskell to write as little as boilerplate code as possible. Then identify the common elements of the API for each and write a common API. That strikes me as the simple part. I'm not sure if it's sensible or not, but maybe it would be possible to formalize this back and forth computation using something similar to session types. Maybe next steps would be to automatically take the types in the program and generate a contract for the JSON sent between the device and server, which might give you some fun experience in type level programming. This is very hand wavy, so I'm not sure if that's realistic or not... Kris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: [darcs-users] Google Summer of Code
-- Forwarded message -- From: Ganesh Sittampalam gan...@earth.li Date: 2013/4/25 Subject: [darcs-users] Google Summer of Code To: darcs-users darcs-us...@darcs.net Hi, darcs.net will participating in Google Summer of Code this year, under the umbrella of haskell.org - Google will be allocating 1 or 2 extra slots specifically for Darcs. Time is a little short, as we'd originally thought this arrangement was coming to an end: the student application deadline is 1900UTC on next Friday (May 3rd). Please see http://darcs.net/GSoC for ideas and what to do next if you are interested in participating. The most important thing is to get in touch with us informally asap. Many thanks to Guillaume Hoffmann both for making our initial application to be a separate organisation (which was unfortunately rejected), and then for talking to Google and establishing that our existing arrangement of having a dedicated slot under the haskell.org umbrella could continue. Cheers, Ganesh ___ darcs-users mailing list darcs-us...@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On 29/04/2013, at 10:04 PM, kudah wrote: On Mon, 29 Apr 2013 18:04:47 +1200 Richard A. O'Keefe o...@cs.otago.ac.nz wrote: so that there is no possibility of catching errors early; by definition in that processor there are no errors. Haddock's markup isn't any better in that regard. Did I praise Haddock? I spent two hours on my first day with haddock figuring out that I needed an empty comment line before a code block. It didn't issue any warnings or errors either. Report that as a bug. For what it's worth, I've resurrected an old design I did and have been playing with it to see just how bad it really is to use something like @iword than _word_. (Can anyone remember the name of the old formatting program that the * and _ convention comes from? I've got a manual for it buried in a box I can't reach, and I've been trying to remember the name. The manual was a UBC technical report some time in the early 80s, which may mean it was written in BCPL.) I took a thousand line documentation file and converted it to this unambiguous markup with a single reserved character, and the size increase was actually, well, actually, it got @ismaller. I'm not going to describe the notation, because the point is that unambiguous and lightweight are compatible properties. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc-7 -fPIC error
Hey guys, this probably isn't the official GHC mailing list, but I've been trying to build and install a new GHC on an old RHEL5 system, as mentioned in my previous Cafe thread. I was able to make some good headway: I installed a ghc-6.8 binary, and then used that to build ghc-6.10 source, and then used that to build ghc-6.12 source. The idea is to keep going until I get to ghc-7.6. However, when I get to 7.0, my builds all eventually die with this error: quote: /usr/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation R_X86_64_PC32 against `StgRun' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status After this failed the first time, I tried adding -fPIC to SRC_HC_OPTS, GhcStage1HcOpts, and so forth in build.mk. But ultimately I get the same error. I tried skipping a version and building ghc-7.2 instead, but the same error pops up. -- frigidcode.com signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On 30 April 2013 09:28, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: On 29/04/2013, at 10:04 PM, kudah wrote: On Mon, 29 Apr 2013 18:04:47 +1200 Richard A. O'Keefe o...@cs.otago.ac.nz wrote: so that there is no possibility of catching errors early; by definition in that processor there are no errors. Haddock's markup isn't any better in that regard. Did I praise Haddock? I spent two hours on my first day with haddock figuring out that I needed an empty comment line before a code block. It didn't issue any warnings or errors either. Report that as a bug. For what it's worth, I've resurrected an old design I did and have been playing with it to see just how bad it really is to use something like @iword than _word_. Everyone agrees it's useful to have @ilegible markup :) I'm impressed with Mateusz' balanced summary of the issues and look forward to his GSoC project submission about _Markdown_. Conrad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
