[Haskell-cafe] threadDelay

2009-02-09 Thread Immanuel Litzroth
Am I correct in assuming this program should run 100 secs?

import Control.Concurrent
main = do
 threadDelay 10

Why do I get the folling result then?
 ghc -threaded Main.hs -o delay
time ./delay

real0m0.104s
user0m0.001s
sys0m0.002s

Thanks in advance for all your wonderful comments,
Immanuel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

2009-01-16 Thread Immanuel Litzroth
It's a criticism already voiced by the great David Bowie:

My Brain Hurt like a warehouse, it had no room to spare
I had to cram so many things to store everything in there

Immanuel



On Thu, Jan 15, 2009 at 4:34 PM, John Goerzen jgoer...@complete.org wrote:

 Hi folks,

 Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml
 hacker:

 http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/

 It's a great post, and I encourage people to read it.  I'd like to
 highlight one particular paragraph:


  One thing that does annoy me about Haskell- naming. Say you've
  noticed a common pattern, a lot of data structures are similar to
  the difference list I described above, in that they have an empty
  state and the ability to append things onto the end. Now, for
  various reasons, you want to give this pattern a name using on
  Haskell's tools for expressing common idioms as general patterns
  (type classes, in this case). What name do you give it? I'd be
  inclined to call it something like Appendable. But no, Haskell
  calls this pattern a Monoid. Yep, that's all a monoid is-
  something with an empty state and the ability to append things to
  the end. Well, it's a little more general than that, but not
  much. Simon Peyton Jones once commented that the biggest mistake
  Haskell made was to call them monads instead of warm, fluffy
  things. Well, Haskell is exacerbating that mistake. Haskell
  developers, stop letting the category theorists name
  things. Please. I beg of you.

 I'd like to echo that sentiment!

 He went on to add:

  If you?re not a category theorists, and you're learning (or thinking
  of learning) Haskell, don't get scared off by names like monoid or
  functor. And ignore anyone who starts their explanation with
  references to category theory- you don't need to know category
  theory, and I don't think it helps.

 I'd echo that one too.

 -- John
 ___
 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] some ideas for Haskell', from Python

2009-01-15 Thread Immanuel Litzroth
 2) In Python it is possible to import modules inside a function.

   In Haskell something like:

   joinPath' root name =
   joinPath [root, name]
   importing System.FilePath (joinPath)


In Python importing a module has totally different semantics from importing
in Haskell.
I runs the initialization code for the module  makes the names in that
module
available to you code. In Haskell modules are just namespace control, and
you can always
refer to names imported through import X through the syntax X.name.
This means that the local import in Python solves two problems
1) making a name available locally.
2) running initialization code only when a specific function is called.
Neither of those makes any sense for Haskell as far as I can tell.
Immanuel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Taking Exception to Exceptions

2009-01-08 Thread Immanuel Litzroth


 I recommend this paper for info, it's very easy to follow:

 http://www.haskell.org/~simonmar/papers/ext-exceptions.pdfhttp://www.haskell.org/%7Esimonmar/papers/ext-exceptions.pdf

 Austin

That paper cleared up most of my issues and it is amazing that it is
not amongst the papers that are referenced at the top of the the page
describing Control.Exception.
Anyway, there is one more problem I have related to exceptions that is
about forcing strictness. It relates to option parsing. I have an option -t
that says which track from a file of tracks to print. So I go

data Flags = TrackNumber !Int deriving(Read, Show, Eq)

makeTrackNumber :: String - Flags
makeTrackNumber str =
TrackNumber $ read str

options = [GetOpt.Option ['t'] [tracknumber] (GetOpt.ReqArg
makeTrackNumber tracknumber) number of track to show]

Now my main goes
main = do
  args - getArgs
  opts - evaluate $ GetOpt.getOpt GetOpt.RequireOrder options args
  print done getting the opts
  case opts of ...

which of course first prints done getting opts and then throws an
exception if I give it a flag
-t abc. What would be the way to proceed here? Do I increase the strictness
or do I write a handler
around my complete main? Even if I map the exception in makeTrackNumber to
my very own
exception how do I find out which exact call gave a problem i.e. which is
the call stack at the moment
the exception was thrown -- I might use makeTrackNumber in other contexts
too.
Thanks in advance,
Immanuel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Taking Exception to Exceptions

2009-01-07 Thread Immanuel Litzroth
I'm trying to use the new (for me at least) extensible exceptions and
I am little amazed that I cannot get catch, try or mapException to work
without telling them which exceptions I want to catch.
What is the rationale behind this?
How does bracket manage to catch all exceptions?
What should onException do?
Is there some example code that uses these exceptions, or better
documentation?
Thanks in advance,
Immanuel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Why Not Haskell?

2006-08-09 Thread Immanuel Litzroth
Reilly Hayes [EMAIL PROTECTED] writes:

 On Aug 8, 2006, at 1:42 AM, Immanuel Litzroth wrote:


 Reilly Hayes [EMAIL PROTECTED] writes:





 I don't understand your argument. How exactly does the GPL get in the
 way of selling software as an instantiation of business expertise?
 Are you saying that you have the business expertise but customers
 still prefer not to buy your software? Doesn't that just mean that
 your expertise isn't worth much (economic evaluation :-). Or that your
 idea that they were buying expertise was not correct, they were just
 buying the software after all, and now they have an alternative?



 I failed to communicate my case clearly.  The software *is* what is being
 sold.  The *reason* it is valuable is the business expertise required to build
 it.  There are markets with very small populations of people who both
 understand the business thoroughly and can implement solutions.  It makes
 software valuable and makes licensing the most effective way to monetize that
 value.

I am not arguing that licensing would not be a very effective way to
monetize value. 


 Yes I know the business model. Sell them some overpriced software
 charge them through the nose for support, features, training,
 installation, updates 
 Your resentment against the GPL stems from the fact that it makes
 squeezing the last buck out of your clients somewhat harder (in some
 markets). It probably annoys you that you are not dealing with a
 competitor who is making shitloads of money, making some price fixing
 or secret agreements not feasable. Your problem is that just as your
 business practice is not illegal, neither is the GPL.


 This paragraph is way out of line.  You have taken a discussion of the merits
 of using GPL software and turned it into a personal attack.  Attack the
 argument, not the arguer.  It would be both polite and reasonable to tone down
 the hostility if you actually want a discussion.

Yeah, it might have been harsh and I apologize. But I just describe
what I have seen in some of the companies I worked for.  

 I don't have a problem with the GPL.  In my professional life,  I am careful 
 to
 avoid GPL software in those cases where the GPL would interfere with the 
 firm's
 commercial interests.  I certainly don't resent the GPL or those who choose to
 release software under the GPL.  In fact, I can imagine wanting to release 
 some
 kinds of software under the GPL.

 The point I was making was that the GPL *does* get in the way of *some* 
 optimal
 mechanisms of making money.  Which is *fine*.  That is one of the *intents* of
 the GPL.  The argument that I am trying to counter is the one that says open
 source is *always* better for everybody. 

I don't think the *intent* of the GPL is to get in the way of some
optimal ways of making money. Can you tell me which part of the GPL
makes you think? It might have that side-effect though.

 Sometimes, the best thing for the
 owner of the intellectual property is to keep it closed.  There *are* markets
 where monetization of IP is a zero sum game, or worse (if the IP is public,
 nobody makes any money).

I wonder who you see as the participants in this game? A worse than
zero sum game might be interesting if you are one of the people who
score positive and some of the other people have to pay for it. 
Gambling is a fine example.

 I'm not making (or getting involved in) the moral argument about free
 or open
 software.  I will point out that the current good health of Haskell
 owes a
 great deal to Microsoft through the computer scientists they employ. 
 I'm sure
 Haskell has benefitted from the largesse of other companies as well.


 That is definitely wrong. Haskell would be in even greater shape if
 some people who shall remain unnamed had not gone over to Microsoft. I
 foresee an interesting discussion here.


 I don't see how you can say Haskell would be better OR worse off if people
 hadn't gone to work for Microsoft.  It's an entirely hypothetical case and 
 it's
 just not knowable.  My point is much simpler.  Haskell  GHC do benefit from
 the efforts of people being paid by Microsoft.  Microsoft is planning to hire 
 a
 full-time contractor to work on GHC.

It seems irony gets lost so easily in these conversations. You have no
way of knowing what the state of haskell would have been had certain
key contributors to GHC and Haskell not taken jobs at Microsoft. 
Therefore you statement is meaningless and only good for producing
approving nods among people who already agree with what you say. 

 The snarky comment about people who shall remain unnamed is rude.
I did not mean to be rude, and would like to apologize if anyone felt 
personally attacked by this. 
Immanuel

-- 
***
I can, I can't.
Tubbs Tattsyrup

--
Immanuel

Re: [Haskell-cafe] Re: Why Not Haskell?

2006-08-08 Thread Immanuel Litzroth
Reilly Hayes [EMAIL PROTECTED] writes:

 On Aug 7, 2006, at 10:00 AM, Stefan Monnier wrote:
 In any case, making a living by selling a program (as opposed to services
 around that program) is a difficult business.  


 Making a living writing and selling programs for use by a wide audience is one
 thing. But there is a lot of money to be made by developers who really
 understand a complex niche market (assuming the niche is actually populated by
 customers who need and can pay for the product).  And the GPL absolutely gets
 in the way of that.  Because what you're really selling in that kind of market
 is software as an instantiation of business expertise.

I don't understand your argument. How exactly does the GPL get in the
way of selling software as an instantiation of business expertise?
Are you saying that you have the business expertise but customers
still prefer not to buy your software? Doesn't that just mean that 
your expertise isn't worth much (economic evaluation :-). Or that your 
idea that they were buying expertise was not correct, they were just 
buying the software after all, and now they have an alternative?

 Maybe you should thank the FSF for making you doubt: you should really
 think
 very hard about how you're going to make a living off of selling a 
 program,
 even if that program hasn't been anywhere near any GPL'd code.  In all
 likelihood it'll be much easier to earn your money by selling services
 around your program than just the program itself.


 Selling services is much easier if you can tie the services to IP that you own
 exclusively.  It can also double your firm's daily rate on related
 services.  And the economics of selling product (the program) can be  MUCH
 better, assuming people want to use the program.  If they don't, then you 
 don't
 have a service business either.

Yes I know the business model. Sell them some overpriced software
charge them through the nose for support, features, training,
installation, updates 
Your resentment against the GPL stems from the fact that it makes 
squeezing the last buck out of your clients somewhat harder (in some
markets). It probably annoys you that you are not dealing with a
competitor who is making shitloads of money, making some price fixing
or secret agreements not feasable. Your problem is that just as your
business practice is not illegal, neither is the GPL.  

 I'm not making (or getting involved in) the moral argument about free or open
 software.  I will point out that the current good health of Haskell owes a
 great deal to Microsoft through the computer scientists they employ.  I'm sure
 Haskell has benefitted from the largesse of other companies as well.

That is definitely wrong. Haskell would be in even greater shape if
some people who shall remain unnamed had not gone over to Microsoft. I
foresee an interesting discussion here.
Immanuel
-- 
***
I can, I can't.
Tubbs Tattsyrup

--
Immanuel Litzroth
Software Development Engineer
Enfocus Software
Antwerpsesteenweg 41-45
9000 Gent
Belgium
Voice: +32 9 269 23 90
Fax : +32 9 269 16 91
Email: [EMAIL PROTECTED]
web : www.enfocus.be
***
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why Not Haskell?

2006-08-07 Thread Immanuel Litzroth
Brian Hulley [EMAIL PROTECTED] writes:



 I meant even a non-programmer in the sense of  even someone who is
 not a C hacker to show that the threat of people being able to steal
 code from a program is not the only source of problems that GPL could
 impose on a commercial application. No derogatory implication towards
 people who choose not to learn computer programming was intended.


 The GPL itself refers to a cost of distribution, since it recognizes
 such things are not free-in-price.  This is in reference to offering
 a copy of the source code.  The price of a binary copy can be as
 large as desired. Likewise for the cost of support.

 Well I understand the free as in free speech not free beer motto,
 but suppose person A is talented at writing software but prefers a
 peaceful existence and lacks the contacts/refs/desire/energy etc to be
 a consultant or contractor, and has had the bad experience of being
 forced to work extremely long hours with low pay while in an employed
 position, and person B is outgoing, ebullient, and talented at
 marketing and advertising. Now person A spends some years quietly
 writing some code, which uses a GPL library and is therefore GPL'd,
 and sells it, as is his/her right under the GPL to person B. Then
 person B is free, as in free speech to do whatever he/she likes with
 the software, and so in particular could use his/her marketing skills
 to completely undermine person A's one and only hope of earning a
 living, so from person A's point of view the *amortized* effect of the
 GPL is to make his/her software free as in free beer as well.

Then someone discovers a bug in the program of person A. Person B
is being so busy being outgoing, ebullient and effervescent that he
does not easily find the cause of the bug. Moreover the code needs to
be ported to a the new Warthog MacOSX release. Person A being not only
talented but also shrewd now uses the contractual obligations of
person B as leverage to screw him out of most of his previously made
profit for delivering said work. He lived peacefully ever after.

What is this, Economic Analysis by Parable?
Immanuel
-- 
***
I can, I can't.
Tubbs Tattsyrup

--
Immanuel Litzroth
Software Development Engineer
Enfocus Software
Antwerpsesteenweg 41-45
9000 Gent
Belgium
Voice: +32 9 269 23 90
Fax : +32 9 269 16 91
Email: [EMAIL PROTECTED]
web : www.enfocus.be
***
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] if-then-else as rebindable syntax

2006-07-28 Thread Immanuel Litzroth
Doaitse Swierstra [EMAIL PROTECTED] writes:

We alreday are at a stage where first year students trying to master
haskell get error messages like
Bool is not an instance of the class Num
if they accidently write 1 + True (or something equivalent, but less
obvious).

Good! It will prepare them for C++ error messages of several pages
because you forgot to write const next to a member function, thus
make the transition from Haskell to something that pays the rent
easier. 

 In short: you will not make Haskell a lot more popular by attracting
 category theorists, but by making
 transitions from Java and C as smooth and surprise-free as possible
 (and this is already hard enough).

Are we talking about the straw that broke the camel's back?
Are you serious about making Java/C programmers transition to Haskell?
What would be the purpose of that? 
Immanuel
-- 
***
I can, I can't.
Tubbs Tattsyrup

--
Immanuel Litzroth
Software Development Engineer
Enfocus Software
Antwerpsesteenweg 41-45
9000 Gent
Belgium
Voice: +32 9 269 23 90
Fax : +32 9 269 16 91
Email: [EMAIL PROTECTED]
web : www.enfocus.be
***
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Language shootout (reloaded)

2006-02-10 Thread Immanuel Litzroth
Stefan Holdermans [EMAIL PROTECTED] writes:


 Still---and, please, forgive me for this---I feel that us being #1
 now tells us more about the Haskell community than it tells us about
 Haskell.

How to optimize Haskell code:
1) enter it as a test in the great language shootout.
2) wait a few days.
3) download optimized code.
Immanuel

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp

2005-09-21 Thread Immanuel Litzroth
David F. Place [EMAIL PROTECTED] writes:

I was hoping that the examples I requested would be examples of
particular control constructs or extensions to the language's syntax
and semantics.  Though I admit that such things are possible in lisp,
I suspect that their utility is minimal.

Ever heard of the loop macro?
Immanuel Litzroth

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp

2005-09-21 Thread Immanuel Litzroth
Tomasz Zielonka [EMAIL PROTECTED] writes:

 On Wed, Sep 21, 2005 at 08:53:47AM +0100, Immanuel Litzroth wrote:
 David F. Place [EMAIL PROTECTED] writes:
 
 I was hoping that the examples I requested would be examples of
 particular control constructs or extensions to the language's syntax
 and semantics.  Though I admit that such things are possible in lisp,
 I suspect that their utility is minimal.
 
 Ever heard of the loop macro?
 Immanuel Litzroth

 I would be nice if you could give some examples for use of LOOP macro
 that you think would be cumbersome to translate to Haskell.

That was not the original question and I think that would lead to
pointless discussion about the meaning of cumbersome.  
Loop is an example of a control construct that can be implemented by a macro.
One can can discuss it's utility, but it was deemed important enough to be
standardized (by lisp people). It was only one of the macros developed
at that time to do things sequencelike things (series, generators/gatherers were
others) .
Another example is UFFI, basically a bunch of macros to do platform
independent foreign function interfaces.
I a currently writing a macro to generate the functions and
datastructures to read an ipod database. This allows me to
declaratively say
(defheader (header-name inherits-from) 
   (field-name length optional reader)...).
I doubt this would be easy in Haskell (maybe with TH it could be done) 
since I build a list of (header-name . (field-names ...)) at compile
time which is then used to generate code that locally binds these 
to the result of reading them so that readers can refer to fields
already read e.g.
(let* ((field-name (reader stream)))
  ((field-name2 (reader field-name1 stream))

Immanuel

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp

2005-09-21 Thread Immanuel Litzroth
David F. Place [EMAIL PROTECTED] writes:

 On Sep 21, 2005, at 3:53 AM, Immanuel Litzroth wrote:

 Ever heard of the loop macro?

 Yes, the loop macro is a good example for the argument against lisp.
 Lisp has features to support iteration that date back to the time
 before it was understood that tail recursion is equivalent to
 iteration. 
 In fact, even in the early '90s most common lisp compilers
 didn't implement tail-merging.  I doubt there is any program
 implemented using the loop macro that couldn't be more elegantly
 implemented recursively.  
 In fact, when writing in lisp or scheme, I
 always write recursively now that I can depend on compilers to tail-
 merge.

I personally find loop usually the most concise way to express my
iteration requirements.  
Immanuel

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe