Tomasz Zielonka wrote:
and handle options as functions from Config to Config:
I find this approach very convenient, but I push it a bit further. Some
time ago I wrote a small article about this:
http://www.haskell.org/pipermail/haskell/2004-January/013412.html
[from there]
-- Here
On Tue, May 02, 2006 at 02:27:28PM +0200, Mirko Rahn wrote:
But how to handle dependencies between options using this technique? I
can image two solutions:
1: Every dependency 'a implies b' has to be checked in both functions,
the one for a and the one for b.
2: An order for the actions has
Hello Anton,
Friday, April 28, 2006, 12:54:44 AM, you wrote:
I really trying to avoid imperative approach. I do have a terribly big
experience in imperative programming (by the way, you might know one
application that I made about 3 years ago. It is Uni-K Sensei for
no. but may be you are
On Thu, Apr 27, 2006 at 02:26:22AM +0300, Einar Karttunen wrote:
On 26.04 11:29, Anton Kulchitsky wrote:
I just started to study Haskell and it is my almost first big experience
with functional languages (except Emacs Lisp and Python). I enjoyed all
small exercises and started a bigger
Tomasz Zielonka wrote:
On Thu, Apr 27, 2006 at 02:26:22AM +0300, Einar Karttunen wrote:
and handle options as functions from Config to Config:
Option ['i'] [input] (ReqArg (\x c - c { infile = Just x }) file) input
file name
I find this approach very convenient, but I push it a bit
Hello Anton,
Wednesday, April 26, 2006, 11:29:16 PM, you wrote:
I just started to study Haskell and it is my almost first big experience
with functional languages (except Emacs Lisp and Python). I enjoyed all
small exercises and started a bigger business writing a general utility.
you are my
On Thu, Apr 27, 2006 at 03:10:32PM +0400, Bulat Ziganshin wrote:
i don't like the GetOpt interface (it returns a list of options what
is unusable for high-speed application)
This got me interested. I assume that you measured performace and it
wasn't fast enough.
How many command line args you
Hello Tomasz,
Thursday, April 27, 2006, 4:45:45 PM, you wrote:
On Thu, Apr 27, 2006 at 03:10:32PM +0400, Bulat Ziganshin wrote:
i don't like the GetOpt interface (it returns a list of options what
is unusable for high-speed application)
This got me interested. I assume that you measured
Bulat Ziganshin wrote:
Hello Tomasz,
[snip]
ultimately, the main problem of all options-parsing stuff i ever seen,
is requirement to repeat option definition many times. if i have, say,
40 options, then i need to maintain 3 to 5 program fragments that deal
with each option. something like this:
On 27.04 12:32, Mirko Rahn wrote:
So it would be much better to define the options in the library and to
provide this definitions to the user program somehow. I tought about
this topic several times and came up with a solution that works for me
but is far from being perfect. It uses
I find this approach very convenient, but I push it a bit further. Some
time ago I wrote a small article about this:
http://www.haskell.org/pipermail/haskell/2004-January/013412.html
I was not the first one to use the approach but I felt that it should be
made more popular. Perhaps I
Hi Bulat,
thank you very much for such a detailed reply!
I just started to study Haskell and it is my almost first big experience
with functional languages (except Emacs Lisp and Python). I enjoyed all
small exercises and started a bigger business writing a general utility.
you are my
Brian Hulley wrote:
moduleOptions = ComposedOption My module [ModOption1, ModOption2]
moduleOptions = Option $ ComposedOption My module [ModOption1, ModOption2]
allOptions = ComposedOption Name of program [Module1.moduleOptions,
allOptions = Option $ ComposedOption Name of program
I wrote an option parser that infers everything about the options from
the types of what you pull out of it so there is no need to specify
redundant information and you can write very concise code (especially when
combined with
the overloaded regex module!)
like for instance
main = do
Hi all,
I just started to study Haskell and it is my almost first big experience
with functional languages (except Emacs Lisp and Python). I enjoyed all
small exercises and started a bigger business writing a general utility.
However, I have a problem from the beginning. The utility get some
On 26.04 11:29, Anton Kulchitsky wrote:
I just started to study Haskell and it is my almost first big experience
with functional languages (except Emacs Lisp and Python). I enjoyed all
small exercises and started a bigger business writing a general utility.
However, I have a problem from
16 matches
Mail list logo
