Scenarios

[fgmccabe]

I have refactored the scenarios into a series of smaller files to make them more digestible. Also, the directory.md example is kind of interesting...

[fgmccabe]

Respectfully demur. The option type is a special case of algebraic type; as is the either type. So, do we wish to honor that or do we make a bunch of special cases? The problem with special cases is that there are so many of them ... including those not yet invented. In addition, there are enough examples of APIs that are quite polymorphic in nature, and having separate imports for them is a hack necessary for C programming but should not necessarily be reflected in the 'interface'. Some examples: settimeout (string or callback function argument), define_property, canvas get_context, bufferData, etc. In addition, I do not understand your comment about modularity.

On Tue, Oct 15, 2019 at 9:27 AM Andreas Rossberg notifications@github.com wrote:

@rossberg commented on this pull request.

In proposals/interface-types/working-notes/record.md https://github.com/WebAssembly/interface-types/pull/76#discussion_r335055258 :

@@ -0,0 +1,73 @@ + + +### Records + +Records are collections of named and typed fields. Records can be defined in as +Interface Types; for example this definition encodes a familiar notion of a +credit card: + +```wat +(@interface datatype @cc

@fgmccabe https://github.com/fgmccabe, the only reason to distinguish them would be if you wanted nominal typing for algebraic types. But there is little reason to want that in Wasm interfaces. In fact, there is good reason not to want that because it makes everything more complicated and aversely affects modularity.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/WebAssembly/interface-types/pull/76?email_source=notifications&email_token=AAQAXUBGIHHWGFRLDYELH5LQOXVPTA5CNFSM4I7POCDKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCIAMNUQ#discussion_r335055258, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQAXUFOFYJ2NSSQ5INIY2LQOXVPTANCNFSM4I7POCDA .

-- Francis McCabe SWE

[rossberg]

@fgmccabe:

The option type is a special case of algebraic type; as is the either type. So, do we wish to honor that or do we make a bunch of special cases? The problem with special cases is that there are so many of them ... including those not yet invented. In addition, there are enough examples of APIs that are quite polymorphic in nature, and having separate imports for them is a hack necessary for C programming but should not necessarily be reflected in the 'interface'. Some examples: settimeout (string or callback function argument), define_property, canvas get_context, bufferData, etc.

Not sure if this is a reply to my comment? I definitely agree that you want variant types. I was merely saying that there is no reason to make them nominal, and thereofore, no reason to distinguish type from datatype definitions. You can interpret definitions of algebraic data types as aliases for structural variant/sum types just fine, and it's actually much easier to do so in the context of interfaces.

In addition, I do not understand your comment about modularity.

Fair enough. I could go into a long explanation about how nominal types don't work at interface boundaries, esp with the strong kind of modularity provided by Wasm modules (which has no notion of referring to types from other modules). But that may be a bit off-topic.

[fgmccabe]

The case for nominal types in the interface layer has nothing to do with wasm core types. Put simply, for APIs it is important that a person is never misunderstood as a chair or a port.

On Tue, Oct 15, 2019 at 11:03 PM Andreas Rossberg notifications@github.com wrote:

@fgmccabe https://github.com/fgmccabe:

The option type is a special case of algebraic type; as is the either type. So, do we wish to honor that or do we make a bunch of special cases? The problem with special cases is that there are so many of them ... including those not yet invented. In addition, there are enough examples of APIs that are quite polymorphic in nature, and having separate imports for them is a hack necessary for C programming but should not necessarily be reflected in the 'interface'. Some examples: settimeout (string or callback function argument), define_property, canvas get_context, bufferData, etc.

Not sure if this is a reply to my comment? I definitely agree that you want variant types. I was merely saying that there is no reason to make them nominal, and thereofore, no reason to distinguish type from datatype definitions. You can interpret definitions of algebraic data types as aliases for structural variant/sum types just fine, and it's actually much easier to do so in the context of interfaces.

In addition, I do not understand your comment about modularity.

Fair enough. I could go into a long explanation about how nominal types don't work at interface boundaries, esp with the strong kind of modularity provided by Wasm modules (which has no notion of referring to types from other modules). But that may be a bit off-topic.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/WebAssembly/interface-types/pull/76?email_source=notifications&email_token=AAQAXUD7DYMF3H25GQXAMA3QO2VEJA5CNFSM4I7POCDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLGRLQ#issuecomment-542533806, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQAXUBJATPKL34QBD57P5TQO2VEJANCNFSM4I7POCDA .

-- Francis McCabe SWE

[rossberg]

@fgmccabe:

The case for nominal types in the interface layer has nothing to do with wasm core types.

Neither has my argument. ;) They simply won't work in interfaces for a Wasm-like module system. How would you use a nominal datatype from another module?

Put simply, for APIs it is important that a person is never misunderstood as a chair or a port.

Confusing two structurally equivalent algebraic types is no different from confusing an int denoting a length with an int denoting an index. And that latter confusion is waaaay more likely to happen in practice. Yet, APIs don't tend to define nominal integer types.

[fgmccabe]

The case for algebraic data types is a bit different: if you have variant types you need to be able to signal which variant you actually have. This is data dependent; it seems to me.

On Wed, Oct 16, 2019 at 12:05 AM Andreas Rossberg notifications@github.com wrote:

@fgmccabe https://github.com/fgmccabe:

The case for nominal types in the interface layer has nothing to do with wasm core types.

Neither has my argument. ;) They simply won't work in interfaces for a Wasm-like module system. How would you use a nominal datatype from another module?

Put simply, for APIs it is important that a person is never misunderstood as a chair or a port.

Confusing two structurally equivalent algebraic types is no different from confusing an int denoting a length with an int denoting an index. And that latter confusion is waaaay more likely to happen in practice. Yet, APIs don't tend to define nominal integer types.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/WebAssembly/interface-types/pull/76?email_source=notifications&email_token=AAQAXUBC72RLFAGQ5XDQ6ZDQO24MVA5CNFSM4I7POCDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLLXZI#issuecomment-542555109, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQAXUC5J2ZV3GAGLLUNEDDQO24MVANCNFSM4I7POCDA .

-- Francis McCabe SWE

[rossberg]

@fgmccabe:

if you have variant types you need to be able to signal which variant you actually have.

Sure, but that is independent from making the type nominal (i.e., not an alias). Variant tags can be treated just as structurally as record labels (in fact, they are the exact dual). They can both be identified purely by syntactic name -- or in Wasm, rather by index. Knowing the structure of the assumed type is enough to interpret the label/index. Really no different from integers ()which are really just a shorthand for peano numbers, so datatypes :)).