OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (OFFICE-2470) 2.2 ExpressionCalculation is a mixure of observations, rules and possible suggestions



    [ http://tools.oasis-open.org/issues/browse/OFFICE-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19010#action_19010 ] 

Eike Rathke commented on OFFICE-2470:
-------------------------------------

For return types: an expression may also return an array or a reference list.

I don't think we can require that evaluators shall
1. Evaluate function parameters in left to right order. 
That is an implementation detail. (Yes, the original text says "Function parameters shall act as if they had been computed in left-to-right order", but I don't think that holds)

For implicit conversions we should say that if no conversion exists, an error shall be returned.

We can't drop the "eager evaluation" aspect of 3.a) completely, is is significant that _all_ argument expressions are evaluated unless an error was encountered and the function propagates errors (which is the usual case unless otherwise noted).


> 2.2 Expression Calculation is a mixure of observations, rules and possible suggestions
> --------------------------------------------------------------------------------------
>
>                 Key: OFFICE-2470
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2470
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: OpenFormula
>            Reporter: Patrick Durusau
>            Assignee: Patrick Durusau
>
> 2.2 Expression Calculation is a mixture of observations, rules and possible suggestions. 
> For example, it starts by saying formulas are recalculated from "outside in," only to confess a few paragraphs later that is how it "appears to the end user." 
> There is one really glaring hole in my proposal, that also exists in the current language.
> We describe the ordering of operators but as far as I can tell, we don't address the situation where there is a mixture of operators and functions.
> Note that I changed #1 from constant number/string and added error.
> As near as I can determine, the only possible outcomes of any expression are:
> 1) a number
> 2) a string
> 3) an error
> 4) a reference
> So, application of these rules self-terminates when any of those conditions obtain.
> Yes, that removes "constant number," "constant string" but those are defined elsewhere anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]