so wise! thanks for those clarification.
I did not deeply understand why it is called an identity func, and why it
has to be this signature.
It seems so narrowed to a specific case, makes me unhappy.
Now, i realized that even if <t>, for some specific cases, seems to solve
some situations,
it won t be enough to implement the kind of things i presented,
function composition (do -> to composition).
My example was tooooo simple.
A better func to think about is *mustNotErr*.
mustNotErr is not implementable using <t>, but lets take a look what he d
be,
func mustNotErr(f func() (<t>, error)) func() (<t>) {}
In plain text, it is a func that takes in parameter a func and returns a
func.
but if you take some realistic example you ll get something like
func W() (X, error){}
func W1(a A, b *B) (Y, X, error){}
And now we can observe that size, positions, and types
of the delayed func IO/parameters are the differences
that are not matched in my previous declaration of mustNotErr.
mustNotErr takes no parameter, returns only 2 parameters
f() (A,B) -> matches W, but not W1.
But, intuitively we feel that W and W1 can be factorized to something like
this,
a func func(
with any input parameters ...
, ) (
returns any parameters, ...
followed, ,
by a traling error error
)
yeah ?
Using that definition, let s see what it might look likes,
mustNotErr := func(f <t:func(...)(..., error)>) *???* {
return func(params ...Parameters) *???* {
...ret, err := f(params...)
if err != nil {
panic(err)
}
return ret...
}
}
Where Parameters{Value,Type}
Where "...,error" ~~ any front parameters until error
Where "...ret, err :=" ~~ any front parameters until error
Where "return ret..." ~~ any values in []Parameters
The problem now is about the type of the returned func,
it is not <t> anymore, because the error return parameter was removed,
on the other hand, as a declarer we dont know enough about f, to return a
complete function,
it literally is func(...)(...)
But func(...)(...) is not a type a receiver can consume....
At that point, some sort of templating is required, indeed,
or what, partial types ? looks bad...
On Thursday, July 20, 2017 at 10:25:30 PM UTC+2, Jesper Louis Andersen
wrote:
>
> On Mon, Jul 17, 2017 at 11:07 AM <mhh...@gmail.com <javascript:>> 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.
