Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f1FAJIH12704 for ; Thu, 15 Feb 2001 11:19:18 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1FAJId10068 . for ; Thu, 15 Feb 2001 11:19:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09738.C1195700" Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1FAJHM15867 for ; Thu, 15 Feb 2001 11:19:17 +0100 (MET) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id LAA20501 for ; Thu, 15 Feb 2001 11:19:16 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1FAJGM15859 for ; Thu, 15 Feb 2001 11:19:16 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <14.942150B3@mail.listserv.gmd.de>; Thu, 15 Feb 2001 11:19:08 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488566 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 15 Feb 2001 11:19:13 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id LAA08222 for ; Thu, 15 Feb 2001 11:19:11 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id LAA44410 for ; Thu, 15 Feb 2001 11:19:12 +0100 Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1FAJDx07969 for ; Thu, 15 Feb 2001 11:19:13 +0100 (MET) Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1FAJBd10063 .; Thu, 15 Feb 2001 11:19:11 +0100 In-Reply-To: Return-Path: X-Sender: Content-class: urn:content-classes:message Subject: Re: Side remarks about TeX input sequence Date: Thu, 15 Feb 2001 11:19:06 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: =?iso-8859-1?Q?Rainer_Sch=F6pf?= To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3935 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09738.C1195700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu, 15 Feb 2001, Hans Aberg wrote: > > Compaq OpenVMS and IBM OS/MVS are two examples > > Are these OS's in continued widespread use, or are they dying? -- The = thing > is that without those OS line separator convetions, one can decide = that a > line separator should be \l, \r, or a \r\l (as in Java), and that = would be > platform independent. That's totally irrelevant. You are confusing OS level and library level. What you see in Java is at the library level and has near to nothing to = do with the underlying operating system. To take OpenVMS, it has various OS level file formats (both stream and record oriented), many of which can be used for textual data. In every case you can read characters or lines or whatever if your language = library offers the functionality. In Java you see \r\l, in C \n. Platform independence is today implemented at the library level, not the OS level. This was quite different twenty years ago, when OS = capabilities influenced library (and sometimes language) design. TeX the program was influenced by what Pascal (and particular compilers) could do. That's the reason for the implementation in TeX the Pascal program. If you rip it apart anyway, you can redo that bit with or = without changing the way the program behaves. And still, it has nothing to do with input encoding or internal representation. So, let's not get sidetracked. Rainer Sch=F6pf ------_=_NextPart_001_01C09738.C1195700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Side remarks about TeX input sequence

On Thu, 15 Feb 2001, Hans Aberg wrote:

> >       Compaq = OpenVMS and IBM OS/MVS are two examples
>
> Are these OS's in continued widespread use, or = are they dying? -- The thing
> is that without those OS line separator = convetions, one can decide that a
> line separator should be \l, \r, or a \r\l (as = in Java), and that would be
> platform independent.

That's totally irrelevant. You are confusing OS level = and library level.
What you see in Java is at the library level and has = near to nothing to do
with the underlying operating system.

To take OpenVMS, it has various OS level file formats = (both stream and
record oriented), many of which can be used for = textual data. In every
case you can read characters or lines or whatever if = your language library
offers the functionality. In Java you see \r\l, in C = \n.

Platform independence is today implemented at the = library level, not the
OS level. This was quite different twenty years ago, = when OS capabilities
influenced library (and sometimes language) = design.

TeX the program was influenced by what Pascal (and = particular compilers)
could do.  That's the reason for the = implementation in TeX the Pascal
program. If you rip it apart anyway, you can redo = that bit with or without
changing the way the program behaves.

And still, it has nothing to do with input encoding or = internal
representation.

So, let's not get sidetracked.

Rainer Sch=F6pf

------_=_NextPart_001_01C09738.C1195700--