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{}
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 Thoma
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 p
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 poin
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 ele
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 i
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 p
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
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...@
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 MBI
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 (e
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 defini
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 de
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 rule
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 specifi
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
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 i
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
--
Yo
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
> ```
> pac
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 questi
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
> 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
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 = &p
fmt.Println(**
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 *
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
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. Specificall
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
> pointe
27 matches
Mail list logo
