Re: [Haskell-cafe] CRIP: the Curiously Reoccuring Instance Pattern
I think instead you should have: - abandoned FunDeps - embraced Overlapping more! Well, using TypeCast to emulate all FunDeps was demonstrated three years later after HList (or even sooner -- I don't remember when exactly the code was written): http://okmij.org/ftp/Haskell/TypeClass.html#Haskell1 We demonstrate that removing from Haskell the ability to define typeclasses leads to no loss of expressivity. Haskell restricted to a single, pre-defined typeclass with only one method can express all of Haskell98 typeclass programming idioms including constructor classes, as well as multi-parameter type classes and even some functional dependencies. The addition of TypeCast as a pre-defined constraint gives us all functional dependencies, bounded existentials, and even associated data types. Besides clarifying the role of typeclasses as method bundles, we propose a simpler model of overloading resolution than that of Hall et al. So here's my conjecture: 1. We don't need FunDeps, except to define TypeCast. (And GHC now has equality constraints, which are prettier.) 2. Without FunDeps, overlapping works fine. ... I agree on point 1 but not on point 2. The example of incoherence described in Sec `7.6.3.4. Overlapping instances' of the GHC User Guide has nothing to do with functional dependencies. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CRIP: the Curiously Reoccuring Instance Pattern
oleg at okmij.org writes: I think instead you should have: - abandoned FunDeps - embraced Overlapping more! Well, using TypeCast to emulate all FunDeps was demonstrated three years later after HList (or even sooner -- I don't remember when exactly the code was written): http://okmij.org/ftp/Haskell/TypeClass.html#Haskell1 Yikes! Thank you Oleg, more formidable code to get my head round. So here's my conjecture: 1. We don't need FunDeps, except to define TypeCast. (And GHC now has equality constraints, which are prettier.) 2. Without FunDeps, overlapping works fine. ... I agree on point 1 but not on point 2. The example of incoherence described in Sec `7.6.3.4. Overlapping instances' of the GHC User Guide has nothing to do with functional dependencies. Well, I meant overlapping as used in HList. But fair point, and goes back to a much earlier discussion: a) Don't switch on IncoherentInstances. b) Make instance validation 'eager' and 'strict' like Hugs does, not 'optimistic'/'lax' like GHC. (That is, validate at point of declaration of the instance.) c) Reject instances that are not explicitly dis-overlapped. The mechanism for dis-overlap is disequality restraints. So for the multi- module MyShow example in 7.6.3.4. reject the overlap: instance MyShow [T] -- in module Main is OK, providing -- instance MyShow [a] -- in module Help must be dis-overlapped to instance MyShow [a] | a /~ T where ... The work-in-progress NewAxioms is aiming for something similar, but only for type functions. Perhaps in the longer term we use that to build helper functions, then banish overlapping type classes? (I still think that explicitly dis-overlapped instances would be easier to understand.) AntC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Spam on the Haskell wiki
On Mon, Jul 30, 2012 at 6:59 PM, Alexander Solla alex.so...@gmail.com wrote: We could even have a report spam button on each page, and if enough users click on it (for a given revision), the revision gets forwarded to a moderator. This would be useless. The problem is not detecting spam, since that's quite trivial: it's very hard to miss. The problem is that the moderator (ie. me) is already overworked. The spam needs to be reduced to begin with, not detected. -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Community-wide RFP
Is there a place - on the Haskell Wiki perhaps - with a list of desired Haskell-related projects? Both for programs written in Haskell, as well as things to help, and enhance the programming experience? Walt BMeph Rorie-Baety I am an eyewitness to what you committed in that location. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Community-wide RFP
There is an ignored reddit for that (http://www.reddit.com/r/haskell_proposals), but somewhere good? I don't think so. Thomas On Fri, Aug 3, 2012 at 8:02 AM, Black Mephistopheles black.m...@gmail.com wrote: Is there a place - on the Haskell Wiki perhaps - with a list of desired Haskell-related projects? Both for programs written in Haskell, as well as things to help, and enhance the programming experience? Walt BMeph Rorie-Baety I am an eyewitness to what you committed in that location. ___ 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] What Haskell Records Need
Evan Laforge wrote: I consider that a strength of the lens approach. If I say 'set (a.b.c.d) 42 record', 'a', 'b' etc. don't have to be record fields, I can swap them out for other lenses later on. I can also easily precompose, e.g. 'setThis = a . b; setThat = b . c' and encourage people to use the composed ones (or require via export lists). This corresponds to asking in that it introduces a point of abstraction where I can change all access / modification in one place, or a module can retain control by only exporting the composed version. The same is true with SEC functions: personsSalary' :: (Salary - Salary) - Person - Person personsSalary' = job' . salary' Here I've created a new updater that is composed of 2 that are generated for me (from the examples given in the original email). I can export whichever of these functions I like, generated or otherwise, and keep as much abstraction as I like! The nice part about the SEC functions is that they compose as regular functions. Lenses are super powerful in that they form a category. Unfortunately using categories other than functions feels a tad unwieldy because you have to hide something from prelude and then import Category. (A bit like exceptions, currently). If you like the look of set with lenses, you could define a helper function to use with SEC updaters. set :: ((b - a) - c) - a - c set sec = sec . const --and then use it like so: setPersonsSalary :: Salary - Person - Person setPersonsSalary salary = set personsSalary' salary With it you can use an updater as a setter. I'd like to reiterate one of finer points of the original proposal. The compiler could disallow using old-style update syntax for fields whose SEC update function is not in scope, giving us fine-grained control over access and update. On the other hand we currently have to create new functions to achieve this (exporting the getter means exporting the ability to update [using update syntax] as well, currently). And now back to lenses: it is really convenient how lenses let you compose the getter and setter together. I don't recall too many cases where having the getter and setter and modifier all in one place was terribly useful. Could anyone give me an example? But again, where that is useful, a lens can be created from a getter and a SEC updater. Thoughts? --Jonathan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell-beginners] vector indexing time
Thank you for that insight. :) On Fri, Aug 3, 2012 at 4:50 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Creating the vector still takes time proportional to the length of the vector. In fact, it appears that in your example, the vector packages optimizes the creation time to create only up to the element that you actually demand. The linear time you're seeing is not the result of an inefficiency of vector indexing, but the result of an efficiency in vector creation. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What Haskell Records Need
On Fri, Aug 3, 2012 at 10:11 AM, Jonathan Geddes
geddes.jonat...@gmail.comwrote:
The nice part about the SEC functions is that
they compose as regular functions. Lenses are
super powerful in that they form a category.
Unfortunately using categories other than
functions feels a tad unwieldy because you
have to hide something from prelude and then
import Category. (A bit like exceptions,
currently).
FWIW this is also true for van Laarhoven lenses[1]
type FTLens a b = forall f. Functor f = (b - f b) - (a - f a)
newtype Const a b = Const { unConst :: a } deriving Functor
get :: FTLens a b - a - b
get ft = unConst . ft Const
{-
ft :: forall f. (b - f b) - (a - f a)
Const :: forall x. b - Const b x
ft Const :: a - Const b a
-}
newtype Id a = Id { unId :: a } deriving Functor
set :: FTLens a b - b - a - a
set ft b = unId . ft (\_ - Id b)
modify :: FTLens a b - (b - b) - a - a
modify ft k = unId . ft (Id . k)
-- example
fstLens :: FTLens (a,b) a
fstLens aToFa (a,b) = (,b) $ aToFa a
-- and you get
compose :: FTLens b c - FTLens a b - FTLens a c
compose = (.)
identity :: FTLens a a
identity = id
If you like the look of set with lenses,
you could define a helper function to use
with SEC updaters.
set :: ((b - a) - c) - a - c
set sec = sec . const
--and then use it like so:
setPersonsSalary :: Salary - Person - Person
setPersonsSalary salary = set personsSalary' salary
With it you can use an updater as a setter.
I'd like to reiterate one of finer points of
the original proposal.
The compiler could disallow using old-style
update syntax for fields whose SEC update
function is not in scope, giving us
fine-grained control over access and update.
On the other hand we currently have to create
new functions to achieve this (exporting the
getter means exporting the ability to update
[using update syntax] as well, currently).
And now back to lenses:
it is really convenient how lenses let you compose the getter
and setter together.
I don't recall too many cases where having the
getter and setter and modifier all in one
place was terribly useful. Could anyone give
me an example? But again, where that is
useful, a lens can be created from a getter
and a SEC updater.
Thoughts?
--Jonathan
___
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] What Haskell Records Need
Oops, forgot my references
[1] Original post:
http://www.twanvl.nl/blog/haskell/cps-functional-references
[2] polymorphic update support: http://r6.ca/blog/20120623T104901Z.html
[3] another post about these:
http://comonad.com/reader/2012/mirrored-lenses/
On Fri, Aug 3, 2012 at 1:53 PM, Ryan Ingram ryani.s...@gmail.com wrote:
On Fri, Aug 3, 2012 at 10:11 AM, Jonathan Geddes
geddes.jonat...@gmail.com wrote:
The nice part about the SEC functions is that
they compose as regular functions. Lenses are
super powerful in that they form a category.
Unfortunately using categories other than
functions feels a tad unwieldy because you
have to hide something from prelude and then
import Category. (A bit like exceptions,
currently).
FWIW this is also true for van Laarhoven lenses[1]
type FTLens a b = forall f. Functor f = (b - f b) - (a - f a)
newtype Const a b = Const { unConst :: a } deriving Functor
get :: FTLens a b - a - b
get ft = unConst . ft Const
{-
ft :: forall f. (b - f b) - (a - f a)
Const :: forall x. b - Const b x
ft Const :: a - Const b a
-}
newtype Id a = Id { unId :: a } deriving Functor
set :: FTLens a b - b - a - a
set ft b = unId . ft (\_ - Id b)
modify :: FTLens a b - (b - b) - a - a
modify ft k = unId . ft (Id . k)
-- example
fstLens :: FTLens (a,b) a
fstLens aToFa (a,b) = (,b) $ aToFa a
-- and you get
compose :: FTLens b c - FTLens a b - FTLens a c
compose = (.)
identity :: FTLens a a
identity = id
If you like the look of set with lenses,
you could define a helper function to use
with SEC updaters.
set :: ((b - a) - c) - a - c
set sec = sec . const
--and then use it like so:
setPersonsSalary :: Salary - Person - Person
setPersonsSalary salary = set personsSalary' salary
With it you can use an updater as a setter.
I'd like to reiterate one of finer points of
the original proposal.
The compiler could disallow using old-style
update syntax for fields whose SEC update
function is not in scope, giving us
fine-grained control over access and update.
On the other hand we currently have to create
new functions to achieve this (exporting the
getter means exporting the ability to update
[using update syntax] as well, currently).
And now back to lenses:
it is really convenient how lenses let you compose the getter
and setter together.
I don't recall too many cases where having the
getter and setter and modifier all in one
place was terribly useful. Could anyone give
me an example? But again, where that is
useful, a lens can be created from a getter
and a SEC updater.
Thoughts?
--Jonathan
___
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] cabal-dev + haskell mode (vim)
Hello Café, I am struggling to get ctags and / or haskell mode to work with cabal-dev. This is quite annoying. Has anyone worked around this? Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-dev + haskell mode (vim)
On Fri, Aug 3, 2012 at 2:35 PM, Benjamin Edwards edwards.b...@gmail.com wrote: I am struggling to get ctags and / or haskell mode to work with cabal-dev. This is quite annoying. Has anyone worked around this? I use ghc-mod for vim and it sorta supports this... by adding arbitrary flags to GHC in your vimrc: let g:ghcmod_ghc_options = ['-package-conf=/Source/alphaHeavy/build/package.conf.d'] Providing cabal-dev maintains a package database it should work there too. With a little vim-fu you could probably discover the most correct package database automatically. https://github.com/eagletmt/ghcmod-vim -n ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why is the the transpose function in Data.List more complicated?
Transpose in Data.List is the following: transpose :: [[a]] - [[a]] transpose [] = [] transpose ([] : xss) = transpose xss transpose ((x:xs) : xss) = (x : [h | (h:_) - xss]) : transpose (xs : [ t | (_:t) - xss]) Yet this seems to work. transp :: [[b]] - [[b]] transp ([]:_) = [] transp rows = map head rows : transp (map tail rows) Why is the the transpose function in Data.List more complicated? -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell-beginners] Why is the the transpose function in Data.List more complicated?
Hi KC, transp :: [[b]] - [[b]] transp ([]:_) = [] transp rows = map head rows : transp (map tail rows) Why is the the transpose function in Data.List more complicated? In the Data.List version, the list comprehension syntax quietly filters out items that fail to pattern-match (empty lists). Therefore the transpose in Data.List does not generate a pattern-match exception when you give it lists of different lengths: transpose [[1], [], [3]] == [[1,3]] The Data.List version also returns an empty list if the input is an empty list, whereas your version returns an infinite list of empty lists. -Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Spam on the Haskell wiki
Hi Gwern, First of all, thanks for your patience. I am willing to do administrator tasks. 4. ReCAPTCHA enabled for 'edits adding new, unrecognized external links' - which is all of the spam. This is already enabled. I guess the problem may be due to ReCAPTCHAhttp://www.google.com/recaptcha/learnmore; so you can choose to use a custom built CAPTCHA that is more difficult to crack. You may find some open source captcha systems better than the ReCAPTCHA. http://jcaptcha.sourceforge.net/ To forge the relay attacks on CAPTCHA, you may try early timeouts and/or increasing length of CAPTCHA text. This potentially may mean more trouble and nuisance to legit users, but I guess, the Haskellers will be willing to pay this small price for a better web-site experience for them. :) Relay attacks: Remember that there are human solvers employed in countries like India, China, so any human solvable captcha will fail to work as desired. http://en.wikipedia.org/wiki/CAPTCHA#Human_solvers The problem is not detecting spam, since that's quite trivial: it's very hard to miss. Thanks for providing more info. So, another doubt, if detecting spam is trivial, then why not just send the detected spam to trash directly without any human inspection? This may mean some trouble for the posters due to false positives; but the moderator's job can be reduced to some extent. I hope, this is useful. If not, please forgive me for causing more reading trouble for you. Regards, -Damodar On Fri, Aug 3, 2012 at 7:29 PM, Gwern Branwen gwe...@gmail.com wrote: On Mon, Jul 30, 2012 at 6:59 PM, Alexander Solla alex.so...@gmail.com wrote: We could even have a report spam button on each page, and if enough users click on it (for a given revision), the revision gets forwarded to a moderator. This would be useless. The problem is not detecting spam, since that's quite trivial: it's very hard to miss. The problem is that the moderator (ie. me) is already overworked. The spam needs to be reduced to begin with, not detected. -- gwern http://www.gwern.net ___ 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
