Small, but important, correction re #5:
5. Any contract could contain at most one 'union' or 'except' assertion *for
each type parameter*.
Alan
On Monday, September 17, 2018 at 11:07:26 AM UTC+1, alan...@gmail.com wrote:
>
> Jonathan,
>
> The problem with just 'OR'ing complex64 and complex128 together is that
> the resulting contract wouldn't encompass any defined types with the same
> underlying types. So 'mycomplex' wouldn't be included:
>
> type mycomplex complex64
>
> However, I'm pleased you mentioned it as it's given me an idea. Maybe my
> 'fuller' proposal was on the right lines after all, it just needed
> simplifying :)
>
> Suppose (with the sole exception of Comparable) we get rid of the
> built-ins altogether and instead add two new assertions to the four that
> are already permitted within a contract body:
>
> union{...}(T)
> except{...}(T)
>
> These would assert that a type parameter must represent a type within the
> 'union' body but NOT represent a type within the 'except' body. The
> following could go within the body:
>
> 1. Any non-generic type.
>
> 2. Any contract requiring exactly one type parameter (inferred to be T).
>
> Other rules would be:
>
> 3. There could be any number of constituent types/contracts with a minimum
> of one.
>
> 4. Any type specified under #1 would be deemed to include any defined type
> with the same underlying type (IMPORTANT POINT!).
>
> 5. Any contract could contain at most one 'union' or 'except' assertion.
>
> 6. 'union' and 'except' would only be keywords within this context. Other
> uses would be unaffected and so the proposal would still be backwards
> compatible with Go 1.
>
> Incidentally, I'm NOT suggesting that we should add union types to the
> language itself; these constructs would only apply within a contract body.
>
> It would now be a simple matter to build up a standard contracts package
> ("ct" say) which included those originally envisaged: Integer, Signed,
> Unsigned, Float, Complex, Boolean, String, Real, Numeric, Ordered, Addable,
> Bytes and Runes. For example:
>
> contract Signed(T) {
> union{ int8, int16, int32, int64, int }(T)
> }
>
> contract Unsigned(T) {
> union{ uint8, uint16, uint32, uint64, uint, uintptr }(T)
> }
>
> contract Float(T) {
> union{ float32, float64 }(T)
> }
>
> contract Complex(T) {
> union{ complex64, complex128 }(T)
> }
>
> contract Integer(T) {
> union{ ct.Signed, ct.Unsigned }(T)
> }
>
> contract Numeric(T) {
> union{ ct.Integer, ct.Float, ct.Complex }(T)
> }
>
> contract String(T) {
> union{ string }(T) // includes any defined type based on string
> }
>
> contract Bytes(T) {
> union{ string, []byte }(T) // includes defined types based on string
> or []byte
> }
>
> The Add1K example could now by made to work properly with this contract
> which disallows 8 bit integers:
>
> contract BiggerInts(T) {
> ct.Integer(T)
> except{ int8, uint8 }(T)
> }
>
> Incidentally, any one who dislikes having to qualify stuff with "ct" could
> get rid of it in the 'import' declaration as long as they were confident
> they wouldn't reuse the names of the standard contracts in the current
> source file:
>
> import . "ct"
>
> So what do you think of this idea?
>
> It's certainly more expressive than the simplified proposal as it stands
> and (apart from stuff like a totally generic Min() function which would
> require contract adaptors) I'm struggling to think of anything it couldn't
> do that I'd want it to do.
>
> Alan
>
> On Sunday, September 16, 2018 at 11:22:35 PM UTC+1, Jonathan Amsterdam
> wrote:
>>
>>
>>
>> On Friday, September 14, 2018 at 8:06:31 PM UTC-4, alanfo wrote:
>>>
>>> Thanks for your comments, Jonathan.
>>>
>>> I did in fact deal with all the cases you mention in my 'fuller'
>>> proposal:
>>>
>>> https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
>>>
>>> where I'd used a device to restrict the built-ins to just one following
>>> criticism by Ian that an earlier proposal I'd made had too many of them (it
>>> had 14).
>>>
>>> However, I decided instead to restrict the built-ins to a reasonable
>>> number (6) in the simplified proposal which meant that many of them had to
>>> go.
>>>
>>
>> Your 'fuller' proposal says that you can "or" the builtins together. But
>> if you have that, you can get rid of many of them. For instance, "complex"
>> is just "complex64 or complex128".
>>
>>>
>>> The example you mentioned was taken from the draft design paper and
>>> didn't compile for int8 there either.
>>>
>>
>> Sorry, I shouldn't have used the word "compile" because it's ambiguous.
>> Neither your Add1K nor the draft design's can be instantiated for int8.
>> However, the draft design Add1K is valid with respect to its contract.
>> Yours isn't, because the contract admits int8 but the function doesn't.
>>
>
--
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.
