Add new algorithm: either() #3395

nordlow · 2015-06-08T09:54:45Z

Thanks to D's lazy parameters this new variadic function either simplify pattern matching.

either() is similar to Python/Lisp's or. Same as Phobos's any but returns first parameter value which implicitly convert to true, or last argument otherwise. I guess any could be modified but that would cause breakage on its return type.

I've found real use of either()in various parsing contexts.

I'm very open to changing the namings if you feel they are misguiding.

Note that either currently cannot be nothrow because of issue https://issues.dlang.org/show_bug.cgi?id=12647

DmitryOlshansky · 2015-06-08T17:24:20Z

2 things to note:

lazy had awful codegen last time I've seen it
tryEvery is quite non-obvious in how it expects each lazy parameter to affect the same haystack it then restores on failure. A simpler approach is to just make each parameter a callable that accepts ref S whole.

DmitryOlshansky · 2015-06-08T17:26:23Z

std/algorithm/comparison.d

+    {
+        if (result)
+        {
+            results ~= result;


These array appends would be highly problematic for the performance of a parser...

Done. I return fixed length bool array instead.

DmitryOlshansky · 2015-06-11T14:14:56Z

@nordlow Please do not merge with master, do:

 # if upstream is dlang/phobos  remote
git pull --rebase upstream master

nordlow · 2015-06-12T10:42:40Z

I just realized that it's better for tryEvery to return either a

a bool true upon matching of all arguments, false otherwise,
a size_t counter that somehow indicates how many arguments that could be matched or
a Voldemort struct with count member and implicit bool conversion rules that enables the nice idiom

if (const hit = haystack.tryEvery(needles...) 
{
    // do something with `hits.count`
}

I prefer the last alternative as it will harmonize with the interface of the pending

#3288

What do you guys think?

andralex · 2015-06-12T16:41:11Z

std/algorithm/comparison.d

+    impossible to mark either() as nothrow. Issue at
+    https://issues.dlang.org/show_bug.cgi?id=12647
+*/
+CommonType!Ts either(Ts...)(lazy Ts a) if (a.length >= 1)


Nice, two things:

Could you please try whether it's possible to accept/return by reference? I.e. either(a[0], a[1]) = 1; should work. But I don't think auto ref cooperates nicely with lazy.

A predicate would help, e.g. choose either non-empty string: auto s = either!(s => !s.empty)(param, "default");. In fact I think such use would be most useful.

You need to ensure here that CommonType!Ts is not void.

MetaLang · 2015-06-12T18:39:07Z

I'd like to propose a different implementation for either. I think an iterative approach is preferable for efficiency reasons.

CommonType!Ts either(Ts...)(lazy Ts a) 
if (a.length >= 1 && !is(CommonType!Ts == void))
{
    foreach (ai; a)
        if (ai) 
            return ai;

    return a[$ - 1];
}

CyberShadow · 2015-06-17T04:29:12Z

So either/every are any/all except they return non-bool? Does the distinction make them useful enough to add considering the overlap in function? Can we change any/all instead?

Yes, either/every operate on a tuple, and any/all on a range. But seeing as the functions require that they have a common type, you can use any/all with only, right?

tryEvery seems too specialized for Phobos.

DmitryOlshansky · 2015-06-24T08:58:44Z

tryEvery seems too specialized for Phobos.

+1 I'd also point out non-obvious conventions in its usage.

nordlow · 2015-06-25T10:53:28Z

Made either and every iterative instead.

MetaLang · 2015-06-25T13:16:30Z

std/algorithm/comparison.d

+    foreach (ref e; a[0 .. $ - 1])
+        if (e)
+            return e;
+    return a[$ - 1];


This will return a[$ - 1] even if it's falsy.

So which lvalue should be returned if all parameters bool-convert to false? We can't use CommonType!Ts.init because that's an rvalue. Any ideas on this, @andralex?

It seems that the only sensible thing to do would be to throw an exception or assert, but that seems too heavy for such a small function. Maybe have the user provide a default value? It doesn't really make sense, but I don't see much of an alternative. What do Python and Lisp do when all values evaluate to false?

Python:

assert((0 or False) is False) assert((False or 0) is 0) assert((False and 0) is False) assert((0 and False) is 0) assert((0 or None) is None) assert((None or 0) is 0)

Emacs Lisp:

(and 0 nil) => nil (and nil 0) => nil (or 0 nil) => 0 (or nil 0) => 0

IMO the important thing here is to have the same behaviour for l-values as for r-values. If so I see three alternatives here:

Mimic Python's behaviour (in order to get same behaviour for l-value and r-value returns);

either returns last argument upon no true-conversion

every returns first argument upon no true-conversion

If default value is supplied return it upon failure for r-value overloads of both either and every. For the l-value overload we could force the default value to be an l-value via ref parameter in this case, right?

Throw Exception (if no default value is supplied).

What do you think?

Ping. I'm sensing we need a voting on this matter.

@andralex ?

My standing point here is a behaviour that is easy to remember.

should be fine as is

nordlow · 2015-06-27T21:01:32Z

The latest commit contains a todo; there's a problem with the conversion trait. It doesn't work with arrays. Is there an alternative trait?

JakobOvrum · 2015-09-01T07:36:23Z

std/algorithm/comparison.d

+
+    TODO: Is inout Conversion!T the correct return value?
+
+    NOTE: Lazy parameters are currently, too restrictively, inferred by DMD to


It's not just nothrow, it's all function attributes.

edit:

Or not. Huh.

So should I remove this comment for now or tell that no attributes can be inferred?

andralex · 2015-10-29T14:27:20Z

Couple more nits and we're ready to go... again :o).

nordlow · 2015-10-29T16:52:46Z

After my latest changes in the first either-overload we need to restrict it to not allow it when all variables are l-values. This in order for the second overload to kick in. How do I do that? Because of this the unittest for either now deliberatly fails as

comparison.d(2017,11): Error: either(x, delegate int() => y) is not an lvalue

andralex · 2015-10-29T18:56:44Z

Regarding lvalues: I'd say let's just forgo them.

nordlow · 2015-10-29T19:35:58Z

Ok @andralex , removed l-value ref overload
Updated to use pred(T.init) instead of pred(T())
Removed array-check from ifTestable().
Moved ifTestable to std.traits
Added docs to ifTestable
Added static unittests for ifTestable to prove that pred is indeed evaluated

IMO, we're ready.

andralex · 2015-10-29T20:05:47Z

std/algorithm/comparison.d

+    if (alternatives.length >= 1 &&
+        !is(CommonType!(T, Ts) == void) &&
+        ifTestable!T &&
+        allSatisfy!(ifTestable, Ts))


Just replace these two lines with allSatisfy!(ifTestable, T, Ts)

andralex · 2015-10-29T20:07:09Z

One last nit. Then I preapprove (it sounds... oxymoronic).

nordlow · 2015-10-29T20:11:16Z

Done!

andralex · 2015-10-29T20:15:27Z

Auto-merge toggled on

andralex · 2015-10-29T20:15:36Z

thx!

nordlow · 2015-10-29T20:16:02Z

Great!

nordlow · 2015-10-29T20:20:11Z

Just realized that we can make use of typeof(return) in

CommonType!(T, Ts) either(alias pred = a => a, T, Ts...)(T first, lazy Ts alternatives)
    if (alternatives.length >= 1 &&
        !is(typeof(return) == void) &&
        allSatisfy!(ifTestable, T, Ts))

Would that be preferrable in other PRs to reduce redundancy and perhaps number of instantiation tries?

Add new algorithm: either()

JakobOvrum · 2015-10-30T04:54:31Z

This still isn't passing the predicate to ifTestable, despite my comments...

nordlow · 2015-10-30T10:41:46Z

Should we revert and fix, @andralex ?

andralex · 2015-10-30T12:37:27Z

@nordlow just create a new PR. Thanks @JakobOvrum

nordlow · 2015-10-30T12:51:22Z

Ok, I can add the typeof(return) in it too.

nordlow changed the title ~~Add new algorithms either(), every() and tryEvery()~~ Add new algorithms: either(), every() and tryEvery() Jun 8, 2015

DmitryOlshansky reviewed Jun 8, 2015
View reviewed changes

andralex reviewed Jun 12, 2015
View reviewed changes

nordlow force-pushed the either-and-every branch from 8c5c1ec to 12bb64e Compare June 25, 2015 10:42

nordlow changed the title ~~Add new algorithms: either(), every() and tryEvery()~~ Add new algorithms: either(), every() and tryAll() Jun 25, 2015

MetaLang reviewed Jun 25, 2015
View reviewed changes

JakobOvrum reviewed Sep 1, 2015
View reviewed changes

nordlow force-pushed the either-and-every branch 3 times, most recently from 504017b to da6fd86 Compare October 29, 2015 16:48

nordlow force-pushed the either-and-every branch from da6fd86 to 97f66d4 Compare October 29, 2015 16:55

nordlow force-pushed the either-and-every branch 3 times, most recently from ec32762 to f86922f Compare October 29, 2015 19:35

nordlow force-pushed the either-and-every branch 2 times, most recently from 71e550f to c91ed83 Compare October 29, 2015 19:59

andralex reviewed Oct 29, 2015
View reviewed changes

Add algorithm either() and trait allSatisfy()

c46a463

nordlow force-pushed the either-and-every branch from c91ed83 to c46a463 Compare October 29, 2015 20:11

andralex added a commit that referenced this pull request Oct 29, 2015

Merge pull request #3395 from nordlow/either-and-every

168d96d

Add new algorithm: either()

andralex merged commit 168d96d into dlang:master Oct 29, 2015

wilzbach mentioned this pull request Jan 29, 2018

Turn enforce into an eponymous template + undocument enforceEx #6086

Merged

nordlow deleted the either-and-every branch October 19, 2021 19:45


		TODO: Is inout Conversion!T the correct return value?

		NOTE: Lazy parameters are currently, too restrictively, inferred by DMD to

Add new algorithm: either() #3395

Add new algorithm: either() #3395

Conversation

nordlow commented Jun 8, 2015

DmitryOlshansky commented Jun 8, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DmitryOlshansky commented Jun 11, 2015

nordlow commented Jun 12, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MetaLang commented Jun 12, 2015

CyberShadow commented Jun 17, 2015

DmitryOlshansky commented Jun 24, 2015

nordlow commented Jun 25, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nordlow commented Jun 27, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andralex commented Oct 29, 2015

nordlow commented Oct 29, 2015

andralex commented Oct 29, 2015

nordlow commented Oct 29, 2015

Choose a reason for hiding this comment

andralex commented Oct 29, 2015

nordlow commented Oct 29, 2015

andralex commented Oct 29, 2015

andralex commented Oct 29, 2015

nordlow commented Oct 29, 2015

nordlow commented Oct 29, 2015

JakobOvrum commented Oct 30, 2015

nordlow commented Oct 30, 2015

andralex commented Oct 30, 2015

nordlow commented Oct 30, 2015