Rudolf Adamkovič <salutis@me.com> writes:

> A slight correction is in order, as my proposal was simpler.

Actually, scratch that.  It would not work, of course.  Boy, am I
confused sometimes!  Phil got it _perfectly_ right.

I apologize for the noise!

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't.  That's logic.'"
-- Lewis Carroll, Through the Looking Glass, 1871/1872

Phil Hagelberg <phil@hagelb.org> writes:

> During yesterday's Fennel User Group meeting we discussed some ideas
> about cleaning up the syntax for pattern matching [...]

Thank you for a great summary, Phil!

> This replaces `&or` in the pattern side with `&` as the body, which
> causes that body to evaluate to the body for the next pattern.

A slight correction is in order, as my proposal was simpler.

I meant for `&` to fall through to the next _pattern_, not to "evaluate
to the _body_ of the next pattern".  In simple words, and combined with

Phil Hagelberg <phil@hagelb.org> writes:

> I'll go ahead and push this removal.

Fantastic, thank you!

Should we also rename 'error-match' to
'error', now that there is only one way to
assert on errors?

When I compare

  (faith.error-match
    ".*: index out of bounds"

Phil Hagelberg <phil@hagelb.org> writes:

> Nice catch; thanks. Applied and pushed. Sorry for the delay.

Fantastic, thanks!

Any comment on this:

> I did not check nor fix 'faith.error', as I
> never use it.  Also, do we still need it, now
> that we have 'faith.error-match'?  One can
> explicitly match against ".*" if they need
> to.  That said, either way, this patch is
> orthogonal to fixing or removal of the

---
This patch fixes

  (faith.error-match "oops" (fn [] nil))

passing with flying colors.

At Egghead Games, we test all "reachable"
errors, as per the awesome Test-Driven
Development (TDD), which is why this bug bit
us today.  So, here is a fix!

P.S. #1:
[message trimmed]

Andrey Listopadov <andreyorst@gmail.com> writes:

> Yes, but then you will still need to use
> the multiple-value binding syntax inside
> the clause: (&or (1 2) (3 4)) for case to
> match on either 1 and 2 or 3 and 4 values,
> [...]

Correct.

> [...] so what's the point of using []?  Is
> there any semantic difference between (&or
> ...) and [&or ...]?

Andrey Listopadov <andreyorst@gmail.com> writes:

> We're matching on a data structure here, so
> using &in in the data structure is weird,
> because it implies it matches this or that
> IN the data structure.  In the previous
> example parens are kinda like a calling
> convention, not a multiple value
> convention.

Sorry for not being clearer.  I see both
multiple values and tables as "data
structures".  Consider

Phil Hagelberg <phil@hagelb.org> writes:

> If we use a bare `in` symbol then there is a potential for conflict with
> existing identifiers. [...] a "directive".

That makes perfect sense!

So, &-prefixing would instantly solve 3
problems:

  1. reader confusion,
  2. macro hygiene, and
  3. basic disjunctions.

Phil Hagelberg <phil@hagelb.org> writes:

> [...]

Gotcha!

> The proposal solves the overloading of `or` by replacing it with `&in`
> but then goes on to split up the clause form. But once you've replaced
> `or` with `&in`, you've already solved the problem; why keep going?

So, that would give us, if I understand correctly:

(&in PATTERN+)
(&where (&in PATTERN+) GUARD+)

Thank you for the initial replies!

To scale the discussion a bit, I basically
see two problems with the current syntax:

P1. Simple disjunctions, which are common,
are not simple:

    (where (or ...))

P2. The 'or' and 'where' forms look like
ordinary function or macro calls, yet they
are something else entirely: