After giving this some more thought, i’ve changed my syntax for complex
relationships between types. Now it looks like this:
contract Node {
Edges() []Edge
}
contract Edge {
Nodes() (from, to Node)
}
func ShortestPath(type N Node, E Edge)(src, dst N) []E
Andy
> On Oct 25, 2018, at 9:41 AM, Burak Serdar <bser...@ieee.org> wrote:
>
> On Thu, Oct 25, 2018 at 10:32 AM Andy Balholm <andybalh...@gmail.com
> <mailto:andybalh...@gmail.com>> wrote:
>>
>>
>>
>> On Oct 25, 2018, at 6:45 AM, Marvin Renich <m...@renich.org
>> <mailto:m...@renich.org>> 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
> <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 golang-nuts+unsubscr...@googlegroups.com
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout
>> <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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
