GREL Functions vs Controls

[Owen Stephens]

I'm writing some documentation and a question occurred to me. Why are the GREL Controls:

isBlank

isNonBlank

isNull

isNotNull

isNumeric

isError

Controls rather than Functions? The current documentation says

There are inline controls to support branching and essentially looping. They look like functions, but unlike functions, their arguments don't all get evaluated down to value before they get run. A control can decide which part of the code to execute and can affect the environment bindings. Functions, on the other hand, can't do either. Each control decides which of their arguments to evaluate to value, and how.

https://github.com/OpenRefine/OpenRefine/wiki/GREL-Controls

But while I see this is true of the other controls (with, if, forEach, filter etc.), the 'isX' family don't seem (to me) to fulfil the definition of a Control as defined here.

Is there any reason these are put with Controls rather than functions? And if not, any view on reorganising them into functions?

Thanks

Owen 

[Thad Guidry]

They were used as arguments for controls typically and not used on their own typically.  No other reason. We can move them to Functions if you want.

-Thad

--
You received this message because you are subscribed to the Google Groups "OpenRefine Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrefine-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Morris]

From a practical point of view, one of the main distinguishing features of controls is that you can't say

    foo.isBlank()

like you can with functions, but instead have to say

    isBlank(foo)

If you try it, you'll get "Unknown function isBlank()"  I suggest leaving the documentation organization as it is so that it parallels the implementation.

Tom

[David Huynh]

A function would automatically bubble up any error in any argument whereas a control can consume errors and return normally. The isX controls must be able to consume errors in order to be useful even if there's some error within their arguments.

[Thad Guidry]

Yeah I never liked that however Tom. I always liked to be able to define my expression and then ask a question about it...feeling more natural.

-Thad

[isao matsunami]

Eye-opener.

2018/11/01 12:51、Thad Guidry <thadg...@gmail.com>のメール:

[Owen Stephens]

 On Wed, Oct 31, 2018, 5:36 PM Tom Morris <tfmo...@gmail.com wrote:

From a practical point of view, one of the main distinguishing features of controls is that you can't say

    foo.isBlank()

like you can with functions, but instead have to say

    isBlank(foo)

If you try it, you'll get "Unknown function isBlank()"  I suggest leaving the documentation organization as it is so that it parallels the implementation.

Thanks Tom. I definitely wouldn't just want to change the documentation. I was thinking about updating the code so that you could write these expressions in both ways - I tend to use the dot notation both for myself and when I deliver documentation/training to others because I think it gives more readable expressions.

Owen

[Owen Stephens]

On Thursday, November 1, 2018 at 5:47:42 AM UTC, David Huynh wrote:

A function would automatically bubble up any error in any argument whereas a control can consume errors and return normally. The isX controls must be able to consume errors in order to be useful even if there's some error within their arguments.

Thanks David - that's an interesting and potentially useful distinction which I've not found documented anywhere. However it doesn't seem to be true of all controls - only the 'isX' and 'with' seem to follow this pattern.

Thanks to all for the feedback so far - I'm going to reflect on it and may raise some github issues or PRs if I feel it is worthwhile after giving it more thought

Owen

[Thad Guidry]

Dot notation FTW. 😀
Sure Owen. But having a smarter GREL editor that auto completes etc. might also help ease uncomfort we have here like auto closing parenthesis, syntax highlighting, etc. Something to think about towards alternative ways to handle these isX things.

-Thad

--