Re: [ANNOUNCE] Anubis language 1.7 release

David RENE schrieb:
> Joachim Durchholz wrote:
Conditionals: Seems to be just normal pattern matching. It's restricted to a single level (no provision for nested patterns), and it has a slightly annoying restriction that patterns must be given in the same orders as the cases of a sum type. There's also a simple exhaustiveness constraint, though that's considerably weakened because you can cheat by saying
if <expr> is <pattern> then <body> else <term>

The conditionals of Anubis are not pattern matching, because pattern matching like in CAML for example, is performed through an ordered set of filters, two of which eventually accepting the datum to be filtered.

Hmm... I'm rather puzzled that you need *two* filters to accept something in CAML. I'd have said there is one filter (the pattern) and a result (the expression).
Would you care to explain what you mean when you say "filter"?

This behavior reflects the fact that the sets defined by filters are not necessarily disjoint. On the contrary, sums in category theory are disjoint unions. When a datum belongs to such a sum, it belongs to one and exactly one member of the sum. This is why conditional have exactly one case per alternative, and heads of cases are not tried one after the other, but a jump is performed directly to the right case. It seems that
pattern matching is inherited from Prolog (and maybe other systems), but for sure not from an analysis of categorical sums. This is somewhat theoretical, but in practice this means (among other things): no exception.

Sure.
I'm not 100% sure, but I think most FPLs have this kind of exhaustiveness checking, too. Whether you get a warning or an error depends on the language's specific design philosophy, I'd guess.

Nested 'patterns' (actually heads of cases in Anubis) could be possible only in the case the second type has only one alternative (for the same reason that all cases must be considered).

Not really - if the language's design goal is to insist on exhausting all possibilities, the programmer would simply have to enumerate all cases.

> The author did not implement
this feature, because he did not find it very useful.

Sure. The Haskell and *ML folks thought otherwise.
Can't tell which variant is more useful in practice.

Furthermore, you would have to unnest in the case you add an
alternative to the second type.

A nested pattern would be something like

Pair (x, Pair (y, z))

No need to unnest here - this is a single-case pattern that deconstructs a Pair of something and a Pair.

This might be useful in other ways. E.g. one could have the following two guards:

Pair (x, Pair (y, y)) -> do something knowing that y = y
Pair (x, Pair (y, z)) -> do something knowing that y != z

(Here guard order matters.) (I'm not sure whether the above can be done in Anubis at all, or whether it's too useful in practice. However, if you have equality tests, then the above is useful, too...)

In Anubis the square root is of type Float -> Maybe(Float), where the type schema Maybe is the same as in Haskell.

OK, that's a valid approach for square roots.

I don't think it's a valid approach in general.
You can't predict all potential problems and wrap them in a Maybe type. There's always the odd bug, the slight oversight, or the outright idiocy in the code, leading to "this can't happen" situations with inconsistent data and/or unattained postconditions. The software must have *some* way to abort the computation, and a higher layer must have *some* way to recover from an aborted computation.
A purposefully simple exception mechanism would do exactly this.

Regards,
Jo
.

Relevant Pages

  • Re: Pattern between cubes
    ... its not pattern that i foll0w always, there are ways i can derive ... we can use suitable identiteis to derive such formulae. ... Total sum of squares. ...
    (sci.math)
  • Re: Total size of specific files
    ... the pattern *.chi? ... But it seems to sum up the total in "bursts" - and I'm not sure if I ... it allows you to give find options to restrict the files counted. ...
    (comp.unix.shell)
  • Re: Series pattern
    ... The early k suggest pattern p*ln+q, but it might not be the ... the sum is equal to ... can't be expressed in terms of radicals. ...
    (sci.math)
  • Re: matmul trouble
    ... It was sum. ... Hmm. ... Perhaps a pattern. ... sounding like compiler instalation issues again.. ...
    (comp.lang.fortran)