[phc-general] Structured Tags pre-processor

[Satyam]

----- Original Message ----- 
From: "Edsko de Vries" <edsko at phpcompiler.org>
To: <phc-general at phpcompiler.org>
Sent: Thursday, August 10, 2006 12:15 PM
Subject: Re: [phc-general] Structured Tags pre-processor


> Hey,
>
>> I re-wrote and expanded the initial document actually explaining the
>> code I made and referring to PHC.   I have downloads of my code,
>> including the patch files for PHC.
>
> Where?
>

The files are there but in individual links, I didn't make a sinple download 
package, which is probably what I should have, you are right.

>> I was wondering if I could redo the patches so that
>> they can be better isolated from the original files, the references to
>> line numbers in the patches wouldn't work in further releases.
>
> I don't know how you generate your patches; I usually use diff -Nu (or
> diff -Nur for a recursive diff) which generates a "unified" diff which
> is reasonably insensitive to line number changes.
>

I used Subversion to do the diff, but subversion actualy calls diff, so that 
is what I have, though when looking at the patch since it gave specific line 
numbers, I thought it used and enforced them, though it contains lines 
before and after which might allow it to find the right position even if 
things are moved a little.  Good, then.

> But perhaps it is easier if you simply provide an already-patched
> version of phc, user's might prefer that to having to patch phc
> themselves (note also that since you require a patched version anyway,
> perhaps it is easier to hardcode the plugins into the phc binary; the
> only change you have to make to do that is to use process_ast in
> process_ast/process_ast.cpp instead of a process_ast in a plugin).
>

So I would need to put my code under that process_ast and the regular make, 
not the script to compile plugins, will make a version of phc with my plugin 
in it?  Cool!   I'll try that, regarding offering it for download, the 
license agreement covers that for sure but I hate to read those things, 
basically, you guys don't mind if I do?


>> >Have you any ideas on how to the the schema validation? That might be
>> >a slightly more difficult problem to tackle.
>> >
>> I know, and it scares me!  My idea is to read the XSD file in memory,
>> using the DOM representation and have a pointer to where I'm currently
>> at, then as I reach each tag, attribute or escaped echo node, see if
>> it matches the alternatives the XSD offers at that point and update
>> the pointer to that state.  The pointer would have to be pushed to the
>> stack and a new pointer set, according to the xmlschema declaration
>> for that function. These xmlschema declarations would be scanned in
>> the first pass to save these declarations in the method_declaration
>> map (new members have to be added to the class description) so that
>> they can be checked when the method is called.  The stack with the
>> pointer to the schema will also be used when finding flow-control
>> statements.
>>
>> This, of course, is no more than the general idea, which, as usual,
>> will not last long after the first tests.  I can't figure out yet what
>> to do when functions are declared elsewhere (includes), have no schema
>> declaration or when using variables for tags or attributes.  This is
>> one reason why I didn't want full expressions for tag_names, just
>> literals (the best option for validation) or variables (I had to
>> provide some flexibility) though variables ruin the validation.
>
> Perhaps it is easier to support DTDs instead? Schemas are big and ugly,
> and have lots of features; good support for DTDs might be easier to
> implement.
>

I have (or at least had) this funny idea that DTDs were on their way out and 
XSDs were the way of the future.  That future seems to be too distant so 
I'll fall back on DTDs.  Actually, I didn't plan to really follow all the 
XSD, there is much more information there that I could possibly check for 
anyway.  The nice thing about XSDs is that I had the loading of it solved. 
I am still looking for a DTD parser, found plenty in Java, one in c# (I 
guess that's the closest) one in perl, another in Lisp, a couple in 
languages I never heard about (besides Haskell, I mean ;-) )  Doing one in 
C++ from scratch .... well, it might be interesting.   By the way, talking 
about Lisp, can you imagine:

(html (head(title 'This is a web page in HTMLisp ))(body (h1 'Hi there! )))

We complained about parenthesis back then, now we have plenty of angled 
brackets and we are all so happy!  We´ll be punching cards (made of carbon 
fibre or some such) any day now, and we'll call it a great invention!  We 
could have been spared of JavaScript, HTML and all that, Lisp all the way 
and that's it.

Satyam




> Edsko
> _______________________________________________
> phc-general mailing list
> phc-general at phpcompiler.org
> https://altoure.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/phc-general
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.10.8/415 - Release Date: 09/08/2006
>