From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA07095; Tue, 4 Sep 2001 19:56:24 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA07161 for ; Tue, 4 Sep 2001 19:56:23 +0200 (MET DST) Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f84HuMf15097 for ; Tue, 4 Sep 2001 19:56:22 +0200 (MET DST) Received: from ip178.usw22.rb1.bel.nwlink.com (ip178.usw22.rb1.bel.nwlink.com [207.202.195.178]) by smtp.nwlink.com (8.9.3/8.9.1) with SMTP id KAA14748 for ; Tue, 4 Sep 2001 10:54:30 -0700 (PDT) Received: (qmail 21204 invoked by uid 500); 4 Sep 2001 17:55:56 -0000 Date: Tue, 4 Sep 2001 10:55:56 -0700 From: Michael Leary To: Jon Moore Cc: caml-list@inria.fr Subject: Re: [Caml-list] flushing stdout with flush stdout not good? Message-ID: <20010904105556.B20346@ip178.usw22.rb1.bel.nwlink.com> References: <20010903193104.A12284@ip178.usw22.rb1.bel.nwlink.com> <200109040253.f842ruW10866@codex.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109040253.f842ruW10866@codex.cis.upenn.edu>; from jonm@dsl.cis.upenn.edu on Mon, Sep 03, 2001 at 10:53:56PM -0400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, Sep 03, 2001 at 10:53:56PM -0400, Jon Moore wrote: > In the code you wrote above, "fso" gets bound to () (and not to a function) > after flushing stdout once. So the name and color functions you wrote are > doing prints, and returning units, rather than invoking the flush as you > thought. Thus, this is why the output becomes bursty (you're not actually > flushing). Heh, a pretty obvious mistake now that I look at it... If it's fully applied it's only the return value, otherwise it's a partially applied function/closure awaiting more args. All that lambda calculus stuff. :) -- ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr