Kirill Lisovsky <lisovsky@...> writes:
> > I would like to continue to support SXPath within Askemos and I have
> > some hope to finally integrate the xslt, xpath etc. code there with
> > the sxpath implementation. The lack of xpath/xslt variables and root
> > prevented that, therefore I considered (read tried) how I would do
> > that.
> Please note that XPath vars (as well as root) are already supported
> by current SXPathlib using explicit passing of additional
Ups. I haven't had the time to check.
This takes me to a totally unrelated point: it is by no means Askemos'
job to care about implementation of XSLT etc. (there is some support
though, because there was not alternative at the time when it was
written) I'd really like to reuse any third party implementation here.
Am I going to the wrong address?
seems not to support any additional parameters? Should the web be
Also this stupid me can't find STX's home at all!? (Except for some
PLT specific binary, which I did not learn how to load.)
Anyway: for some unrelated reasons, I'm forced _not_ to depend on the
SXML data model. It is easy to parameterize the sxpath code to cope
with other data models (all it takes to replace pair?, symbol?
etc. with appropriate functions for the data model), but apparently I
can not automate the job. I did it by hand once and now I'm sort of
forced to track sxpath, which is just too much effort, I can not do
that. Could we aggree on a common set of predicates and accessors to
facilitate broder use of SXPath? It would really help.
> > To sum up: yes, parameters (or thread variables, the rscheme name for
> > parameters, which I tried) seem at first to solve the problem, but to
> > me the drawbacks made it unfeasable. I'll put some comments at the
> > details. I'd propose a different solution, albeit not 100% compatible
> > (I believe): make sxpath a macro with two optional parameters, second
> > and third are variable binding envt and root. The actual converters
> > take nodeset, bindings and root parameter, pass these down and return
> > those three values.
> > Advantages: much clearer to read,
> I can agree with this statement for the cases then this additional
> parameters are in use, but it turns out that a lot (most?) of SXPath application
> are not interested in this parameters. In this case we just have to
> extra dummy parameters to handle...
That's why I proposed a macro with two _optional_ arguments. Maybe
also keyword arguments instead.
> > variables are lexically scoped, no global variables, no threading issues.
> I do agree that a direct passing of these parameters is
> straightforward and simple, yet a decent SRFI-39 implementation with
> thread-local parameters inherited by child threads will eliminate
> any practical problems here, will not it?
True. But this "practical" argument is goes against your other, very
valid arguments concerning the drawbacks of global variables...
I personaly feel that parameters should only be used for "de facto
constants" (with respect to the computation). Things like
"preferences settings", user names, credetials etc. Not for argument
passing. The latter I'd rather like explicit.
But at the end of the day, this is "just" the theoretical argument.
Parameters are easy to implement in any Scheme. Also threading issues
are not exactly the point, DELAY is!
> And one another important thing is extensibility: while an introduction
> of a new parameter is pretty simple in parameterization-based approach
> (a new parameter will be just ignored by an existing applications) it
> leads to backward-incompatibility and bloated list of arguments in case
> of direct passing-based one.
Taken to the extreme, we could use this argument, just put everything
into a parameter and modify the variable name resolution. OK, we
would end up with something like elisp and I would stop using Scheme.
:-( I aggree, parameters are tempting but I don't bye them yet.
No, I don't believe that a few additional parameters should be hidden,
if they actually effect the normal processing.
BTW: As long as XML/XSLT is concerned, we will end up with at most 7
parameters (axis) won't we? OK, _I_ would have use for another two
parameters (often called 'me' and 'msg' in Askemos), but I'd still
rather stick to the longer argument list. Actually the Askemos code
uses a (non hygienic) macro to sort the argument list and use
sensible default values, because, yes, usually only 1-3 arguments are
to be changed.
> > Drawback: Location steps, which are given as user defined procedures
> > will have to be rewritten (add two dummy parameters). We could have
> > macros to assist. (It is actually very unfortune that Scheme doesn't
> > allow to determine the arity of a procedure.)
> That's exactly the main reason for this proposal: an attempt to provide
> var bindings and other variables _without_ unnecessary complication of
> location step functions.
I did understand that. I'm saying that I think the aim of the
proposal is well justified, but after a few experiments, I'm convinced
that the other obvious approach is just less of a pain in the neck.
> > I'd personally depreciate all use of parameters, for the reasons you
> > give later:
> > > 1. Parameters and dynamic binding can be confusing if used for
> > > variable things, because dynamic binding introduces referential
> > > opacity (even if the bindings themselves are immutable). Rebinding
> > > of a lexical variable does not break the referential transparency
> > > because such a variable is captured in a closure and because we can
> > > see the rebinding by inspecting the code from the given point
> > > upwards. Dynamic bindings are not captured in a closure. To see the
> > > rebinding, we need to examine the dynamic history of the process and
> > > potentially all of the code.
> > For me this very argument by itself would be the show stopper already!
> > I believe I lost more time of my life debugging dynamic/global
> > variable bindings than I spent with all other kinds of bugs together.
> > As a SXPath user I'd rather add two unsused parameters to a few
> > applications of mine than taking the risk of globals into tomorrows
> > debug sessions.
> But are you really using a rebinding of root and XPath variables
> in the middle of SXPath query?
Here it's not exactly a matter of doing so or not. Does XPath/XSLT
allow to rebind variables? If yes, then we'll finally have to
implement it in the not too distant future.
> > > It looks like most SXPath queries (at least so far) have empty list
> > > of XPath variables, and queried nodeset as root, so root and XPath
> > > vars may be considered as the objects which in general stays the
> > It looks like that, but only because SXPath doesn't support variables
> > etc. And that's one of the main reasons, why it is of limitted use
> > within the Askemos xslt code. Also at the application code level we
> > would need a way to pass variables until sxpath becomes as useful as
> > it could be.
> Actually, this support is provided since the W3C-compatible
> "textual SXPath" was introduced.
> Some applications (such as STX - mostly for XSLT compatibility)
> employ XPath vars and root, but SXPath query in context of a current node without
> XPath vars is a very popular situation, and it doesn't need any
> additional parameters...
Sorry, I did not understand that.
> > > 3. As it possible to see from the discussion of SRFI-39, it's
> > > unclear how parameters interact with threads. DELAY and parameters is
> > > another dangerous combination.
> > Here I ran up until the point which I call infeasable.
> > My xslt code uses force/delay to evaluate xslt variables only if
> > referenced. If I'd change to eager evaluation, the existing Askemos
> > applications would become unsusable slow. You don't want to do that.
> > In other words: parameters interact badly with functional programming
> > style.
> XSLT variables can't be modified, thus they can be considered as constants
> in these context, which eliminates this particular problem
> (as far as I understand it).
> Yet SRFI-39 and DELAY is a suspicious couple, and this problem has to be
> investigated carefully.
!!! That's what my point is. My XSLT implementation creates a
DELAYed value for each XSLT variable. Only those variable values,
which are actually refenrenced are FORCEd. XSLT variables can be
nested, usual shadow rules apply. Now what's the value of XSLT
variable "name"? That's where I died and decided that I will not give
up the lazy evaluation and not introduce some strange capturing of
"thread variables" - called parameters today. Passed down as normal
arguments the DELAY as well as many other situations, will properly
capture the correct values. No extra code needed.
Another solution would be to extend lambda in such a way, that
parameters are captured like the argument list. I feel that's a bit
too deep inside the Scheme implementation, isn't it? Is there a
The worst of harm may often result from the best of intentions.