Re: [go-nuts] Re: Interface value terminology

['Axel Wagner' via golang-nuts]

On Mon, Nov 27, 2017 at 3:02 PM, Stefan Nilsson <
trolleriprofess...@gmail.com> wrote:

> Sure, using a type descriptor to implement the dynamic type is an
> implementation detail. but the fact that an interface value consists of a
> concrete value and a dynamic type is part of the spec. I find it
> unfortunate that there is no common agreement on the terminology. That's
> why I'm asking.
>

"concrete" is mentioned once in the spec:

"Variables of interface type also have a distinct dynamic type, which is
the concrete type of the value assigned to the variable at run time"

I don't think this warrants deriving the term "concrete type" as canon (on
the contrary). TBQH, I'm also not quite sure there is that much of an
issue. I've never ran into any real issues, that I noticed.

You asked what terms we are using for several concepts and why. And my
answer is: I use terms like "(static) type", "dynamic type" and "dynamic
value" as they are defined in the spec, because they are defined that way
in the spec.
I use the term "concrete type", when referring to a non-interface type,
because it's a useful concept to talk about and it is how I usually see
that term used.
And I use the term "type descriptor" to refer to the implementation detail
of gc's generated struct describing the type - because it seems very
descriptive (pun intended) :)
Personally, I rarely, if ever, see an inconsistency from this usage with
what everyone else is saying.

If you are observing a disconnect or disagreement, maybe what's needed is
some better documentation/explanation/publication of these terms? Because
they do seem pretty unambiguous, to me.


>
> On Monday, November 27, 2017 at 2:58:21 PM UTC+1, Jan Mercl wrote:
>>
>> On Mon, Nov 27, 2017 at 2:43 PM Stefan Nilsson 
>> wrote:
>>
>> Having a dynamic type does not imply having a/any type descriptor
>> included in the value of an interface variable. That's why it's an
>> implementation detail.
>>
>>
>>
>> --
>>
>> -j
>>
> --
> 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.
>

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

Re: [go-nuts] Re: Interface value terminology

[Jan Mercl]

On Mon, Nov 27, 2017 at 3:18 PM Stefan Nilsson 
wrote:

> I fully understand that this can be implemented in many different ways.
That's not my question. Splitting words about "consists of" and "has a"
doesn't add much to the discussion.

I think the distinction is essential. Consider/compare to:

i := 42

Per specs, the variable consists of 32 or 64 bits representing the number
42 and it also has a type. Static in this case, but that's not important.
The point is that for a value to have an observable type, the value per se
does not need to _include_ the type information. Including it in the value
of an interface variable is fine and everything, but in no way a necessity.
Meaning: implementation detail interesting mostly for the compiler/runtime
people only. Why talk about a type descriptor _value_ when there can be
none?


-- 

-j

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

Re: [go-nuts] Re: Interface value terminology

[Stefan Nilsson]

I fully understand that this can be implemented in many different ways. 
That's not my question. Splitting words about "consists of" and "has a" 
doesn't add much to the discussion.

On Monday, November 27, 2017 at 3:12:31 PM UTC+1, Jan Mercl wrote:
>
> On Mon, Nov 27, 2017 at 3:02 PM Stefan Nilsson  > wrote:
>
> > Sure, using a type descriptor to implement the dynamic type is an 
> implementation detail. but the fact that an interface value consists of a 
> concrete value and a dynamic type is part of the spec. 
>
> The value of an interface variable does not consist of two things. It 
> consists of one thing, the dynamic value and _has_ a dynamic type. The 
> later does not need to by stored in the interface variable value. Storing 
> the type information in the interface variable value is a very reasonable 
> choice, but other approaches are possible, even though it may mean wasting 
> some additional memory elsewhere.
>
> -- 
>
> -j
>

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

Re: [go-nuts] Re: Interface value terminology

[Jan Mercl]

On Mon, Nov 27, 2017 at 3:02 PM Stefan Nilsson 
wrote:

> Sure, using a type descriptor to implement the dynamic type is an
implementation detail. but the fact that an interface value consists of a
concrete value and a dynamic type is part of the spec.

The value of an interface variable does not consist of two things. It
consists of one thing, the dynamic value and _has_ a dynamic type. The
later does not need to by stored in the interface variable value. Storing
the type information in the interface variable value is a very reasonable
choice, but other approaches are possible, even though it may mean wasting
some additional memory elsewhere.

-- 

-j

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

Re: [go-nuts] Re: Interface value terminology

[Stefan Nilsson]

Sure, using a type descriptor to implement the dynamic type is an 
implementation detail. but the fact that an interface value consists of a 
concrete value and a dynamic type is part of the spec. I find it 
unfortunate that there is no common agreement on the terminology. That's 
why I'm asking.

On Monday, November 27, 2017 at 2:58:21 PM UTC+1, Jan Mercl wrote:
>
> On Mon, Nov 27, 2017 at 2:43 PM Stefan Nilsson  > wrote:
>
> Having a dynamic type does not imply having a/any type descriptor included 
> in the value of an interface variable. That's why it's an implementation 
> detail.
>
>
>
> -- 
>
> -j
>

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

Re: [go-nuts] Re: Interface value terminology

['Axel Wagner' via golang-nuts]

On Mon, Nov 27, 2017 at 2:42 PM, Stefan Nilsson <
trolleriprofess...@gmail.com> wrote:

> I see the dynamic type, which is part of every interface variable, as more
> than an implementation detail.
>

Yes. But not the type descriptor. Which is why I tried to emphasize the
difference :)

The dynamic type is a semantic concept, not related to any specific
implementation. Every implementation needs to implement interfaces some way
and that way needs to support the notion of a dynamic type.
The type descriptor, is what I'd call this thing
 (and the
other structs in that file, embedding it): A data structure defined by the
runtime and generated by gc for every type used in the program. It's the
way how gc - this particular implementation of Go - chose to implement the
requirement of dynamic types from the spec.

The fact that interface values have dynamic types and dynamic values is not
an implementation detail, it's required by the spec.
The fact that interface values are represented by a two-pointer struct, one
pointer to the dynamic value and one pointer to a (unique) type descriptor
*is* an implementation detail. A Go implementation might choose to inline a
type-definition, or to use integer-id's instead of singleton-pointers, or
to inline dynamic values, or to not box interfaces at all if it can proof
it unnecessary, or to box *every* value, not just interfaces, or…

(Note, this is still just the nomenclature I use. Just trying to explain
why it's self-consistent and IMO reasonably clear)


> The language spec, which is typically very careful to avoid talking about
> implementation issues, explicitly states that an interface variable has a
> dynamic type:
>
> Variables of interface type also have a distinct *dynamic type*, which is
> the concrete type of the value assigned to the variable at run time (unless
> the value is the predeclared identifier nil, which has no type). The
> dynamic type may vary during execution but values stored in interface
> variables are always assignable
>  to the static type of the
> variable.
>
> The dynamic type is also crucial in the definition of equality, and it's
> the very mechanism used in type assertions and type switches.
>
> Thinking of an interface variable as storing both a concrete value and a
> dynamic type can be really helpful for understanding Go interfaces. First,
> it's correct by definition. Second, trying to apply concepts from different
> languages can lead to fuzzy thinking. In my experience, the Go language
> spec is often to the better teacher. :)
>
> --
> 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.
>

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

Re: [go-nuts] Re: Interface value terminology

[Jan Mercl]

On Mon, Nov 27, 2017 at 2:43 PM Stefan Nilsson 
wrote:

Having a dynamic type does not imply having a/any type descriptor included
in the value of an interface variable. That's why it's an implementation
detail.



-- 

-j

-- 
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] Re: Interface value terminology

[Stefan Nilsson]

I see the dynamic type, which is part of every interface variable, as more 
than an implementation detail. The language spec, which is typically very 
careful to avoid talking about implementation issues, explicitly states 
that an interface variable has a dynamic type:

Variables of interface type also have a distinct *dynamic type*, which is 
the concrete type of the value assigned to the variable at run time (unless 
the value is the predeclared identifier nil, which has no type). The 
dynamic type may vary during execution but values stored in interface 
variables are always assignable  to 
the static type of the variable.

The dynamic type is also crucial in the definition of equality, and it's 
the very mechanism used in type assertions and type switches.

Thinking of an interface variable as storing both a concrete value and a 
dynamic type can be really helpful for understanding Go interfaces. First, 
it's correct by definition. Second, trying to apply concepts from different 
languages can lead to fuzzy thinking. In my experience, the Go language 
spec is often to the better teacher. :)

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