On Mon, Jul 17, 2017 at 11:07 AM <mhhc...@gmail.com> wrote: > does it make sense to consider a "value type of any type that carries out > its input type" ? >
Yes. This is called a "universal" and is related to the concept of parametrization by J. Reynolds. Your 'do' function is often called 'id' for the obvious reason that it is the identity function. In SKI logic it is the I combinator. If we annotate the type as you would in type theory, you would write something like id : (T : Type) -> T -> T id t x = x to say that the function can be instantiated with any type 'T' you desire. The actual implementation of 'id' takes two parameters. First it takes the desired type and then it takes the parameter and returns it. Writing 'id Int' is a partial invocation. It "plugs in" the T and yields a function of type 'Int -> Int'. Likewise, 'id String' plugs in strings in the position. Interestingly, Reynolds showed that if the function 'id' is to work for *any* type T at the same time, it *must* have the above implementation. No other implementation is valid. This is the concept of parametrization. Even better, the type T can be a type outside of the type system of the programming language! But do note there is no way a function such as 'id' can manipulate the contents in any way. It is allowed to pass a (generic) data value, but it is not allowed to scrutinize said data value at all. The next question is if you can add constraints to the type. In particular, you want access to the stringer interface in order to grab a string representation of the values. That is, you want to allow any type T for which it holds that it is a member of the Stringer interface. exclaim : Show a => a -> String exclaim x = show x ++ "!" The exclaim function is one such function example. It accepts any type 'a' for which the "Show" interface is implemented. Then it prints the value and adds an exclamation mark at the end of the string. It works for any type implementing the "Show interface". The above code works in Idris, or Haskell with minor modifications, so the generality is definitely doable. The price you pay for these types of generalizations tend to be compilation time or slower execution time. It is one of the places where I tend to disagree with the Go authors: I think the added compilation time is worth paying for the added expressive power in the language. I also think you can make compilation of generics really fast, so the added compilation time is somewhat manageable (and only paid if you actually invoke a generic construction). -- 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.
