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 f1CIkJH21486 for ; Mon, 12 Feb 2001 19:46:19 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1CIkJd30319 . for ; Mon, 12 Feb 2001 19:46:19 +0100 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 f1CIkIM06622 for ; Mon, 12 Feb 2001 19:46:18 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09524.16304F80" 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 TAA20661 for ; Mon, 12 Feb 2001 19:46:17 +0100 (MET) 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 f1CIkEM06599 for ; Mon, 12 Feb 2001 19:46:14 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <13.E7ACC292@mail.listserv.gmd.de>; Mon, 12 Feb 2001 19:46:07 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 489014 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 12 Feb 2001 19:46:03 +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 TAA15549 for ; Mon, 12 Feb 2001 19:46:02 +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 TAA09378 for ; Mon, 12 Feb 2001 19:46:03 +0100 Received: from musse.tninet.se (musse.tninet.se [195.100.94.12]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with SMTP id f1CIk3u25248 for ; Mon, 12 Feb 2001 19:46:03 +0100 (MET) Received: (qmail 8209 invoked from network); 12 Feb 2001 19:46:00 +0100 Received: from delenn.tninet.se (HELO algonet.se) (195.100.94.104) by musse.tninet.se with SMTP; 12 Feb 2001 19:46:00 +0100 Received: from [195.100.226.139] (du139-226.ppp.su-anst.tninet.se [195.100.226.139]) by delenn.tninet.se (BLUETAIL Mail Robustifier 2.2.1) with ESMTP id 489314.3559.982delenn-s1 for ; Mon, 12 Feb 2001 19:45:59 +0100 In-Reply-To: <14984.9874.886663.642855@istrati.zdv.uni-mainz.de> References: Return-Path: X-Sender: haberg@pop.matematik.su.se Content-class: urn:content-classes:message Subject: Re: Why markup? Date: Mon, 12 Feb 2001 19:44:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Hans Aberg" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3862 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09524.16304F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 19:08 +0100 2001/02/12, Frank Mittelbach wrote: > > -- Again, if there was a better parser at hand, one would not need = to have > > any markup at all, because it would be able to see that `20' is the = object > >give up, unless you want to wait for a parser which "understands" human >language (or write one but don't hand wave it) Writing a parser for English is clearly a research project; see for = example http://lands.let.kun.nl/TSpublic/tosca/ One does not get very far with LALR(1) on this problem (parsing = English), even less far when trying work with a grammar that depends on semantic information. Computer languages such as C and C++ are not strictly = LALR(1), but can be made to parse in such chunks. >how do you do without markup in this case: > > The $a$ in the formula is a variable The usual remark on this: Can you parse it? :-) -- If you can parse it, = it must be possible. Right? -- The general picture, though, is that the more general grammars the parser can handle, the less markup will be needed. >while contrieved i came across that particular problem in math when i = tried to >understand an article in Hungarian (i think) about number theory and = misstook >an "a" being text as part of a longer inline formula because it was >incorrectly coded (by you perhaps?) ie not identifiable easily as math = not >text. Sorry, I don't know Hungarian. Hans Aberg ------_=_NextPart_001_01C09524.16304F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Why markup?

At 19:08 +0100 2001/02/12, Frank Mittelbach = wrote:
> > -- Again, if there was a better parser at = hand, one would not need to have
> > any markup at all, because it would be able = to see that `20' is the object
>
>give up, unless you want to wait for a parser = which "understands" human
>language (or write one but don't hand wave = it)

Writing a parser for English is clearly a research = project; see for example
  http://lands.let.kun.nl/= TSpublic/tosca/

One does not get very far with LALR(1) on this problem = (parsing English),
even less far when trying work with a grammar that = depends on semantic
information. Computer languages such as C and C++ are = not strictly LALR(1),
but can be made to parse in such chunks.

>how do you do without markup in this case:
>
>  The $a$ in the formula is a = variable

The usual remark on this: Can you parse it? :-) -- If = you can parse it, it
must be possible. Right?

-- The general picture, though, is that the more = general grammars the
parser can handle, the less markup will be = needed.

>while contrieved i came across that particular = problem in math when i tried to
>understand an article in Hungarian (i think) = about number theory and misstook
>an "a" being text as part of a longer = inline formula because it was
>incorrectly coded (by you perhaps?) ie not = identifiable easily as math not
>text.

Sorry, I don't know Hungarian.

  Hans Aberg

------_=_NextPart_001_01C09524.16304F80--