The special case for Filter assumes that DecodeParms are always present

[bdoubrov]

Currently Stream and other stream-based objects define the special case condition

fn:Eval(fn:ArrayLength(DecodeParms) == fn:ArrayLength(Filter))

for both Filter and DecodeParms keys. As a result, the following perfectly valid use case:

<<
/Filter [/FlateDecode]
% no DecodeParms
...
>>
stream
...
endstream

is reporting an error because of the special Filter condition.

There are two ways to fix this:

1. either remove completely the special case for Filter
2. or replace Filter special case condition by

fn:Eval(fn:IsPresent(DecodeParms,fn:ArrayLength(DecodeParms) == fn:ArrayLength(Filter)))

The same applies to FFilter and FDecodeParms keys.

[faceless2]

This caught me too the first time around. If DecodeParms is not present, then fn:ArrayLength(DecodeParms) doesn't evaluate to zero, it evaluates to undefined, which makes the whole expression undefined. See #30

[petervwyatt]

As @faceless2 says...

[petervwyatt]

See also #47 - just linking issues to keep track of related discussions

[bdoubrov]

Not sure if this is the best place to continue the discussion on the formal logic, or reopen #30. But as this issue is still open, I leave the comment here.

While the general use of undefined for missing properties is fine, I see some issues that the current Arlington boolean logic is not aligned with ECMAScript that also supports undefined. See https://tc39.es/ecma262/multipage/global-object.html#sec-undefined

The key difference is that the expression (a == undefined) is always false in JavaScript, while is undefined in Arlington.

Is there a fundamental problem in aligning Arlington boolean logic with ECMAScript one?

[petervwyatt]

Yes - I'm trying to use predicate logic, NOT functional programming logic.