Re: Moving away from an expression language

I think it is critical to think about this from a data flow
perspective.  There are two important and distinct uses of the
expression language:

1. To compute values for use in options
2. To control which flows are allowed to execute

(1) is an essential distinction that our data flow language has and is
really an syntactic compaction of a reusing the result of a particular
flow in the context of an option value.

(2) is more critical but consider that at the end of the day we need
to evaluate a boolean test.  Any sequence can be converted to a
boolean and we should consider the same in a data flow context.

We can push the comparison into the expression being evaluate and just
require default semantics for converting a sequence of values in the
data flow into boolean.

Afterwards we can consider syntactic measures to shorten or make these
more usable.

We want the operations done in the steps and very little in flow
language.  Following that goal, expressions are steps that we need to
make really easy to use.


On Fri, Feb 19, 2016 at 6:55 AM, Liam R. E. Quin <liam@w3.org> wrote:
> On Wed, 2016-02-17 at 22:43 +0100, James Fuller wrote:
>> These are interesting ideas though after thinking about it for a few
>> days I am less sure about how we would spec this and what it gives
>> our
>> users.
>>
>> I think we both agree that getting rid of the expr language does not
>> get rid of the need for choose/if switching.
>
> And you need to have expressions inside the if and choode, and for that
> you need an expression language.
>
> The ability to say, "if the document uses feature x, do y", seems
> fairly central, and that's sounding dynamic.
>
> Liam



-- 
--Alex Miłowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Friday, 19 February 2016 22:13:54 UTC