From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA07884 for caml-redistribution; Tue, 5 Oct 1999 10:21:47 +0200 (MET DST) 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 HAA06975 for ; Tue, 5 Oct 1999 07:38:25 +0200 (MET DST) Received: from www.nextsolution.co.jp (www.nextsolution.co.jp [202.33.212.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id HAA02743 for ; Tue, 5 Oct 1999 07:38:22 +0200 (MET DST) Received: from sparc1.nextsolution.co.jp (sparc1 [202.235.80.1]) by www.nextsolution.co.jp (8.8.7/3.7W) with SMTP id OAA24672; Tue, 5 Oct 1999 14:35:43 +0900 (JST) Received: from sparc1.nextsolution.co.jp by sparc1.nextsolution.co.jp (SMI-8.6/SMI-SVR4) id OAA08748; Tue, 5 Oct 1999 14:37:48 +0900 From: "Frank A. Christoph" To: "John Prevost" Cc: "CAML Mailing list" Subject: RE: A propos de monad/About monads Date: Tue, 5 Oct 1999 14:48:53 +0900 Message-ID: <000301bf0ef5$4e5da6c0$0150ebca@nextsolution.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: weis > I spent some time last year working with monadic parsers--this is > another really nice way to use monads (especially if you have monad > comprehensions.) > ...[example omitted]... Ah! Parsers a great example of a useful monad without side-effects; I can't believe I forgot to mention them. Actually, though, I have been using Swierstra & Duponcheel's parser combinators (they are much more efficient) for a while now and these, as is now well-known, cannot be expressed as a monad. Interested people can find out about them at: http://www.cs.uu.nl/groups/ST/Software/Parse/ > Unfortunately, this kind of thing (along with other higher-order > combinator stuff for, as an example, formatted printing) doesn't work > that well in ML because of the value restriction. :( Yes. And maybe one reason I didn't mention parsers is that combinator languages like this do not work as nicely in eager languages like ML as they do in non-strict ones like Haskell. Aside from the fact that you have to eta-expand lots of definitions, eager evaluation also forces you to turn recursive operators like (say) the Kleene star into primitives, whereas in a lazy regime you can define them at the object level, i.e., in terms of other combinators. I guess you got around this by using the Lazy module...? --FAC