Commit Graph

4 Commits

Author SHA1 Message Date
KtorZ efeda9a998
Prevent non-default fallback on exhaustive validator
Technically, we always need a fallback just because the way the UPLC
  is going to work. The last case in the handler pattern matching is
  always going to be else ...

  We could optimize that away and when the validator is exhaustive, make
  the last handler the fallback. Yet, it's really a micro optimization
  that saves us one extra if/else. So the sake of getting things
  working, we always assume that there's a fallback but, with the extra
  condition that when the validator is exhaustive (i.e. there's a
  handler covering all purposes), the fallback HAS TO BE the default
  fallback (i.e. (_) => fail).

  This allows us to gracefully format it out, and also raise an error in
  case where there's an extraneous custom fallback.
2024-08-27 20:16:45 +02:00
KtorZ d74e36d0bc
Introduce 'Never' type as a safe alternative to always None options
Unfortunately, as documented in:

  https://github.com/IntersectMBO/cardano-ledger/issues/4571

  Some Option fields in the script context certificates are going to
  remain set to None, at least until the next Hard fork. There's a risk
  that people permanently lock their funds if they expect deposits on
  registration credentials to ever be `Some`.

  So, we introduce a special type that emulate an `Option` that can only
  ever be `None`. We call it `Never` and it is the first type of this
  kind (i.e. with constructors indexes not starting at 0).
2024-08-27 14:40:39 +02:00
KtorZ 442010d056
Fix generation of fallback validator
This must only happen in case all other validator succeed; otherwise
  we might generate invalid validators.
2024-08-25 16:20:08 +02:00
KtorZ 7ec3f2e8df
DRY builtins types creation to ensure proper consistency. 2024-08-25 16:20:06 +02:00