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 PAA28938; Thu, 29 Apr 2004 15:40:50 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA28924 for ; Thu, 29 Apr 2004 15:40:49 +0200 (MET DST) Received: from smtp.mbg.ocn.ne.jp (mbg.ocn.ne.jp [210.190.142.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3TDelYM011172 for ; Thu, 29 Apr 2004 15:40:48 +0200 Received: from localhost (p48100-adsau14honb7-acca.tokyo.ocn.ne.jp [221.187.101.100]) by smtp.mbg.ocn.ne.jp (Postfix) with ESMTP id 0A1DD5B77; Thu, 29 Apr 2004 22:40:46 +0900 (JST) Date: Thu, 29 Apr 2004 22:40:36 +0900 (JST) Message-Id: <20040429.224036.75426712.yoriyuki@mbg.ocn.ne.jp> To: jgoerzen@complete.org Cc: ben@socialtools.net, caml-list@inria.fr Subject: Re: [Caml-list] Re: Common IO structure From: Yamagata Yoriyuki In-Reply-To: <20040429130335.GA11323@excelhustler.com> References: <20040428214442.GE10198@excelhustler.com> <20040429.192746.48535796.yoriyuki@mbg.ocn.ne.jp> <20040429130335.GA11323@excelhustler.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 yamagata:01 yoriyuki:01 yoriyuki:01 caml-list:01 2004:99 2004:99 0900,:01 yamagata:01 python:01 readline:01 extlib:01 abstractions:01 readline:01 encodings:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: John Goerzen Subject: Re: [Caml-list] Re: Common IO structure Date: Thu, 29 Apr 2004 08:03:35 -0500 > > On Thu, Apr 29, 2004 at 07:27:46PM +0900, Yamagata Yoriyuki wrote: > > > > >Python is simple. One standard for everything. You get read(), > > > > >write(), readline(), readlines(), xreadlines() (hello Extlib, this one's > > > > >for you), seek(), etc. This can apply to files, strings, sockets, > > > > >pipes, whatever. Before we can start fussing about unicode > > > > >abstractions, I think we need to have a uniform I/O layer. > > > > > > > > OK, but then you can leave out readline(), readlines() and xreadlines(), > > > > because they don't make any sense unless you've already dealt with > > > > character encodings. > > > > > > No, they can simply be implemented in terms of read(). > > > > It will break when UTF-16/UTF-32 are used. The line separator should > > be handled after code conversion. At least that is the idea of > > Unicode standard. (But Since Unicode standard is challenged by > > reality in every aspect, maybe nobody cares.) > > You are missing the point. read() could handle the code conversion. No, what I wanted to say is that the line separator should be handled in the Unicode level, not the byte-character level. Your design assumes read() always returns new line characters as in ASCII. This would not hold when read() returns UTF-16/UTF-32. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners