Re: [go-nuts] "interface{} says nothing", lets consider it destroys information

[mhhcbon]

here is a solution to what i described in previous.

The result of
func mustNotErr(f func() (, error)) func() () {}
is the transitivity of t -to> func (...) (..., *-*error)

mustNotErr takes in input
a func T with any inputs, and a *traling* error, 
returns in output,
the func T *less* the trailing error.

- Given
func W() (X, error){}
func W1(a A, b *B) (Y, X, error){}
- Want
func MustW() (X){}
func MustW1(a A, b *B) (Y, X){}

Which literally is,
W() (X, error) -> less a trailing error ->MustW() (X)
W1(a A, b *B) (Y, X, error) -> less a trailing error ->MustW1(a A, b *B) 
(Y, X)

Which in can be written such as
W() (X, error) -> func (...) (..., *-error*) ->MustW() (X)
W1(a A, b *B) (Y, X, error) -> func (...) (..., *-error*) ->MustW1(a A, b 
*B) (Y, X)

So the solution might looks like

mustNotErr := func(f ) t->func (...) (..., *-error*) 
{
 return func(params ...Parameters) ... {
...ret, err := f(params...)
if err != nil {
panic(err)
}
return ret...
 }
}


On Friday, July 21, 2017 at 10:32:21 AM UTC+2, mhh...@gmail.com wrote:
>
> 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 , 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 to simple.
>
> A better func to think about is *mustNotErr*.
>
> mustNotErr is not implementable using , but lets take a look what he d 
> be,
>
> func mustNotErr(f func() (, error)) func() () {}
>
> 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 ) *???* {
>  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  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  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 

Re: [go-nuts] "interface{} says nothing", lets consider it destroys information

[Jesper Louis Andersen]

On Mon, Jul 17, 2017 at 11:07 AM  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.

[go-nuts] "interface{} says nothing", lets consider it destroys information

[mhhcbon]

in func do(i interface{}) interface{} (return i), do says nothing because 
"interface{} says nothing", 

from the caller pov, it looses information at the return call, 

var x = "o"
do(x) // <- return lost the track it was a string

if you delegate that func to another func, 
it can t says anything else rather than nothing unless it introduces type 
assertion.
func to(do func(interface{})interface{}) func (interface{}) interface{} { 
return func (i interface{}) interface{} {return do(i)} }

if the observation become "interface{} destroys information", 
does it make sense to consider a "value type of any type that carries out 
its input type" ?
func do(any )  {return any}
do("thing") <- this is explicitly string

Acting the same way as interface, except that little thing about 
destroying/preserving an information.

It can be delegated to func that works on anything, still returns concrete 
types.
func to(do func(**)) func () ** { return func (i )  
{return do(i)} }

to(do)("whatever") // got a string, right ?

One step forward, 
what if  might be able to say "any type with a constraint on that 
interface",
func do(any )  {return any}
do(WhateverStringerCapable{}) <- much like using a regular parameter of 
type Stringer/interface{}, but now the return call reflects the invoke call 
, so its more complete than interface{}/Stringer.

no?

Or maybe there is a reason in destroying that information ?

-- 
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.