Re: [go-nuts] Pointer to a pointer

[Brian Candler]

On Tuesday, 15 March 2022 at 15:51:46 UTC Jan Mercl wrote:

> a struct with a single field is another interesting case that can be 
> abstracted out.


Aside: a struct with *no* fields is also more useful than you might think - 
e.g. to use a map as a sparse set.

m := make(map[int]struct{})
m[123] = struct{}{}
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1619071b-4ae7-4ca5-85c3-8573978f5a34n%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

['Thomas Bushnell BSG' via golang-nuts]

Yes indeed! These constructions all give us *expressions *with many
consecutive stars. But they don't give us *types *with that. (and you can't
assign a *Number to a **Number, for example)

On Tue, Mar 15, 2022 at 11:50 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Mar 15, 2022 at 4:41 PM Thomas Bushnell BSG
>  wrote:
>
> > Not in the normal implementation it doesn't. Typically it might be:
> >
> > type element struct {
> >   value int
> >   next *element
> > }
> >
> > next is a pointer to an element, not a pointer to a pointer. That
> element contains within it a pointer, but next is not a pointer to a
> pointer. If it were, it would be declared with two stars.
>
> Although linked lists usually do contain a payload, as you note, I
> consider `type peano *peano` a payload-less linked list. Or a linked
> list with zero sized payload one could also say. And once a node
> contains zero bits of a payload, it contains only the link field. And
> a struct with a single field is another interesting case that can be
> abstracted out. Numbers 0 and 1 make many things much more interesting
> ;-)
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxuzz1tMi2vT0oUmyyE8YA9Q31x054pXf_zY0XHRsLjQsw%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

['Thomas Bushnell BSG' via golang-nuts]

On Thu, Mar 10, 2022 at 4:31 AM Rob Pike  wrote:

> On Thu, Mar 10, 2022 at 5:08 PM shan...@gmail.com 
> wrote:
> >
> > Is this really how you want to be known?
>
> Sure, why not? It's a more interesting program than one might think.
>
> For a richer example of the foundational idea here, see the peano.go
> program in the test directory in the repo.
>

This is lovely. I'm thinking about the relation to other ways of defining
models of numerals.

For example, Church numerals are much more annoying (if logically simpler
in some sense); peano.go offers a trivial predecessor function which is
famously annoying for Church numerals.

Finite Von Neumann ordinals are very similar - we interpret  a Number as a
set of all the things which can be reached from it by applying *, and then
each number is the set of all smaller numerals in the right way. And
infinite chains of pointers map to ordinals exactly as we might want.
However this doesn't encode general sets; by definition it can only define
transitive sets, so it gets you ordinals, but only ordinals and not in the
larger universe.

The name "peano.go" also suggests to me that it's not quite PA that we're
modeling here so much as PA numerals what happens if we are working in
a space where the Numbers might be non-standard? The functions now don't
terminate, but because of Tennenbaum's Theorem, there might be very little
we can do to improve on that.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtXQoPbia9FK-0O5z7xP0McBYCodAaPPXcuSw9REL64aQ%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

[Jan Mercl]

On Tue, Mar 15, 2022 at 4:41 PM Thomas Bushnell BSG
 wrote:

> Not in the normal implementation it doesn't. Typically it might be:
>
> type element struct {
>   value int
>   next *element
> }
>
> next is a pointer to an element, not a pointer to a pointer. That element 
> contains within it a pointer, but next is not a pointer to a pointer. If it 
> were, it would be declared with two stars.

Although linked lists usually do contain a payload, as you note, I
consider `type peano *peano` a payload-less linked list. Or a linked
list with zero sized payload one could also say. And once a node
contains zero bits of a payload, it contains only the link field. And
a struct with a single field is another interesting case that can be
abstracted out. Numbers 0 and 1 make many things much more interesting
;-)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XxedfcZfzOUVJE%3DV5kxn6b6MWqqkDk9mPKCkRce%2BBJYw%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 9, 2022 at 11:38 PM Jan Mercl <0xj...@gmail.com> wrote:

> A linked list, for example, consists of pointers to pointers to pointers...
>

Not in the normal implementation it doesn't. Typically it might be:

type element struct {
  value int
  next *element
}

next is a pointer to an element, not a pointer to a pointer. That element
contains *within it *a pointer, but next is not a pointer to a pointer. If
it were, it would be declared with two stars.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxv%2Bpk-KuxOJ-P%2BeVaDUCO1rj%3DwtXQAB%3DQHAU3twFc9mNQ%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

[Rob Pike]

Actually the one I was referring to is in the main repo at
test/peano.go, but it's the same idea.

-rob

On Tue, Mar 15, 2022 at 10:10 PM Jochen Voss  wrote:
>
> Thanks for the pointer to peano.go, this is fun!
>
> It took me a while to locate the file.  In case others are interested: 
> peano.go is at 
> https://github.com/golang/website/blob/master/_content/doc/play/peano.go and 
> can also be found by choosing "Peano Integers" from the top-right menu in the 
> Go playground.
>
> All the best,
> Jochen
> On Thursday, 10 March 2022 at 09:31:58 UTC Rob 'Commander' Pike wrote:
>>
>> On Thu, Mar 10, 2022 at 5:08 PM shan...@gmail.com  wrote:
>> >
>> > Is this really how you want to be known?
>>
>> Sure, why not? It's a more interesting program than one might think.
>>
>> For a richer example of the foundational idea here, see the peano.go
>> program in the test directory in the repo.
>>
>> -rob
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/efbb4589-ff23-4e57-ae6f-0ab4e82ca1cfn%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOXNBZQj4ZKWfEyh3XfbSXLxqYo6sD%3DxqSp55h7M1u5MnONg6g%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

[Jochen Voss]

Thanks for the pointer to peano.go, this is fun!

It took me a while to locate the file.  In case others are interested: 
peano.go is 
at https://github.com/golang/website/blob/master/_content/doc/play/peano.go 
and can also be found by choosing "Peano Integers" from the top-right menu 
in the Go playground.

All the best,
Jochen
On Thursday, 10 March 2022 at 09:31:58 UTC Rob 'Commander' Pike wrote:

> On Thu, Mar 10, 2022 at 5:08 PM shan...@gmail.com  
> wrote:
> >
> > Is this really how you want to be known?
>
> Sure, why not? It's a more interesting program than one might think.
>
> For a richer example of the foundational idea here, see the peano.go
> program in the test directory in the repo.
>
> -rob
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/efbb4589-ff23-4e57-ae6f-0ab4e82ca1cfn%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Rob Pike]

This topic has come up before. The scope of the identifier is set up
to allow, unlike in C, constructs such as

type stateFunction func() stateFunction

as is used in my talk about a scanner, https://talks.golang.org/2011/lex.slide

As I mentioned above, recursive type definitions appear even in an
early (and very interesting) test.

-rob



On Fri, Mar 11, 2022 at 1:01 AM Manlio Perillo  wrote:
>
> On Thursday, March 10, 2022 at 2:48:27 PM UTC+1 axel.wa...@googlemail.com 
> wrote:
>>
>> On Thu, Mar 10, 2022 at 2:38 PM Manlio Perillo  wrote:
>>>
>>> On Thursday, March 10, 2022 at 2:04:44 PM UTC+1 Jan Mercl wrote:

 On Thu, Mar 10, 2022 at 1:40 PM 'wagner riffel' via golang-nuts 
  wrote:

 > I don't think it's mentioned in the specification, my bet is that
 > unless your type requires inifnity amout of memory (eg: `type t struct
 > {t}`) or the type is an interface and break its rules, (eg: `type
 > iface interface{ iface }`) you can use self-reference.

 The validity of `type T *T` in Go is based on two things: 1) The 
 visibility of the identifier in `type T ...` is specified to start right 
 after the identifier, 2) It's possible, in this case, to compute the size 
 of type T. So no problem here.

>>>
>>> The only reference I found in the spec (after a quick search) is:
>>> 8. The scope of a type identifier declared inside a function begins at 
>>> the identifier in the TypeSpec and ends at the end of the innermost 
>>> containing block.
>>
>>
>> Also:
>>>
>>> The scope of an identifier denoting a constant, type, variable, or function 
>>> (but not method) declared at top level (outside any function) is the 
>>> package block.
>>
>>
>
> But this seems different from "The scope of a type identifier declared inside 
> a function **begins** at the identifier in the ...".
> My interpretation of the text you mentioned is: the identifier is **not** in 
> scope **until** the type definition is complete.
>
> Thanks
> Manlio
>
>>
>>
>>>
>>>
>>> > [...]
>>>
>>> Thanks
>>> Manlio
>>>
>>> --
>>> 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...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/aba04b1a-29a3-4950-8ba8-c4d6a4d9aa3en%40googlegroups.com.
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/43992fed-8c73-444d-aedc-19d549726896n%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOXNBZTid05AnogEeWGbCCRQrxD3AuC4gx0GmfEChLXKBf_G9g%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

[Manlio Perillo]

On Thursday, March 10, 2022 at 2:48:27 PM UTC+1 axel.wa...@googlemail.com 
wrote:

> On Thu, Mar 10, 2022 at 2:38 PM Manlio Perillo  
> wrote:
>
>> On Thursday, March 10, 2022 at 2:04:44 PM UTC+1 Jan Mercl wrote:
>>
>>> On Thu, Mar 10, 2022 at 1:40 PM 'wagner riffel' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
>>> > I don't think it's mentioned in the specification, my bet is that
>>> > unless your type requires inifnity amout of memory (eg: `type t struct
>>> > {t}`) or the type is an interface and break its rules, (eg: `type
>>> > iface interface{ iface }`) you can use self-reference.
>>>
>>> The validity of `type T *T` in Go is based on two things: 1) The 
>>> visibility of the identifier in `type T ...` is specified to start right 
>>> after the identifier, 2) It's possible, in this case, to compute the size 
>>> of type T. So no problem here.
>>>
>>>
>> The only reference I found in the spec (after a quick search) is:
>> 8. The scope of a type identifier declared inside a function begins 
>> at the identifier in the TypeSpec and ends at the end of the innermost 
>> containing block.
>>
>
> Also:
>
>> The scope of an identifier denoting a constant, type, variable, or 
>> function (but not method) declared at top level (outside any function) is 
>> the package block.
>
>
>
But this seems different from "The scope of a type identifier declared 
inside a function **begins** at the identifier in the ...".
My interpretation of the text you mentioned is: the identifier is **not** 
in scope **until** the type definition is complete.

Thanks
Manlio


>  
>
>>
>> > [...]
>>
>> Thanks 
>> Manlio
>>
> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/aba04b1a-29a3-4950-8ba8-c4d6a4d9aa3en%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/43992fed-8c73-444d-aedc-19d549726896n%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Holloway Kean Ho]

HI all, 

> Does anyone know what the upper bound on this could be?

Interesting question. I have a thought experiment theory: "LIMIT_MAX = 
(TOTAL_MEMORY - OTHER_SERVICES - DATA) / MBIT"

Explanation:
1. Assuming you're using 64-bit OS and memory structure is aligned using 
64-bit memory, your MBIT should be `uint64` for each memory address as a 
value.
2. Each level of pointer (e.g. pointer of pointer ) shall only consume 1 
`uint64` memory space.
3. Iterate the thinking recursively and you eventually ran out of memory 
available on a given system.
4. Hence, the upper limit, LIMIT_MAX shall be the remaining free memory 
after subtracting other services consuming the memory space 
(OTHER_SERVICES)  and the initial data size, the value of the first degree 
pointer (DATA).

Note:
1. For 32-bit memory addressing, it's at max 4GB at `uint32` per iteration 
due to the addressing capacity limit, which is why 64-bit CPU is created at 
the first place.


I may be wrong but I'm curious to know. As for how to prove it, I have no 
idea and I don't intend to crash my laptop at the moment. Besides, I never 
use pointer of pointer beyond 3 degree deep. =p

Regards,
Holloway

On Thursday, March 10, 2022 at 2:53:05 PM UTC+8 kortschak wrote:

> On Wed, 2022-03-09 at 18:58 -0800, shan...@gmail.com wrote:
> > This morning someone asked about dereferincing a pointer to a pointer
> > to a pointer
> >
> > At first nobody had ever thought about, let alone knew the answer,
> > but some example code was shown, and sure enough ***val is possible
> > ```
> > package main
> >
> > import "fmt"
> >
> > func main() {
> > a := 0
> > b := 
> > c := 
> > UltimatePointOne()
> > fmt.Println(a)
> > }
> >
> > func UltimatePointOne(n ***int) {
> > ***n = 1
> > }
> > ```
> >
> >
> > On a lark a go playground example was tried to find what the maximum
> > * is in Go
> >
> > https://go.dev/play/p/YhibY3p7TSD
> >
> > There's 28 there, but it's not the limit
> >
> > Does anyone know what the upper bound on this could be?
> >
> > 256 * ?
> >
> > 32k * ?
>
> I think aspects of this thread are sad. None of us know the background
> of the OP and this kind of thinking illustrates a joyful level of
> curiosity that could have been answered in a way that helps the
> questioner and build a positive community (for Shane, Rob did answer it
> and in way that is really quite deep, and thinking about how he
> answered it will teach you something that is worth learning).
>
> Calling a question "silly" demeans the questioner without understanding
> where they are coming from.
>
> Dan
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/50570864-f5f2-4835-b22b-6852bfb49949n%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Manlio Perillo]

On Thursday, March 10, 2022 at 2:04:44 PM UTC+1 Jan Mercl wrote:

> On Thu, Mar 10, 2022 at 1:40 PM 'wagner riffel' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> > I don't think it's mentioned in the specification, my bet is that
> > unless your type requires inifnity amout of memory (eg: `type t struct
> > {t}`) or the type is an interface and break its rules, (eg: `type
> > iface interface{ iface }`) you can use self-reference.
>
> The validity of `type T *T` in Go is based on two things: 1) The 
> visibility of the identifier in `type T ...` is specified to start right 
> after the identifier, 2) It's possible, in this case, to compute the size 
> of type T. So no problem here.
>
>
The only reference I found in the spec (after a quick search) is:
8. The scope of a type identifier declared inside a function begins at 
the identifier in the TypeSpec and ends at the end of the innermost 
containing block.

> [...]

Thanks 
Manlio

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/aba04b1a-29a3-4950-8ba8-c4d6a4d9aa3en%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Jan Mercl]

On Thu, Mar 10, 2022 at 2:18 PM 'Axel Wagner' via golang-nuts
 wrote:

> TBH I find it rather surprising that the spec does not mention why `type X X` 
> is *not* allowed.

The specs guarantee unsafe.Sizeof() to produce the size. I think that
gives a Go compiler the right to reject that type definition.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Vct2AQLZnqAR3mGnwK7tLB9_crz6Nfj%3DkrFYn4OgXk%3DA%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

['Axel Wagner' via golang-nuts]

TBH I find it rather surprising that the spec does not mention why `type X
X` is *not* allowed.
It's obvious that it can't be, but from what I can tell, the spec doesn't
forbid it.
Otherwise I would've chalked up the validity of `type X *X` for "anything
that's not forbidden, is allowed". A type definition
 is

TypeDef = identifier Type .
> Type = TypeName | TypeLit | "(" Type ")" .
> TypeName  = identifier | QualifiedIdent .
> TypeLit   = … | PointerType | … .

PointerType = "*" BaseType .

BaseType= Type .


So `type X *X` is obviously valid (after taking scope into account
, as Jam mentions). But so
would `type X X` be.

On Thu, Mar 10, 2022 at 2:04 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Mar 10, 2022 at 1:40 PM 'wagner riffel' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> > I don't think it's mentioned in the specification, my bet is that
> > unless your type requires inifnity amout of memory (eg: `type t struct
> > {t}`) or the type is an interface and break its rules, (eg: `type
> > iface interface{ iface }`) you can use self-reference.
>
> The validity of `type T *T` in Go is based on two things: 1) The
> visibility of the identifier in `type T ...` is specified to start right
> after the identifier, 2) It's possible, in this case, to compute the size
> of type T. So no problem here.
>
> > You're correct, C doesn't allow self reference in type decl, more ...
>
> In `typedef self *self;` the visibility of the second instance of
> identifier `self` starts only after it, ie. preceding the final `;'. So the
> first identifier `self`, the one after `typedef` is undefined and that's
> the real reason it does not work. However:
>
> 
> jnml@e5-1650:~/tmp$ cat main.c
> typedef int T;
> typedef T T;
>
> int main() {}
> jnml@e5-1650:~/tmp$ gcc -Wall main.c
> jnml@e5-1650:~/tmp$
> 
>
> This works because typedef is equal to Go type aliases. But the full Go
> thing cannot work:
>
> 
> jnml@e5-1650:~/tmp$ cat main.c
> typedef int T;
> typedef T *T;
>
> int main() {}
> jnml@e5-1650:~/tmp$ gcc -Wall main.c
> main.c:2:12: error: conflicting types for ‘T’
> 2 | typedef T *T;
>   |^
> main.c:1:13: note: previous declaration of ‘T’ was here
> 1 | typedef int T;
>   |
> 
>
> Here the problem is that we define T to be two different types, the first
> it's an int and the second is a pointer to int.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-VotEGgVupaJ6S1zRF%3D3hDHDKAz0V5_enaD9EfYfL7t-Q%40mail.gmail.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFDr%2BJ5Z79%2BTY_-Yjj5cNniPWRH7ccyK0vSyaHsBcayKA%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

[Jan Mercl]

On Thu, Mar 10, 2022 at 1:40 PM 'wagner riffel' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I don't think it's mentioned in the specification, my bet is that
> unless your type requires inifnity amout of memory (eg: `type t struct
> {t}`) or the type is an interface and break its rules, (eg: `type
> iface interface{ iface }`) you can use self-reference.

The validity of `type T *T` in Go is based on two things: 1) The visibility
of the identifier in `type T ...` is specified to start right after the
identifier, 2) It's possible, in this case, to compute the size of type T.
So no problem here.

> You're correct, C doesn't allow self reference in type decl, more ...

In `typedef self *self;` the visibility of the second instance of
identifier `self` starts only after it, ie. preceding the final `;'. So the
first identifier `self`, the one after `typedef` is undefined and that's
the real reason it does not work. However:


jnml@e5-1650:~/tmp$ cat main.c
typedef int T;
typedef T T;

int main() {}
jnml@e5-1650:~/tmp$ gcc -Wall main.c
jnml@e5-1650:~/tmp$


This works because typedef is equal to Go type aliases. But the full Go
thing cannot work:


jnml@e5-1650:~/tmp$ cat main.c
typedef int T;
typedef T *T;

int main() {}
jnml@e5-1650:~/tmp$ gcc -Wall main.c
main.c:2:12: error: conflicting types for ‘T’
2 | typedef T *T;
  |^
main.c:1:13: note: previous declaration of ‘T’ was here
1 | typedef int T;
  |


Here the problem is that we define T to be two different types, the first
it's an int and the second is a pointer to int.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VotEGgVupaJ6S1zRF%3D3hDHDKAz0V5_enaD9EfYfL7t-Q%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

['wagner riffel' via golang-nuts]

On Thu Mar 10, 2022 at 12:41 PM CET, Manlio Perillo wrote:
> Interesting example, thanks.
>
> But how does `type self *self` works?  If I remember correctly, it is not
> discussed in the Language Specification and in The Go Programming Language
> book.
>

I don't think it's mentioned in the specification, my bet is that
unless your type requires inifnity amout of memory (eg: `type t struct
{t}`) or the type is an interface and break its rules, (eg: `type
iface interface{ iface }`) you can use self-reference.

> By the way, in C `typedef self *self` is invalid (assuming my code is
> written correctly).

You're correct, C doesn't allow self reference in type decl, more
interesting types beside pointers:
  `type fn func() fn`
  `type s []s`
  `type ch chan ch`
  `type m map[*m]m`

-w

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CIG6Z0BDF5P1.1O1MIIQNEHEZY%40pampas.

Re: [go-nuts] Pointer to a pointer

[Manlio Perillo]

Interesting example, thanks.

But how does `type self *self` works?  If I remember correctly, it is not 
discussed in the Language Specification and in The Go Programming Language 
book.

By the way, in C `typedef self *self` is invalid (assuming my code is 
written correctly).

Manlio

On Thursday, March 10, 2022 at 6:44:52 AM UTC+1 Rob 'Commander' Pike wrote:

> Here's a program with 1000 *s. You can see the pattern, make it any
> number you like.
>
> https://go.dev/play/p/FZXWcQTutEG
>
> // You can edit this code!
> // Click here and start typing.
> package main
>
> import "fmt"
>
> type self *self
>
> func main() {
> var p self
> p = 
>
> fmt.Println(p)
> }
>
>
> -rob
>
> On Thu, Mar 10, 2022 at 4:29 PM Kurtis Rader  wrote:
> >
> > On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
> >>
> >> Um
> >>
> >> Really?
> >>
> >> Which of these things are you specifically trying to prevent happening
> >> - Curiousity
> >> - Creativity
> >> - Asking questions
> >> - Some combination of the above
> >>
> >> I mean, I appreciate that you think that people should *know* whatever 
> it is you think you know, but that's a really *really* poor response
> >
> >
> > Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
> >
> >>
> >> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
> >>>
> >>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
> 
>  A linked list, for example, consists of pointers to pointers to 
> pointers...
> 
>  Why should any limit exist to the length of the list except resources 
> available?
> >>>
> >>>
> >>> Yes, but the O.P. was asking about a silly example. Specifically, when 
> defining a function that receives pointers how many levels of indirection 
> are allowed in the declaration. In practice 99.9% of the time a single 
> level of indirection is specified and 0.09% of the time two levels are 
> specified. Etcetera. For example, if
> >>>
> >>> func wtf(i int) {
> >>> }
> >>>
> >>> is supported, which has eight levels of indirection, why isn't 16? 32? 
> 64? Etcetera levels of indirection supported when defining a function. It's 
> a silly question that shows the O.P. doesn't understand how compilers work. 
> Let alone how people use languages like Go in real life.
> >>>
> 
>  On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
> wrote:
> >
> > This morning someone asked about dereferincing a pointer to a 
> pointer to a pointer
> >
> > At first nobody had ever thought about, let alone knew the answer, 
> but some example code was shown, and sure enough ***val is possible
> > ```
> > package main
> >
> > import "fmt"
> >
> > func main() {
> > a := 0
> > b := 
> > c := 
> > UltimatePointOne()
> > fmt.Println(a)
> > }
> >
> > func UltimatePointOne(n ***int) {
> > ***n = 1
> > }
> > ```
> >
> >
> > On a lark a go playground example was tried to find what the maximum 
> * is in Go
> >
> > https://go.dev/play/p/YhibY3p7TSD
> >
> > There's 28 there, but it's not the limit
> >
> > Does anyone know what the upper bound on this could be?
> >
> > 256 * ?
> >
> > 32k * ?
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop 

Re: [go-nuts] Pointer to a pointer

[shan...@gmail.com]

Apologies; I had misunderstood your code and was thinking that - because of 
earlier responses - this wasn't going to be a nice day.

> for Shane, Rob did answer it and in way that is really quite deep, and 
thinking about how he answered it will teach you something that is worth 
learning)

Yeah it's definitely above my paygrade and will take some time for me to 
get my head around
On Thursday, March 10, 2022 at 8:31:58 PM UTC+11 Rob 'Commander' Pike wrote:

> On Thu, Mar 10, 2022 at 5:08 PM shan...@gmail.com  
> wrote:
> >
> > Is this really how you want to be known?
>
> Sure, why not? It's a more interesting program than one might think.
>
> For a richer example of the foundational idea here, see the peano.go
> program in the test directory in the repo.
>
> -rob
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fd44a6d2-4764-4d90-9637-2808683fcedfn%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Rob Pike]

On Thu, Mar 10, 2022 at 5:08 PM shan...@gmail.com  wrote:
>
> Is this really how you want to be known?

Sure, why not? It's a more interesting program than one might think.

For a richer example of the foundational idea here, see the peano.go
program in the test directory in the repo.

-rob

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOXNBZQpnc%3DCQDYM9Vgk-bPU%2BaevXG4SA15OEGmMtC1b1tXDLg%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

['Dan Kortschak' via golang-nuts]

On Wed, 2022-03-09 at 18:58 -0800, shan...@gmail.com wrote:
> This morning someone asked about dereferincing a pointer to a pointer
> to a pointer
>
> At first nobody had ever thought about, let alone knew the answer,
> but some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum
> * is in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?

I think aspects of this thread are sad. None of us know the background
of the OP and this kind of thinking illustrates a joyful level of
curiosity that could have been answered in a way that helps the
questioner and build a positive community (for Shane, Rob did answer it
and in way that is really quite deep, and thinking about how he
answered it will teach you something that is worth learning).

Calling a question "silly" demeans the questioner without understanding
where they are coming from.

Dan


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2ca392b4dd00815102200177bde7186d11e8e9ba.camel%40kortschak.io.

Re: [go-nuts] Pointer to a pointer

[peterGo]

Kurtis Rader,

Stop it. When you are in a hole, stop digging.

When you don't understand a question or topic, don't launch ad hominem 
attacks, calling people's questions silly. That's nasty and it's against 
the Go Code of Conduct.

Like Jan, Rob, and Volker, I found it to be an interesting question, worthy 
of an answer. I wrote a program and looked at the executable code. Are we 
silly too?

Peter

On Thursday, March 10, 2022 at 12:29:54 AM UTC-5 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
>
>> Um
>>
>> Really?
>>
>> Which of these things are you specifically trying to prevent happening
>>  - Curiousity
>>  - Creativity
>>  - Asking questions
>>  - Some combination of the above
>>
>> I mean, I appreciate that you think that people should *know* whatever it 
>> is you think you know, but that's a really *really* poor response
>>
>
> Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
>  
>
>> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>>
>>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>>>
 A linked list, for example, consists of pointers to pointers to 
 pointers...

 Why should any limit exist to the length of the list except resources 
 available?

>>>
>>> Yes, but the O.P. was asking about a silly example. Specifically, when 
>>> defining a function that receives pointers how many levels of indirection 
>>> are allowed in the declaration. In practice 99.9% of the time a single 
>>> level of indirection is specified and 0.09% of the time two levels are 
>>> specified. Etcetera.  For example, if
>>>
>>> func wtf(i int) {
>>> }
>>>
>>> is supported, which has eight levels of indirection, why isn't 16? 32? 
>>> 64? Etcetera levels of indirection supported when defining a function. It's 
>>> a silly question that shows the O.P. doesn't understand how compilers work. 
>>> Let alone how people use languages like Go in real life.
>>>  
>>>
 On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
 wrote:

> This morning someone asked about dereferincing a pointer to a pointer 
> to a pointer
>
> At first nobody had ever thought about, let alone knew the answer, but 
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * 
> is in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
>  
> 
> .
>
 -- 
 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...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
  
 
 .

>>>
>>>
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>> -- 
>> 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...@googlegroups.com.
>>
> 

Re: [go-nuts] Pointer to a pointer

[shan...@gmail.com]

Is this really how you want to be known?


On Thursday, March 10, 2022 at 4:44:52 PM UTC+11 Rob 'Commander' Pike wrote:

> Here's a program with 1000 *s. You can see the pattern, make it any
> number you like.
>
> https://go.dev/play/p/FZXWcQTutEG
>
> // You can edit this code!
> // Click here and start typing.
> package main
>
> import "fmt"
>
> type self *self
>
> func main() {
> var p self
> p = 
>
> fmt.Println(p)
> }
>
>
> -rob
>
> On Thu, Mar 10, 2022 at 4:29 PM Kurtis Rader  wrote:
> >
> > On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
> >>
> >> Um
> >>
> >> Really?
> >>
> >> Which of these things are you specifically trying to prevent happening
> >> - Curiousity
> >> - Creativity
> >> - Asking questions
> >> - Some combination of the above
> >>
> >> I mean, I appreciate that you think that people should *know* whatever 
> it is you think you know, but that's a really *really* poor response
> >
> >
> > Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
> >
> >>
> >> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
> >>>
> >>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
> 
>  A linked list, for example, consists of pointers to pointers to 
> pointers...
> 
>  Why should any limit exist to the length of the list except resources 
> available?
> >>>
> >>>
> >>> Yes, but the O.P. was asking about a silly example. Specifically, when 
> defining a function that receives pointers how many levels of indirection 
> are allowed in the declaration. In practice 99.9% of the time a single 
> level of indirection is specified and 0.09% of the time two levels are 
> specified. Etcetera. For example, if
> >>>
> >>> func wtf(i int) {
> >>> }
> >>>
> >>> is supported, which has eight levels of indirection, why isn't 16? 32? 
> 64? Etcetera levels of indirection supported when defining a function. It's 
> a silly question that shows the O.P. doesn't understand how compilers work. 
> Let alone how people use languages like Go in real life.
> >>>
> 
>  On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
> wrote:
> >
> > This morning someone asked about dereferincing a pointer to a 
> pointer to a pointer
> >
> > At first nobody had ever thought about, let alone knew the answer, 
> but some example code was shown, and sure enough ***val is possible
> > ```
> > package main
> >
> > import "fmt"
> >
> > func main() {
> > a := 0
> > b := 
> > c := 
> > UltimatePointOne()
> > fmt.Println(a)
> > }
> >
> > func UltimatePointOne(n ***int) {
> > ***n = 1
> > }
> > ```
> >
> >
> > On a lark a go playground example was tried to find what the maximum 
> * is in Go
> >
> > https://go.dev/play/p/YhibY3p7TSD
> >
> > There's 28 there, but it's not the limit
> >
> > Does anyone know what the upper bound on this could be?
> >
> > 256 * ?
> >
> > 32k * ?
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
> .
> 
>  

Re: [go-nuts] Pointer to a pointer

[shan...@gmail.com]

> The limit is going to be both platform dependent and dependent on the 
resources (e.g., memory) available on the platform. 

Then this is the answer you should have started with

> absolutely no one will ever write a function that gets within many orders 
of magnitude of the limit

I mean, nobody will ever go to the stars, so nobody should ask what it 
would take to get their, right

That's really bad. That's attacking "creativity" and "curiousity" both at 
the same time

> So your question is interesting in a hypothetical sense 

This is also "curiousity" - learn to recognise it so you don't stifle it in 
future.



On Thursday, March 10, 2022 at 4:29:54 PM UTC+11 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
>
>> Um
>>
>> Really?
>>
>> Which of these things are you specifically trying to prevent happening
>>  - Curiousity
>>  - Creativity
>>  - Asking questions
>>  - Some combination of the above
>>
>> I mean, I appreciate that you think that people should *know* whatever it 
>> is you think you know, but that's a really *really* poor response
>>
>
> Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
>  
>
>> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>>
>>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>>>
 A linked list, for example, consists of pointers to pointers to 
 pointers...

 Why should any limit exist to the length of the list except resources 
 available?

>>>
>>> Yes, but the O.P. was asking about a silly example. Specifically, when 
>>> defining a function that receives pointers how many levels of indirection 
>>> are allowed in the declaration. In practice 99.9% of the time a single 
>>> level of indirection is specified and 0.09% of the time two levels are 
>>> specified. Etcetera.  For example, if
>>>
>>> func wtf(i int) {
>>> }
>>>
>>> is supported, which has eight levels of indirection, why isn't 16? 32? 
>>> 64? Etcetera levels of indirection supported when defining a function. It's 
>>> a silly question that shows the O.P. doesn't understand how compilers work. 
>>> Let alone how people use languages like Go in real life.
>>>  
>>>
 On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
 wrote:

> This morning someone asked about dereferincing a pointer to a pointer 
> to a pointer
>
> At first nobody had ever thought about, let alone knew the answer, but 
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * 
> is in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
>  
> 
> .
>
 -- 
 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...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
  
 
 .

>>>
>>>
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>> -- 
>> You 

Re: [go-nuts] Pointer to a pointer

[Rob Pike]

Here's a program with 1000 *s. You can see the pattern, make it any
number you like.

https://go.dev/play/p/FZXWcQTutEG

// You can edit this code!
// Click here and start typing.
package main

import "fmt"

type self *self

func main() {
var p self
p = 
fmt.Println(p)
}


-rob

On Thu, Mar 10, 2022 at 4:29 PM Kurtis Rader  wrote:
>
> On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  wrote:
>>
>> Um
>>
>> Really?
>>
>> Which of these things are you specifically trying to prevent happening
>>  - Curiousity
>>  - Creativity
>>  - Asking questions
>>  - Some combination of the above
>>
>> I mean, I appreciate that you think that people should *know* whatever it is 
>> you think you know, but that's a really *really* poor response
>
>
> Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental limits 
> imposed by the Go language or the platform it runs on absolutely no one will 
> ever write a function that gets within many orders of magnitude of the limit. 
> So your question is interesting in a hypothetical sense but not in a 
> practical sense. For the former I suggest you start a research project and 
> write a paper for review that explains why, or why not, the existing limit is 
> a problem.
>
>>
>> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>>>
>>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:

 A linked list, for example, consists of pointers to pointers to pointers...

 Why should any limit exist to the length of the list except resources 
 available?
>>>
>>>
>>> Yes, but the O.P. was asking about a silly example. Specifically, when 
>>> defining a function that receives pointers how many levels of indirection 
>>> are allowed in the declaration. In practice 99.9% of the time a single 
>>> level of indirection is specified and 0.09% of the time two levels are 
>>> specified. Etcetera.  For example, if
>>>
>>> func wtf(i int) {
>>> }
>>>
>>> is supported, which has eight levels of indirection, why isn't 16? 32? 64? 
>>> Etcetera levels of indirection supported when defining a function. It's a 
>>> silly question that shows the O.P. doesn't understand how compilers work. 
>>> Let alone how people use languages like Go in real life.
>>>

 On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>
> This morning someone asked about dereferincing a pointer to a pointer to 
> a pointer
>
> At first nobody had ever thought about, let alone knew the answer, but 
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * is 
> in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com.

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

Re: [go-nuts] Pointer to a pointer

[Kurtis Rader]

On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com 
wrote:

> Um
>
> Really?
>
> Which of these things are you specifically trying to prevent happening
>  - Curiousity
>  - Creativity
>  - Asking questions
>  - Some combination of the above
>
> I mean, I appreciate that you think that people should *know* whatever it
> is you think you know, but that's a really *really* poor response
>

Yes, your question was silly. The limit is going to be both platform
dependent and dependent on the resources (e.g., memory) available on the
platform. Your question is silly because regardless of the fundamental
limits imposed by the Go language or the platform it runs on absolutely no
one will ever write a function that gets within many orders of magnitude of
the limit. So your question is interesting in a hypothetical sense but not
in a practical sense. For the former I suggest you start a research project
and write a paper for review that explains why, or why not, the existing
limit is a problem.


> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>
>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>>
>>> A linked list, for example, consists of pointers to pointers to
>>> pointers...
>>>
>>> Why should any limit exist to the length of the list except resources
>>> available?
>>>
>>
>> Yes, but the O.P. was asking about a silly example. Specifically, when
>> defining a function that receives pointers how many levels of indirection
>> are allowed in the declaration. In practice 99.9% of the time a single
>> level of indirection is specified and 0.09% of the time two levels are
>> specified. Etcetera.  For example, if
>>
>> func wtf(i int) {
>> }
>>
>> is supported, which has eight levels of indirection, why isn't 16? 32?
>> 64? Etcetera levels of indirection supported when defining a function. It's
>> a silly question that shows the O.P. doesn't understand how compilers work.
>> Let alone how people use languages like Go in real life.
>>
>>
>>> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>>>
 This morning someone asked about dereferincing a pointer to a pointer
 to a pointer

 At first nobody had ever thought about, let alone knew the answer, but
 some example code was shown, and sure enough ***val is possible
 ```
 package main

 import "fmt"

 func main() {
 a := 0
 b := 
 c := 
 UltimatePointOne()
 fmt.Println(a)
 }

 func UltimatePointOne(n ***int) {
 ***n = 1
 }
 ```


 On a lark a go playground example was tried to find what the maximum *
 is in Go

 https://go.dev/play/p/YhibY3p7TSD

 There's 28 there, but it's not the limit

 Does anyone know what the upper bound on this could be?

 256 * ?

 32k * ?

 --
 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...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
 
 .

>>> --
>>> 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...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/974ff13d-59ff-41f5-90a2-9a3ccd08f10dn%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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.
To view this discussion on the web visit 

Re: [go-nuts] Pointer to a pointer

[shan...@gmail.com]

Um

Really?

Which of these things are you specifically trying to prevent happening
 - Curiousity
 - Creativity
 - Asking questions
 - Some combination of the above


I mean, I appreciate that you think that people should *know* whatever it 
is you think you know, but that's a really *really* poor response

On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> A linked list, for example, consists of pointers to pointers to 
>> pointers...
>>
>> Why should any limit exist to the length of the list except resources 
>> available?
>>
>
> Yes, but the O.P. was asking about a silly example. Specifically, when 
> defining a function that receives pointers how many levels of indirection 
> are allowed in the declaration. In practice 99.9% of the time a single 
> level of indirection is specified and 0.09% of the time two levels are 
> specified. Etcetera.  For example, if
>
> func wtf(i int) {
> }
>
> is supported, which has eight levels of indirection, why isn't 16? 32? 64? 
> Etcetera levels of indirection supported when defining a function. It's a 
> silly question that shows the O.P. doesn't understand how compilers work. 
> Let alone how people use languages like Go in real life.
>  
>
>> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>>
>>> This morning someone asked about dereferincing a pointer to a pointer to 
>>> a pointer
>>>
>>> At first nobody had ever thought about, let alone knew the answer, but 
>>> some example code was shown, and sure enough ***val is possible
>>> ```
>>> package main
>>>
>>> import "fmt"
>>>
>>> func main() {
>>> a := 0
>>> b := 
>>> c := 
>>> UltimatePointOne()
>>> fmt.Println(a)
>>> }
>>>
>>> func UltimatePointOne(n ***int) {
>>> ***n = 1
>>> }
>>> ```
>>>
>>>
>>> On a lark a go playground example was tried to find what the maximum * 
>>> is in Go
>>>
>>> https://go.dev/play/p/YhibY3p7TSD
>>>
>>> There's 28 there, but it's not the limit
>>>
>>> Does anyone know what the upper bound on this could be?
>>>
>>> 256 * ?
>>>
>>> 32k * ?
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/974ff13d-59ff-41f5-90a2-9a3ccd08f10dn%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Kurtis Rader]

On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:

> A linked list, for example, consists of pointers to pointers to pointers...
>
> Why should any limit exist to the length of the list except resources
> available?
>

Yes, but the O.P. was asking about a silly example. Specifically, when
defining a function that receives pointers how many levels of indirection
are allowed in the declaration. In practice 99.9% of the time a single
level of indirection is specified and 0.09% of the time two levels are
specified. Etcetera.  For example, if

func wtf(i int) {
}

is supported, which has eight levels of indirection, why isn't 16? 32? 64?
Etcetera levels of indirection supported when defining a function. It's a
silly question that shows the O.P. doesn't understand how compilers work.
Let alone how people use languages like Go in real life.


> On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:
>
>> This morning someone asked about dereferincing a pointer to a pointer to
>> a pointer
>>
>> At first nobody had ever thought about, let alone knew the answer, but
>> some example code was shown, and sure enough ***val is possible
>> ```
>> package main
>>
>> import "fmt"
>>
>> func main() {
>> a := 0
>> b := 
>> c := 
>> UltimatePointOne()
>> fmt.Println(a)
>> }
>>
>> func UltimatePointOne(n ***int) {
>> ***n = 1
>> }
>> ```
>>
>>
>> On a lark a go playground example was tried to find what the maximum * is
>> in Go
>>
>> https://go.dev/play/p/YhibY3p7TSD
>>
>> There's 28 there, but it's not the limit
>>
>> Does anyone know what the upper bound on this could be?
>>
>> 256 * ?
>>
>> 32k * ?
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
>> 
>> .
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_FqZwvpTHSMu_719NN0wuJcxXZLLWb_s9j1b9mUe66sg%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

[Jan Mercl]

A linked list, for example, consists of pointers to pointers to pointers...

Why should any limit exist to the length of the list except resources
available?

On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  wrote:

> This morning someone asked about dereferincing a pointer to a pointer to a
> pointer
>
> At first nobody had ever thought about, let alone knew the answer, but
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * is
> in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.com.