search

jonsterling / racket-grit

Grit: the kernel around which a PRL forms
Other
3 stars 0 forks source link

Contract blame is unintuitive #32

Open emberian opened 7 years ago

emberian commented 7 years ago

For example, given some signature defining (tp () (SORT)), running (plug (tp)) will give:

> (plug (tp))
. . logical-framework.rkt:230:25: make-plug: contract violation
  expected: free-name?
  given: (plug tp)
  in: the 1st argument of
      (-> free-name? (listof any/c) plug?)
  contract from: (function make-plug)
  blaming: /home/cmr/proj/racket-grit/logical-framework.rkt
   (assuming the contract is correct)
  at: /home/cmr/proj/racket-grit/logical-framework.rkt:251.18

I suspect the blame is the way it is due to some match expander something or another? I'd expect it to blame me, since I'm the one who gave plug nonsense!

jonsterling commented 7 years ago

I am a beginner with contracts, so this doesn't make a lot of sense to me... make-plug didn't violate its own contract, so why is it getting blamed? (make-plug is indeed what lies at logical-framework.rkt:251)

Or am I misreading the blame message? Or is this one of those peculiarities that arises when using the top-level?

@david-christiansen

david-christiansen commented 7 years ago

This confuses me too. I'll ask for an explanation from the real experts. It's not a top-level thing, because the same thing happens in a module.

david-christiansen commented 7 years ago

Though I suppose it's something like this: https://docs.racket-lang.org/guide/contracts-gotchas.html#%28part._contracts-gotcha-nested%29

We should probably move to providing things as contract-out now that the modules are getting more debugged.