On Thu, Oct 25, 2018 at 10:32 AM Andy Balholm <[email protected]> wrote:
>
>
>
> On Oct 25, 2018, at 6:45 AM, Marvin Renich <[email protected]> wrote:
>
> The most powerful feature of the contracts described in the original
> design draft is the ability to describe interactions between two types
> in a type specification. Your proposal doesn't seem to allow this.
>
>
> See the section of my gist about Contracts on Multiple Types.
> The contract G there is exactly equivalent to the one in the design draft.
I find the idea of defining contracts on multiple types as defined in
the proposal confusing and counterintuitive.
As an extension of defining contracts as existing types, you can
define individual types in terms of existing data structures, and
define another structure to define the relationship between them:
contract Node interface(type E Edge) {...}
contract Edge interface(type N Node) {...}
type Graph(type N Node, type E Edge) struct {...}
See the "Mutually referential type parameter..." section in
https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
>
> Also, you seem to be trying to use "familiar" Go constructs for your
> contract body, but you mix types, fields, and operators at the same
> syntactical level. This is bound to be a source of significant
> cognitive load both when writing and reading contracts.
>
>
> I’ve decided to drop operators from my syntax for structural contracts.
> The only one that was really needed was ==, and it would have to be a little
> magic
> in order to allow using the type as a map key as well.
> So now I just have a built-in contract `comparable`.
>
> The only type names that are used in structural contracts are interfaces,
> and they are used in the same way as in an interface that embeds another
> interface.
> So that should limit the cognitive load somewhat.
>
> Andy, if your proposal is just taking the design draft and replacing the
> contract syntax, then I like it, but I believe my syntax is
> significantly better.
>
>
> Yes, that’s my intention.
> I personally like how much my proposal can accomplish with so little new
> syntax.
> (Though it’s actually more new syntax than the design draft…
> but I expect it’s quite a bit easier to read and write.)
>
> Andy
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
