Re: find with XPath over file system

Hello!

>   By the way, it's one of the reasons why I'd like to implement a method
> to compile XPath to Scheme source code: it would be possible to modify
> behaviour of XPath evaluation.

So, if the separately compiled code includes a call to a library
function `foo', you might think that the behavior of the code could be
modified if we do (set! foo something-else) before the code is run?
But that is not guaranteed to work! What if `foo' was actually a
macro? What if the compiler saw the definition of `foo' and inlined
it? What if the compiler saw that foo must return an integer (e.g.,
Bigloo's optional type declarations) and compiled the code in such a
way so to avoid redundant checks. If you set! foo to something that
may return #f, the code is going to crash. Also, R5RS specifically
says that changing the behavior of primitives (like car) may or may
not affect the behavior of functions that use these primitives (e.g.,
map).

See R5RS, Section 6:

] A program may use a top-level definition to bind any vari-
] able. It may subsequently alter any such binding by an
] assignment (see 4.1.6). These operations do not modify
] the behavior of Scheme's built-in procedures. Altering any
] top-level binding that has not been introduced by a defini-
] tion has an unspecified effect on the behavior of the built-in
] procedures.

That is, doing (set! car something) is not guaranteed to affect `map',
because `map' is built-in procedure (the first paragraph of Sec 6
specifies that the set of library procedures is a subset of built-in
procedures), and R5RS `car' is not introduced by a definition (because
it is present in the initial environment already).

BTW, the use of `eval' to compile XPath to Scheme source code is only
reliable if only free variables in the expression to `eval' are
built-in procedure identifiers. Thus, to be reliable, the expression
to compile must be essentially closed, and one should use
(scheme-report-environment 5) or (null-environment). As to
(interaction-environment), it is declared in R5RS an _optional_
procedure. Furthermore, R5RS specifically does not specify which
bindings are shared between the host program and the evaluated
expression. The Report merely says

] This procedure [(interaction-environment)] returns a specifier for the
] environment that contains implementation-defined bindings, typically a
] superset of those listed in the report. 
 
Note the word `typically' and `superset' (without any qualifications
how big that superset can be). 

In practice, interaction between a separately compiled code and an
interpreter is very tricky. Bigloo insists on special declarations. If
the shared bindings are going to be mutated, they have to be
specifically described as such. Gambit too has special conventions:
(declare block). If the code was compiled when `(declare block)' was
in force, mutations to top-level bindings will have no effect.

> > It is true that R5RS permits an implementation to do an implicit
> > `forcing' of a delayed computation

>   It's interesting. I can't remember such things in R5RS. Would you please
> point me to it?


Please see Sec 6.4, the end of the subsection of `force'

]- Some implementations may implement "implicit forc-
]  ing," where the value of a promise is forced by primi-
]  tive procedures like cdr and +:
]       (+ (delay (* 3 7)) 13)       =       34

	Cheers,
	Oleg


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl