[Haskell-cafe] What does it mean to derive equations of restricted from in Haskell?
In John Hughes's The Design of Pretty printing library paper, he says: The implementations which we are trying to derive consist of equations of a restricted form. We will derive implementations by proving their constituent equations from the specification. By itself this is no guarantee that the implemented functions satisfy the specification because we might not have proved enough equation But if we also check that the derived definitions are terminating and exhaustive then this property is guaranteed What does restricted form mean? What is the meaning and significance of definitions are terminating and exhaustive? -- Daryoush Weblog: http://onfp.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What does it mean to derive equations of restricted from in Haskell?
Daryoush Mehrtash dmehrtash at gmail.com writes: What does restricted form mean? non-restricted: e.g., f (f x y) z = f x (f y z)) restricted: the shape of function declarations in Haskell (where lhs is a pattern) definitions are terminating ... non-termination: an equation like f x y = f y x when you orient it as a rule f x y - f y x, there are infinite derivations and exhaustive non-exhaustive: you have an equation f (x : ys) = ... but you don't have an equation for f [] = ... (all the above is is standard stuff in algebraic specification, equational reasoning, etc.) - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Automatic error traces
It is important to have execution traces in case of error. specially in server applications that run 24/7 such are web applications Thanks to the wonderful package monadloc by Pepe Iborra, now MFlow can generate a complete execution trace in case of error. The control-monad-exception uses monadLoc to generate stack traces, but MFlow makes use of his backtracking mechanism to generate a complete execution trace. Here I explain what and how: http://haskell-web.blogspot.com.es/2013/07/automatic-error-trace-generation-in.html The MFlow version that implements this is in gitHub. Not in hackage yet. https://github.com/agocorona/MFlow I´m quite proud of it since it is one of the things closest to magic that I have done. Feedback? I do not want to keep MFlow as a single person development. I think that it has many unique and nice features not available in other languages and frameworks, and it can be raised to a serious exploitation level by the Haskell community. This will attract people working in Industrial Web development to Haskell thanks to the edge in expressiveness and safety necessary for creating industrial solutions that Haskell has over other languages. It uses most other Haskell web developments blaze, wai, hamlet etc and there are many other things to come. monadLoc : http://hackage.haskell.org/package/monadloc -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ordNub
Francesco Mazzoli f...@mazzo.li writes: import qualified Data.HashSet as S nub :: Hashable a = [a] - [a] nub = S.toList . S.fromList Well, the above is not stable while Niklas’ is. But I guess that’s not the point of your message :). We could also implement Data.BloomFilter.nub, which removes equal elements probabilistically (with a small but non-zero chance of removing some unique elements) :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle problems?
No idea why it has gone down, my guess is that the Apache rule that says treat it as a CGI script got changed to serve it as a file. In the meantime you can use a copy of Hoogle at: https://www.fpcomplete.com/hoogle Thanks, Neil On Mon, Jul 15, 2013 at 5:19 PM, Niklas Hambüchen m...@nh2.me wrote: OK, but why does it need to go down for migration? On Mon 15 Jul 2013 23:52:02 SGT, Daniel F wrote: The web site is migrating. IRC says: Topic for #haskell: haskell.org in the middle of migration; expect turbulence; use www.haskell.org ___ 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] TH splicing and recompilation checking
Hi. we are using template Haskell to splice in some code that is produced by reading and transforming the contents of another file. now, if this other file is touched (by editing), but not the main file, then ghc (and cabal) do not realize that the main file does need to be recompiled. is there a way to tell them about the dependency? (example main file: https://github.com/apunktbau/co4/blob/master/CO4/Test/Queens.hs) - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TH splicing and recompilation checking
Yup, such a thing exists! I think it's a little bit obscure because for some bizarre reason it isn't reexported by Language.Haskell.TH: http://hackage.haskell.org/packages/archive/template-haskell/2.8.0.0/doc/html/Language-Haskell-TH-Syntax.html#v:addDependentFile -Michael On Tue, Jul 16, 2013 at 10:41 AM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: Hi. we are using template Haskell to splice in some code that is produced by reading and transforming the contents of another file. now, if this other file is touched (by editing), but not the main file, then ghc (and cabal) do not realize that the main file does need to be recompiled. is there a way to tell them about the dependency? (example main file: https://github.com/apunktbau/co4/blob/master/CO4/Test/Queens.hs) - J.W. ___ 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] TH splicing and recompilation checking
There is a GHC ticket about implementing a DEPENDS pragma for doing this [0]. There are patches attached, but it looks like it isn't finished yet. Erik [0] http://ghc.haskell.org/trac/ghc/ticket/4900 On Tue, Jul 16, 2013 at 7:41 PM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: Hi. we are using template Haskell to splice in some code that is produced by reading and transforming the contents of another file. now, if this other file is touched (by editing), but not the main file, then ghc (and cabal) do not realize that the main file does need to be recompiled. is there a way to tell them about the dependency? (example main file: https://github.com/apunktbau/co4/blob/master/CO4/Test/Queens.hs) - J.W. ___ 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] Call for Papers IFL 2013
Hello, Please, find below the third call for papers for IFL 2013. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL CALL FOR PAPERS 25th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2013 RADBOUD UNIVERSITY NIJMEGEN, THE NETHERLANDS ACM In-Cooperation / ACM SIGPLAN AUGUST 28 - 30 2013 Landgoed Holthurnsche Hof http://ifl2013.cs.ru.nl We are proud to announce that the 25th edition of the IFL series returns to its roots at the Radboud University Nijmegen in the Netherlands. The symposium is held from 28th to 30th of August 2013. Scope - The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2013 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2013 will use a post-symposium review process to produce the formal proceedings which will be published in the ACM Digital Library. All participants of IFL 2013 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Invited Speaker --- Lennart Augustsson, currently employed by the Standard Chartered Bank, well-known for his work on Haskell, parallel Haskell, Cayenne, and Bluespec, is the invited speaker of IFL 2013. He will be talking about practical applications of functional programming. Submission Details -- Submission deadline draft papers: July 31 Notification of acceptance for presentation: August 2 Early registration deadline: August 7 Late registration deadline:August 14 Submission deadline for pre-symposium proceedings: August 21 25th IFL Symposium:August 28-30 Submission deadline for post-symposium proceedings:November 11 Notification of acceptance for post-symposium proceedings: December 18 Camera-ready version for post-symposium proceedings: February 3 2014 Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Papers are to be submitted via the conference's EasyChair submission page: https://www.easychair.org/conferences/?conf=ifl2013 Topics -- IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2013, please contact the PC chair at ri...@cs.ru.nl. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time
Re: [Haskell-cafe] TH splicing and recompilation checking
I think you want qAddDependentFile in Language.Haskell.TH.Syntax http://hackage.haskell.org/packages/archive/template-haskell/2.7.0.0/doc/html/Language-Haskell-TH-Syntax.html On Tue, Jul 16, 2013 at 05:41:19PM +, Johannes Waldmann wrote: Hi. we are using template Haskell to splice in some code that is produced by reading and transforming the contents of another file. now, if this other file is touched (by editing), but not the main file, then ghc (and cabal) do not realize that the main file does need to be recompiled. is there a way to tell them about the dependency? (example main file: https://github.com/apunktbau/co4/blob/master/CO4/Test/Queens.hs) - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe pgpJqUt8gyZ03.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] Automatic error traces
That's great. We should collaborate on this. I wrote the file-location package and Michael Snoyman wrote monad-logger: both of these give file location information. I also added command tracing to Shelly (which could also benefit from this kind of thing) and recently released rollbar for error notification and would like to have as much line info as possible for that. On Tue, Jul 16, 2013 at 5:45 AM, Alberto G. Corona agocor...@gmail.comwrote: It is important to have execution traces in case of error. specially in server applications that run 24/7 such are web applications Thanks to the wonderful package monadloc by Pepe Iborra, now MFlow can generate a complete execution trace in case of error. The control-monad-exception uses monadLoc to generate stack traces, but MFlow makes use of his backtracking mechanism to generate a complete execution trace. Here I explain what and how: http://haskell-web.blogspot.com.es/2013/07/automatic-error-trace-generation-in.html The MFlow version that implements this is in gitHub. Not in hackage yet. https://github.com/agocorona/MFlow I´m quite proud of it since it is one of the things closest to magic that I have done. Feedback? I do not want to keep MFlow as a single person development. I think that it has many unique and nice features not available in other languages and frameworks, and it can be raised to a serious exploitation level by the Haskell community. This will attract people working in Industrial Web development to Haskell thanks to the edge in expressiveness and safety necessary for creating industrial solutions that Haskell has over other languages. It uses most other Haskell web developments blaze, wai, hamlet etc and there are many other things to come. monadLoc : http://hackage.haskell.org/package/monadloc -- Alberto. ___ web-devel mailing list web-de...@haskell.org http://www.haskell.org/mailman/listinfo/web-devel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FP Complete Accepting Submissions for Haskell Competition
We are excited to share we are accepting submissions for our *FP Haskell Competitionhttps://www.fpcomplete.com/business/competition/competition-overview *. Your code and tutorials can earn you $1,000 in cash prizes each month. We're looking for sample Haskell projects that solve specific real-world engineering and business problems. There is no limit to how many projects you can submit or how many times you can win. - $1,000 cash prize for the winning entry each month - $500 each to the 3 runners-ups - There may be none at all if none meet the winning criteria The contest kicks off August 1, 2013. To participate, you'll need to sign up for our FP Haskell Center Betahttps://www.fpcomplete.com/business/haskell-center/overview. We look forward to seeing your submissions and highlighting the talent of this great Haskell community. if you have any questions, please contact us at competit...@fpcomplete.com. -- Natalia Muska Marketing Manager FP Complete, Inc. nata...@fpcomplete.com 865-506-6513 skype: natalia.s.muska ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Wrapping all fields of a data type in e.g. Maybe
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
default = Cfg False
The user can override the defaults one of two ways, either via a config
file, or from the command-line. If both are specified, the command-line
takes precedence. The way I do this is with,
data OptionalCfg = OptionalCfg { verbose :: Maybe Bool }
And then I define I Monoid instance for OptionalCfg which lets me merge
two ofthem. Once the two OptionalCfgs are merged, I merge *that* with
the default Cfg.
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped in Maybe?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrapping all fields of a data type in e.g. Maybe
On Tue, Jul 16, 2013 at 04:57:59PM -0400, Michael Orlitzky wrote:
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped in Maybe?
You can always try
data Cfg f = Cfg { verbose :: f Bool }
and set f to Maybe or Identity depending on what you use it for. It will be
slightly notationally cumbersome to extract values from the Identity functor
though.
Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: module-management-0.9.3 - clean import lists, split and merge modules
I am pleased to announce that, after a terrible struggle, version 0.13 of the module-management package is now available on hackage. The performance has been upped from dismal to adequate (about a 30-fold improvement) and many bugs have been fixed. The most important for import cleaning is that it no longer gets confused by tabs. The split and merge operations are vastly more reliable, though it is likely that bugs still lurk. Also, the API has been simplified a little. and the examples in Language.Haskell.Modules have been updated. The documentation should appear soon at http://hackage.haskell.org/package/module-management. On Tue, Jul 2, 2013 at 1:36 PM, David Fox d...@seereason.com wrote: Ok, version 0.11.1 is probably my last upload for a while unless I get some specific requests, as I need to get back to real work. It adds the new splitModule function that lets you specify a function defining which symbols go to which modules, with the old function replaced by a call to splitModules defaultSymbolToModule. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrapping all fields of a data type in e.g. Maybe
On 07/16/2013 09:57 PM, Michael Orlitzky wrote:
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
default = Cfg False
The user can override the defaults one of two ways, either via a config
file, or from the command-line. If both are specified, the command-line
takes precedence. The way I do this is with,
data OptionalCfg = OptionalCfg { verbose :: Maybe Bool }
And then I define I Monoid instance for OptionalCfg which lets me merge
two ofthem. Once the two OptionalCfgs are merged, I merge *that* with
the default Cfg.
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped in Maybe?
One option is to combine OptionalCfg with Cfg, by parameterizing Cfg. If
you make
data Cfg a = Cfg { cfgVerbose :: a Bool }
Then you can choose between Cfg Identity and Cfg Maybe. Furthermore,
these are different types, so you can still have a monoid over Cfg Maybe.
There might be some lens magic that makes working with this easier too.
For example,
verbose :: Lens' (Cfg a) Bool
verbose = cfgVerbose.traverse
Or something to that effect (that actually compiles).
- ollie
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] ordNub
On 14.07.2013 13:20, Niklas Hambüchen wrote:
I've taken the Ord-based O(n * log n) implementation from yi using a Set:
ordNub :: (Ord a) = [a] - [a]
ordNub l = go empty l
where
go _ [] = []
go s (x:xs) = if x `member` s then go s xs
else x : go (insert x s) xs
(The benchmark also shows some other potential problem: Using a state
monad to keep the set instead of a function argument can be up to 20
times slower. Should that happen?)
I cannot say whether this should happen, but your code about can be
straight-forwardly refactored using a *Reader* monad.
import Control.Monad.Reader
import Data.Functor (($))
import qualified Data.Set as Set
-- ifM still not in Control.Monad
ifM mc md me = do { c - mc; if c then md else me }
ordNub :: (Ord a) = [a] - [a]
ordNub l = runReader (go l) Set.empty
where
go [] = return []
go (x:xs) = ifM ((x `Set.member`) $ ask)
(go xs)
((x :) $ local (Set.insert x) (go xs))
test = ordNub [1,2,4,1,3,5,2,3,4,5,6,1]
Of course, this does not lend itself to an application of filterM.
In fact, your implementation is already in the (Set a -) reader monad,
in normalized form. It looks already optimal to me.
Cheers,
Andreas
--
Andreas AbelDu bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
Ah, now I have the solution:
{-# LANGUAGE CPP #-}
(|) = flip ($)
#define LET(p, e) (e) | \ (p) -
bla = LET(x, 5)
LET(Just x, Just (x+1))
x
#define MLET(p, e) (e) | \ (p) - do
main = do
MLET((x, y), (5, 3))
print (x + y)
Beautiful, ain't it? Sigh.
--Andreas
On 11.07.2013 17:40, Carter Schonwald wrote:
Yup. Nested cases *are* non recursive lets.
(Can't believe I forgot about that )
On Thursday, July 11, 2013, Edward Kmett wrote:
blah = case foo 1 [] of
(x, s) - case bar x s of
(y, s) - case baz x y s of
(z, s) - ...
-Edward
--
Andreas AbelDu bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrapping all fields of a data type in e.g. Maybe
On 07/16/2013 05:06 PM, Tom Ellis wrote:
On Tue, Jul 16, 2013 at 04:57:59PM -0400, Michael Orlitzky wrote:
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped in Maybe?
You can always try
data Cfg f = Cfg { verbose :: f Bool }
and set f to Maybe or Identity depending on what you use it for. It will be
slightly notationally cumbersome to extract values from the Identity functor
though.
Two votes for this approach. I'll give it a try and see whether it comes
out more or less verbose. Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
On 07/11/2013 08:37 AM, AntC wrote: oleg at okmij.org writes: ... In Haskell I'll have to uniquely number the s's: let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ... and re-number them if I insert a new statement. I once wrote about 50-100 lines of code with the fragment like the above and the only problem was my messing up the numbering (at one place I used s2 where I should've used s3). ... Oleg, I hope you are not saying that in production code you use names like x, y, z, s1, s2, s3, s4, ... Depending on context, those can be perfectly good names, modulo the numbering. I'd be more worried about 'foo', 'bar', 'baz'. :o) It leads to opaque code. Questionable. Typically there tends to be more relevant information in the name of an arrow than in the name of a point, with the arrows connecting the points and thus clarifying their meaning. If even you can mess up, what hope for us with only nano-Oleg brain capacity? Non-recursive let. (On a less tongue-in-cheek note, IMHO, assuming that there is something like a constant 'brain capacity' significantly varying between persons that limits how well one can master a certain discipline is a good start for painting oneself into a corner.) Next you'll be wanting GOTO and destructive assignment. Unlikely. Haskell already has constructs which are more expressive than goto and destructive assignment, without requiring the language to give up the benefits of the absence of those features in direct code. Who knows: one day somebody modifying your code might need to insert a line. (That 'somebody' might be your future self.) (That was part of his point.) Just don't do that! Use long_and_meaningful names. 'meaningful' is long enough. 50-100 near-identical lines of code sounds like an opportunity for an algorithm. ... He expressed that he wrote 50-100 lines of code containing such a short fragment and the only problem was inside that fragment. Since the goal of that anecdote presumably was to establish the relevance of a pitfall that a non-recursive let would make less severe, I think this is a more natural way to interpret the only slightly ambiguous wording. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
Brian Marick sent me a couple of his stickers. The one I have on my door reads to be less wrong than yesterday. The other one I keep free to bring out and wave around: An example would be handy about now. All of the arguing to and fro -- including mine! -- about non-recursive let has been just so much hot air. I could go on about how the distinction between 'val' and 'val rec' in ML was one of the things I came to dislike intensely, and how Haskell's single coherent approach is one of the things that attracted me to Haskell. But why should anyone else care? When presented with a difficulty, it is very common for some functional language users to propose adding just one more feature from some other language, commonly an imperative one (which ML, Caml, and F# arguably are). Typically this is something that _would_ solve the immediate problem but would create worse problems elsewhere, and there is some other solution, either one already available in the language, or a better one that would solve additional problems or cause fewer ones. The best help for any discussion is A CONCRETE EXAMPLE OF REAL CODE. Not little sketches hacked up for the purpose of discussion, but ACTUAL CODE. The person who initially proposes a problem may think some details are not relevant, whereas someone else may see them as the key to the solution. For example, looking at some code in another mostly- functional language, which had been presented as reason why we needed a new construct, I rewrote it in less than half the number of lines using existing constructors, using only existing features. Without seeing THE ACTUAL CODE that prompted this thread, it is impossible to tell whether that might be the case here. In this specific case, we are seeing state being threaded through a bunch of updates, and IN THE ABSENCE OF THE ACTUAL CODE, it seems to me that monad notation is the most intention-revealing notation available for the purpose in Haskell, and if Haskell did have non-recursive let it would STILL be best to write such code using a state monad so that human beings reading the Haskell code would have some idea of what was happening, because that's how state changes are supposed to be expressed in Haskell, and anything else counts as obfuscation. But THE ACTUAL CODE might show that this case was different in some important way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wrapping all fields of a data type in e.g. Maybe
The suggestion of parameterizing on a functor would be good, however
there's another approach I've often seen (although it's not quite what
you've asked for). You can leave your config datatype alone, but instead
of making it a monoid have your configuration parsers return functions with
the type (Cfg - Cfg). You can wrap these functions in Endo to get a
monoid, combine them together, and then apply that function to the default
configuration.
On Wed, Jul 17, 2013 at 4:57 AM, Michael Orlitzky mich...@orlitzky.comwrote:
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
default = Cfg False
The user can override the defaults one of two ways, either via a config
file, or from the command-line. If both are specified, the command-line
takes precedence. The way I do this is with,
data OptionalCfg = OptionalCfg { verbose :: Maybe Bool }
And then I define I Monoid instance for OptionalCfg which lets me merge
two ofthem. Once the two OptionalCfgs are merged, I merge *that* with
the default Cfg.
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped in Maybe?
___
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] Wrapping all fields of a data type in e.g. Maybe
Oh, very nice. It seems reasonable to extend this to Cfg - IO Cfg to
support things like dynamically loading config files, if needed.
On Jul 16, 2013 5:42 PM, John Lato jwl...@gmail.com wrote:
The suggestion of parameterizing on a functor would be good, however
there's another approach I've often seen (although it's not quite what
you've asked for). You can leave your config datatype alone, but instead
of making it a monoid have your configuration parsers return functions with
the type (Cfg - Cfg). You can wrap these functions in Endo to get a
monoid, combine them together, and then apply that function to the default
configuration.
On Wed, Jul 17, 2013 at 4:57 AM, Michael Orlitzky mich...@orlitzky.comwrote:
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
default = Cfg False
The user can override the defaults one of two ways, either via a config
file, or from the command-line. If both are specified, the command-line
takes precedence. The way I do this is with,
data OptionalCfg = OptionalCfg { verbose :: Maybe Bool }
And then I define I Monoid instance for OptionalCfg which lets me merge
two ofthem. Once the two OptionalCfgs are merged, I merge *that* with
the default Cfg.
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped in Maybe?
___
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] Wrapping all fields of a data type in e.g. Maybe
On 07/16/2013 08:41 PM, John Lato wrote: The suggestion of parameterizing on a functor would be good, however there's another approach I've often seen (although it's not quite what you've asked for). You can leave your config datatype alone, but instead of making it a monoid have your configuration parsers return functions with the type (Cfg - Cfg). You can wrap these functions in Endo to get a monoid, combine them together, and then apply that function to the default configuration. I'm using cmdargs for the command-line parsing, and I think (if I don't want to abandon its magic entirely) that I'm stuck filling a data structure automatically. I settled on using (Maybe Foo) so that the default value returned by cmdargs will be Nothing if the user doesn't supply that option; if I use a plain Cfg object, and the user doesn't pass --verbose, I'll get False back in its place and then I don't know whether or not that should override the config file (supposing the user has verbose=True in the file). Very clever though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
