Re: Factual error was Re: Brainstorming: Best of all Worlds

Cameron McCormack:
> >Static analysis of programs doesn’t correspond to solving the halting
> >problem, depending on what sort of analysis you need to do.  If one of
> >the conditions for a calculate attribute is that its expression  
> >needs to
> >halt, then yes, that’s obviously a problem.  From my reading, the  
> >static
> >analysis that’s required by XForms Transitional is just the dependency
> >analysis, which should always be possible.  Whether it comes up with
> >useful dependencies without resorting to evaluating some of the
> >expressions during the analysis is another matter though…

Maciej Stachowiak:
> Evaluating expressions during analysis would mean you can't guarantee  
> your static analysis will terminate, so the analysis would indeed not  
> be Turing-decidable.

The key word is “some”, though.  If the evaluation is restricted to some
subset of expressions that you know (from the syntax) to be simple
operations, then you won’t run in to the problem.

> >  document
> >  document.forms
> >  document.forms[0]
> >  document.forms[0].field
> >  document.forms[0].field.value
> >  document.forms[0][document.forms[0].field.value]
> >  document.forms[0][document.forms[0].field.value].value
> 
> I don't think this corresponds to dependencies in the sense of XForms  
> transitional, since you can't turn this into a list of form elements  
> whose values you depend on.

Right.  So here the expression is doing lots of script work (looking up
names and properties) when the intention is really just to access two
fields in the form.  Without careful evaluation (simple property
getting–which couldn’t even be guaranteed to be safe in the presence of
getter functions on the objects) the implementation can’t know that it’s
just looking at two fields.

> And consider how much worse things get if the user code uses eval().

Exactly.

> >If any of these values change, then the form field with the calculate
> >attribute on it needs to be recomputed.
> >
> >Static analysis wouldn’t allow the implementation to determine the
> >
> >  document.forms[0][document.forms[0].field.value]
> >
> >dependency, since it depends on whatever the current value of the
> >‘field’ field is.  That’d mean it has to watch all form fields in 
> >form
> >number 0.  If the calculate attribute is in that same form, then that
> >just introduced a cycle into the dependency graph.
> 
> Failing on everything that's impossible to statically analyze would  
> certainly be one possible approach.

That could be an option, too.

> >That’s true.  From IRC earlier, discussing a simple use case of
> >automatic “order totals” in forms:
> >
> ><heycam> i think such things would be easier with things like
> >  calculate=""
> ><heycam> (if calculate="" were done properly)
> ><heycam> but (and this is the big "but" that is going to cover much of
> >  the discussion in this group, i think), it's the backwards
> >  compatibility / fallback issue that is troublesome for such  
> >proposals
> ><heycam> if you need to write script to fall back when there's no
> >  support for calculate="", then you may as well forget writing the
> >  calculate="" in the first place
> 
> You skipped Ian's remarks that calculate="" might not even be  
> suitable to real-world examples of an order form.

Yeah (which might be the case; I’d like to see a complex enough order
form that is difficult to do just with an event handler–while I think
using calculate="" should nearly always be easier, I don’t know if the
implementation cost of the one-way constraint system is worth it there).
I was just including my and schnitz’s comments as further discussion
about the issue of introducing non-easily-fallbackable(!) features.

> A JS subset could lead to a sensible design, but it would amount to  
> inventing a new language.

Yes, but it’d be better than a completely different novel syntax, I
think.

> Constraining expressions would also mean  
> you still need the DOM events for the cases where you want to do  
> something more than a simple constraint or calculation, such as  
> checking other documents on the page, contacting a server via  
> XMLHttpRequest, etc.

I wouldn’t advocate throwing DOM events out. :)  Just because something
more complex cannot be achieved with these expressions doesn’t by itself
mean that they don’t have value.

> In any case, it would be nice to hear a proposal that is tight enough  
> to actually work, although I think the feature of declarative  
> constraints still needs to be checked against actual use cases on the  
> web.

Agreed.  (I think the more complex layout expressions (especially with
bounding box calculations and things) I was using in CSVG benefitted
more from the minimal recomputation that you get from the dependency
graph than this order example.)

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Friday, 23 March 2007 06:48:30 UTC