[exprla-devel] Re: [xpl] It's Us....

[reid_spencer <ras...@re...>]

--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
Michael Lauzon wrote:

>  No, XPL has no relation to what you termed XBasic (is that a
> language),

[Gulp...]

Serves me right, I should have spelled the "XBasic" thing
out more precisely. This is one misunderstanding I need to
lay to rest right away.

So far, all that most of us know about what XPL should be
like, is (1) the tag set that you've posted, and (2) the
prototype code which Robert Hopkins posted. My comments
started out from Robert's code, and wandered off into my
thoughts on parsing mechanisms.

Robert, when he introduced his code, said: "Note resemblance
to QBasic." Because of this, and also because my present
concept of XPL is of a language whose grammar is extensible,
and which is therefore in a sense a framework of related
languages, I went and named Robert's code "XBasic" for
temporary reference.

I sure do not want the name to stick. But I did want to
point out something by using it, and I'll expand on it
as follows:

If we set out a list of tags, and some examples of their
use, and then say: "There; now we've defined XPL, once and
for all", then we'd be missing out on something very elegant
and powerful.

Which is, that possibly for the first time ever, the grammar
of a language need not be fixed in concrete from the start.
We have the DTD at our fingertips. Change the DTD and we have
a different version of the language. Even a different language,
to all intents and purposes. Your and Robert's tags give us
an XPL which resembles Basic, but with a little work, we could
adjust it to resemble say, Fortran or Pascal or C.

In the olden days, say the '70s, but it's still the
conventional wisdom, suggesting the idea of an "adjustable"
grammar for a language would have caused heart failures, and
got you thrown into a padded cell for keeps. "But ... compiler
writing is hard work! You need a scanner, and a parser, and
a memory model, and a code generator, and ... (etc). And they
will all be full of bugs, and hard enough to maintain as it is.
If we go adding "adjustments", we'll complicate the compilation
task beyond reason!" they would scream. And more to the point,
"Our clients depend on the fact that the language will be
stable. If the base language begins to spawn all sorts of
extensions, then every time they get a bug, they will have to
work out whether it's their code at fault, or the particular
language extension."

BUT. In the context of XML, these objections no longer have
the same force. Suppose we have designed a new document format,
for describing invoices or something. Does the end user need
to install a special program to view them? No way. Just download
the DTD, which the document itself knows, and maybe a skeleton
parser in Java, and the user has a default program ready-made,
which will traverse the document, check its validity and
print it out. With a little work on the default program, you
can have a document do much more interesting thengs than
print itself out. Like maybe this invoice can wake up once a
day, check the date against its creation date, and email the
reciever saying, "14 days left for payment". E-commerce is
going to be made out of stuff like this.

So, it's the same for programs. If we have a family of XPL
programs, and they all work on the same kind of data, then
okay, they can all be XPL documents using the one DTD.
But different programming languages have different
specialties. And if we have two applications using radically
different kinds of data, then it only makes sense to provide
two versions of XPL, each one with an extension for its
special data type.

Case in point. Suppose we want XPL to have tables in it.
A table is pretty simple to define: just a list of fields,
each named, each with a data type, and some attribute tags.
You'll want to sort it on some of the fields; you'll want
to display table documents in a scrolling window, etc.
LOT OF WORK TO WRITE IT, with just your tags, but it could
be done.

But now, the 21st Century alternative. Teach XPL to read
SQL. How? Easy! Just append a DTD for SQL grammar to the
standard XPL DTD, and add

    | sql-statement

to the standard <xpl-statement> definition. The SQL grammar
already includes the EBNF for tables, and a generic

sql-statement ::= sql-maketable | sql-get-table-row | ...

<sql-make-table> ::= "query" "[" sql-query "]"

<sql-query> ::= [ the usual synatx for SQL queries ]

etc..

There's a bit more handshaking, which I won't do into:
like how to let the SQL part know just what data types
you want it to accept as data fields, and how to search
and sort them. But basically it's a stroll in the park.

In the current programming paradigm, if the Boss suddenly
issues a change order: "Oh, and we want it to have SQL",
well then there's screaming, and running, and staff
explaining to their tearful partners why the vacation
will have to be rescheduled, oh, it's frightful.

I reckon, with XPL technology, the job can be done in
half an hour. If we see the possibilities her and now.

It is basically a matter of regarding DTDs as we now
regard object classes.

> yes...it is us that is doing this work from the ground up;

WOW.

We can make history.

> any suggestions of what I should put on the website?
>

Well, this is where we come in, I think.

Add in an "About Us" page, and then beat on us if we don't
submit our About-Me's. Name, optional email, occupation,
software specialties, favourite languages, and optional
link to a resume.

Then, Links. We should all start keeping lists of any URL
we discover, which is related to XPL, or even just rings
a bell. I would say that XML, Java and scripting-language
sites would take pride of place. It's our web page, so we
really want it to have resource and ideas sites there, where
we can refer to them easily.

And when we submit a site to you, we should also send a
micro-review; as in "Just found this, it's about converting
Pagemaker files to XML. They use GNU m4. Ugh." If we're
feeling energetic, we can submit in-depth reviews. That
will add value to the site, and get people looking at us.

Once we have consensus on the XPL concept, we can add that.
And as soon as we do, you'll need to format up a dateline
page:

13-5-00    Java tutorials available

20-5-00    XP runs minimal parser

27-5-00    XP internals report, <URL>...</URL>
           XP parses <if>, <elseif>, <do> tags

and so on like that.

But mainly, twist our arms til we submit content.

[ sigh ]  Afraid I have to get back to the boring stuff now.

Goodwill
Jonathan

They finally realized that the ONE thing they just could not STAND
was a smartass commenting decompiler.
--- End forwarded message ---