[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: No side effects holy cow. ( Re: process order (still...)

Subject: RE: No side effects holy cow. ( Re: process order (still...) )
From: Khun Yee Fung <KFung@xxxxxxxxxx>
Date: Mon, 24 Apr 2000 18:20:29 -0400
side effects of braces
I was caught up in something else the whole week last week. Sorry.

It seems like I am drifting to discussions outside of XSLT. I think we
should move any further discussion off the mailing list.

-----Original Message-----
From: Paul Tchistopolskii [mailto:paul@xxxxxxx]

>And I don't think that 'assignable variable' 
>is evil concept, because we are using boxes to store  things 
>inside the boxes. 

I do not think mutable variables are evil as well. In fact, I am still more
proficient in C than anything else. I used to program Perl all the time. I
enjoyed every second of it. Especially when I could use closures in Perl
(for Perl/TK). And of course, I assign anonymous subroutines to variables in
Perl, pass them in other subroutines, and then call them...

No, I have nothing against mutable variables. I was just saying that adding
mutable variables to XSLT may not be the best way of solving the problems. I
mentioned SQL because it is a very nice and tight language. I guess if we
could have the equivalent of stored procedures for XSLT then we would have
the best of both worlds.

In summary, no holy cow either way.

[... description of result-tree processing deleted ...]

This is getting very interesting. I know what you mean. I spent the last 6
months (not fulltime, of course) thinking about a generic way of doing tree
transformation using some ideas from XSLT. These are some of the points:

1. I really like the template idea. I consider this idea one of the most
significant in the last few years. The flexibility it brings to programming
is fascinating. This is ultimate dynamic processing.

2. I really like the idea of producing the result tree. For me it is a new
paradigm. I also want to keep it with modifications.

3. I want to be able to look at the result tree and possibly modifying it
when I am still producing it.

4. I think I need a different way of doing tree matching. I want to be able
to say, find a subtree in the input tree that has a specific structure. For
instance, I want to be able to label a node (or a subtree) in the pattern,
and then say some other place in the tree has the identical (or similar)
node (or subtree). [See point 7 also]

5. I want to be able to specify an adaptor for the input, as long as the
adaptor filters the input and outputs an XML tree. Same thing with the
output. I want to be able to specify an adaptor that will create the final
format with the XML trees I have created. In other words, I want to keep the
processing on purely XML trees.

6. I want to elevate the status of a template to a module, with helpers
inside the module, so that encapsulation can be done easily. I do not
consider named-templates central to the new paradigm but nevertheless very
useful as helpers (to avoid templates that are 10 pages long with
repeatative code).

7. I want to be able to extend a template. Anologous to inheritance in OO, I
want the extension idea to reuse code and pattern. I think the extension can
have two facets: one for extending the pattern to make it more specific. One
for extending the module of the template to modify the result tree created
by the template.

I don't have my notebook with me so these are all I can think of for this
message. I apologise if the descriptions are vague and hard to visualize.

I started designing a language that fulfills all these things a few weeks
ago. Hopefully, if other things do not distract me, I will finish writing
the language report by the end of summer. (Of course, I will either find so
many holes in my thinking that I give up doing it, or I will finish the
report and shelf it right away as a paper exercise that will never see the
light of day.)

As much as I would like to say more about this language I have in mind, it
is not XSLT related. So I will stop.

>That's what makes me happy, because all the innovation in this world 
>get's implemented by those lazy developers with bad attitude who are 
>tired of typing more keystrokes than they have to.

I should have explained this better. I like the critical attitude (but not
personal attacks). Like you say, this is how we improve. What I meant to say
was that they did not want to know exactly how it worked before they
dismissed it out of hand. I could see their eyes telling me: `I do not need
to know this'. Perhaps it was a failure on my part to explain it better.

I am not sure what I should think about the number of keystrokes part. On
one hand, I do not like the cluttering of characters on my screen. On the
other hand, I do appreciate the ease of  tag matching in XML. I do not
believe XML should be as terse as Lisp or even Java (We ask people to
comment the closing braces when they are too far away from their opening
braces, right?). And I loath to give up having data and instructions in the
same notation. I learned Perl because I refused to program in sh+sed+awk; I
just cannot switch my brain fast enough to handle three sets of semantics at
the same time.

>I understand, 
>such a view is rare between scietists, who for some reasons
>( unclear to me) think that scientists deserve more respect
>for the things they are doing. ( Please, don't get this personal - 
>I very much enjoyed your letters and I don't think you are making 
>any difference between developers and scientists. ;-)

Actually, I was trained as a computer scientist but I never had the chance
of being one. When I graduated, the job market was way too tight for me to
get a professorship (Or I was not good enough. Choose your interpretation.).
I became a software engineer instead. So, I won't take it personally.

Regards,
Khun Yee


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.