From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,f72c7d988369817f
X-Google-Attributes: gid103376,public
From: Ted Dennison <dennison@telepath.com>
Subject: Re: Ada 95 S/W Eng
Date: 2000/07/18
Message-ID: <8l1mou$m2a$1@nnrp1.deja.com>#1/1
X-Deja-AN: 647763447
References: <8kvb9c$r13$1@slb7.atl.mindspring.net>
 <uzongqwpw.fsf@gsfc.nasa.gov> <3973A59B.75E0FD00@freeoutpost.com>
X-Http-Proxy: 1.0 x65.deja.com:80 (Squid/1.1.22) for client 204.48.27.130
Organization: Deja.com - Before you buy.
X-Article-Creation-Date: Tue Jul 18 13:40:49 2000 GMT
X-MyDeja-Info: XMYDJUIDtedennison
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.7 [en] (WinNT; I)
Date: 2000-07-18T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <3973A59B.75E0FD00@freeoutpost.com>,
  Jeff Parke <webmaster@freeoutpost.com> wrote:
> It certainly seems to me that "gate" from the GTKAda package could be
> combined with TED's OpenToken in interesting ways...especially since
> I have a client clamoring for XML.

There is rudimentary HTML support in OpenToken, thanks to Christ Grein.
But I'd love to see someone submit good XML support.

I've been using GTKAda for the last few days, and I'd really like to see
something interesting done with XML there too. In particular, I'd like
to see something similar to Motif's UIL support. I was really
disappointed in the way Glade spits out tons of files that have to be
hand-edited (and thus hand-merged when the GUI changes).

I should also mention that I've been working on a *new* parsing
mechanism for OpenToken, which will be released as a beta version
shortly. It was inspired by ANTLR. So instead of being table driven like
lex, it helps you to build recursive-decent (LL) parsers. I like this
approach better than the old LR approach for the following reasons:

   o  There's no complicated up-front table-building, which is more
in-keeping with the OpenToken approach for lexical analysis.
   o  Parsing errors should be easier to debug, as you can just step
through the parse routines. With the current parser you'd have to search
the machine-generated table for bad entries, and try to figure out why
the builder put them there.
   o  Parsers can now be usefully inherited from and extended.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.