Fix up dependent contract syntax #8
Comments
hi +1 on explicit naming. can you give some concrete examples of where object contracts conflict? or say which rules conflict? I know some LALR tricks which might (or might not) help. Paul |
What about using Haskell syntax for this? f :: (Num x) => x -> !(result) -> x > result |
perhaps a better question is: what syntax do you use for each in your papers? |
ie, if it's not obviously conflicting in your papers, then it's a shame to let LR dictate it. |
The problem isn't just disambiguation. It's that the syntax I'd love (and see most often in papers) where we name the argument like @paulmillr I think that syntax would be a bit confusing since in haskell that means to constrain by the typeclass right? Humm...maybe that'd work though. The multi arg would look like:
Or simpler since
But now I think my favorite syntax right now is |
Your "typeclass as var" proposition seems to me as good as haskell example.
I don't think so: consider a function where we pass many similar arguments: f :: (SomeLongClassName s, SomeLongClassName2 t) => (s, s, s, t) -> [t, s, t, s] -> t s s s
# or
f :: (SomeLongClassName as s, SomeLongClassName2 as t) => (s, s, s, t) -> [t, s, t, s] -> t s s s What would this example look like without |
That syntax wouldn't work for dependent types. The point is to name each parameter uniquely. What you have might actually be useful as a kind of "contract variable" but we need something different for uniquely identifying each param. We could combine them:
But if we just want a way to alias long contract names there's already a way since contracts are just values:
Not sure if it's a good idea to introduce special syntax for this. |
This solution is OK then. So, I think the form |
Why overcomplicate simple things? If return from 1st func is a param to the 2nd one, same the params of the 1st one should be. Like so: f :: (Num) -> !(result, params) -> params[0] > result Using named params ( |
Ha! Yeah you're right, that does simplify things a bit. Realized we have a bit of an ambiguity though. A dependent contract: f :: (Num) -> !(res, params) -> params[0] > res Not a dependent contract: MyEven = (x) -> x % 2 is 0
f :: (!MyEven) -> !MyEven
|
I'm not too happy with the syntax we have for dependent contracts right now.
Scope of $1 is not obvious and its a bit to magical. Would love to allow explicit naming:
But this conflicts with object contracts (and I don't think this can be disambiguated). Some other ideas that have been bouncing around:
The text was updated successfully, but these errors were encountered: