Re: [go-nuts] Re: Why not tuples?

['Thomas Bushnell BSG' via golang-nuts]

Use the json package to parse the incoming data. Transform it as you
please. Use the json package to format the output.

I'm not sure I see the problem.

On Sat, Dec 3, 2022, 10:47 PM Diogo Baeder  wrote:

> Hi there, sorry for weighting in so late in the game, but I just started
> again to learn Go and was thinking why the language still doesn't have a
> tuple type.
>
> Now, imagine this scenario: I have a web application which has to access a
> webservice that responds with JSON payloads; These payloads are a list of
> values, where each value is a smaller list like '[20220101, 1.234, "New
> York"]'. And these smaller lists follow the same type sequence: int64,
> float64, string. Suppose that I want to filter those values and send a
> response to the client, with the data structure unchanged (same format and
> types). Today, it doesn't seem to be possible to do that in Go, unless I do
> some dirty hack like decoding to '[]any' and then cast to the other types,
> and then hack again to put these values in the response to the client.
>
> I totally understand the reasoning for preferring the usage of structs for
> heterogeneous data (and I myself do prefer them, they're much more powerful
> in general), but there's real world data that's available like in the
> example above, and we just can't go on changing them at their sources. I
> might be mistaken (please let me know if it's the case), but it seems like
> Go is missing an opportunity to interoperate with what's a fundamental data
> structure in many other languages (Python, Rust etc). I'm having a lot of
> fun learning to use the language, and would be happy to see this feature
> being implemented at the core.
>
> (Maybe what I said above is total BS, I acknowledge that since I'm an
> almost complete ignorant in the language)
>
> Cheers!
>
> On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
>
>> Multiple return values. They do kinda exist in a declarative form of
>> sorts, in the type signature, this sets the number and sequence and types
>> of return values. You could even make functions accept them as also input
>> values, I think, but I don't think it works exactly like this. I'm not a
>> fan of these things because of how you have to nominate variables or _ and
>> type inference will make these new variables, if you  := into whatever the
>> return was.
>>
>> I'm not sure what the correct word is for them. Untyped in the same way
>> that literals can be multiple types (especially integers) but singular in
>> their literal form.
>>
>>
>> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>>>
>>> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy 
>>> wrote:
>>>
>>> > Sorry for the self-promotion but it was relevant in that I was working
>>> on how to tidy up the readability of my code and needed multiple returns
>>> and simple untyped tuples were really not nearly as convenient as using a
>>> type struct.
>>>
>>> I have no idea what you mean by 'untyped tuples' because Go does not
>>> have tuples, or at least not as a well defined thing. I can only guess if
>>> you're trying to implement tuples in Go with an array, slice or a struct,
>>> ...? To add to my confusion, Go functions can have as many return values as
>>> one wishes just fine, ie. I obviously do not even understand what problem
>>> you're trying to solve. Sorry.
>>>
>>>
>>> --
>>>
>>> -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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8e728e0f-341d-4340-a868-aac028dfc443n%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/CA%2BYjuxt_bR0wOxkiTp7pYNp-%3DiyzE_KTS-Rk1oRW1wpCv09CUA%40mail.gmail.com.

Re: [go-nuts] Re: Why not tuples?

[Diogo Baeder]

Thanks Brian, that's actually similar to what I'm already doing.

Cheers!

On Wednesday, December 7, 2022 at 8:16:53 AM UTC-3 Brian Candler wrote:

> On Tuesday, 6 December 2022 at 22:27:38 UTC dple...@google.com wrote:
>
>> It'd be great if, for example, you could tag an entire type like:
>>
>> type Row struct { `json:tuple`
>>   date int64
>>   score float64
>>   city string
>> }
>>
>> so that 
>>
>> var v []Row
>> json.Unmarshal(data, )
>>
>> would automatically parse the triples into usable structs (and 
>> json.Marshal would turn them back into lists).
>>
>
> You can wrap that pattern yourself though, and it's not too much work.
> https://go.dev/play/p/JtUxQUQdd92
>
>

-- 
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/0d101208-c021-4fb2-add4-ca498437e04fn%40googlegroups.com.

Re: [go-nuts] Re: Why not tuples?

[Brian Candler]

On Tuesday, 6 December 2022 at 22:27:38 UTC dple...@google.com wrote:

> It'd be great if, for example, you could tag an entire type like:
>
> type Row struct { `json:tuple`
>   date int64
>   score float64
>   city string
> }
>
> so that 
>
> var v []Row
> json.Unmarshal(data, )
>
> would automatically parse the triples into usable structs (and 
> json.Marshal would turn them back into lists).
>

You can wrap that pattern yourself though, and it's not too much work.
https://go.dev/play/p/JtUxQUQdd92

-- 
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/574cb836-c77f-44e5-841e-920b5b1bf48an%40googlegroups.com.

Re: [go-nuts] Re: Why not tuples?

[Diogo Baeder]

That was perfectly put, Daniel, thanks! :-)

And, indeed, what I've been doing is to unmarshal as a "[][]any" and then 
coercing to the right types.

I also agree tuples have a place in the world. They're quite common when 
dealing with tabular data - for example, to reduce the amount of repetition 
when describing "rows" of data. But I don't really have to agree or 
disagree - they just exist, and that itself begs for an action: either 
ignore them, or find a workaround (like 
https://github.com/barweiss/go-tuple ), or implement the syntax, type etc 
for it (which I totally understand if it's too hard or undesirable).

Some approaches that I find interesting are Python's type hints (e.g. 
"tuple[int, float, str]", which is well checked with tools like mypy) or 
even the cleaner approach from Rust (e.g. "(i32, f64, String)"). But 
anyway, I digress.

I like the approach with struct tags too; While not being a real 
implementation of tuples, they at least help with unmarshalling and 
marshalling of data to cope with other existing services when they need to 
follow that structure.

Cheers!

On Tuesday, December 6, 2022 at 7:27:38 PM UTC-3 dple...@google.com wrote:

> On Sat, Dec 3, 2022 at 11:34 PM burak serdar  wrote:
>
>>
>>
>> On Sat, Dec 3, 2022 at 8:47 PM Diogo Baeder  wrote:
>>
>>> Now, imagine this scenario: I have a web application which has to access 
>>> a webservice that responds with JSON payloads; These payloads are a list of 
>>> values, where each value is a smaller list like '[20220101, 1.234, "New 
>>> York"]'. And these smaller lists follow the same type sequence: int64, 
>>> float64, string. Suppose that I want to filter those values and send a 
>>> response to the client, with the data structure unchanged (same format and 
>>> types). Today, it doesn't seem to be possible to do that in Go, unless I do 
>>> some dirty hack like decoding to '[]any' and then cast to the other types, 
>>> and then hack again to put these values in the response to the client.
>>>
>>
>> What you described above is a struct. 
>>
>
> I think the problem Diogo is pointing out is a reasonable one - you 
> specify the type of the object you're unpacking by e.g. 
> json.Unmarshal(data, ), but right now there's no way (AFAIK) 
> for the typed object to capture "a list of [int, float, string] triples" 
> except by capturing it as a [][]any and then manually typechecking that 
> each one is indeed an int, a float, and a string.
>
> It'd be great if, for example, you could tag an entire type like:
>
> type Row struct { `json:tuple`
>   date int64
>   score float64
>   city string
> }
>
> so that 
>
> var v []Row
> json.Unmarshal(data, )
>
> would automatically parse the triples into usable structs (and 
> json.Marshal would turn them back into lists).
>
> *
>
> I also don't think arguments that Go doesn't need tuples really hold 
> water, given that Go already *has* tuples, just only for return types. We 
> could all be writing
>
> func Foo() struct{int, error} {
>return struct{int, error}{3, nil}
> }
> v := Foo()
> i, err := v.int, v.error
> ...
>
> but I think everyone agrees that tuples make this code much more readable. 
> Given that we all do agree that there are cases where having tuples makes 
> for better code, I don't actually know why Go doesn't support them in 
> general. Is it out of fear that people will use them poorly, or is it 
> actually pretty complex to implement and not worthwhile?
>
> -- 
> Dan Lepage
>

-- 
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/64d5942a-1723-4578-84f0-d7d3083b1947n%40googlegroups.com.

Re: [go-nuts] Re: Why not tuples?

['Daniel Lepage' via golang-nuts]

On Sat, Dec 3, 2022 at 11:34 PM burak serdar  wrote:

>
>
> On Sat, Dec 3, 2022 at 8:47 PM Diogo Baeder  wrote:
>
>> Now, imagine this scenario: I have a web application which has to access
>> a webservice that responds with JSON payloads; These payloads are a list of
>> values, where each value is a smaller list like '[20220101, 1.234, "New
>> York"]'. And these smaller lists follow the same type sequence: int64,
>> float64, string. Suppose that I want to filter those values and send a
>> response to the client, with the data structure unchanged (same format and
>> types). Today, it doesn't seem to be possible to do that in Go, unless I do
>> some dirty hack like decoding to '[]any' and then cast to the other types,
>> and then hack again to put these values in the response to the client.
>>
>
> What you described above is a struct.
>

I think the problem Diogo is pointing out is a reasonable one - you specify
the type of the object you're unpacking by e.g. json.Unmarshal(data,
), but right now there's no way (AFAIK) for the typed object to
capture "a list of [int, float, string] triples" except by capturing it as
a [][]any and then manually typechecking that each one is indeed an int, a
float, and a string.

It'd be great if, for example, you could tag an entire type like:

type Row struct { `json:tuple`
  date int64
  score float64
  city string
}

so that

var v []Row
json.Unmarshal(data, )

would automatically parse the triples into usable structs (and json.Marshal
would turn them back into lists).

*

I also don't think arguments that Go doesn't need tuples really hold water,
given that Go already *has* tuples, just only for return types. We could
all be writing

func Foo() struct{int, error} {
   return struct{int, error}{3, nil}
}
v := Foo()
i, err := v.int, v.error
...

but I think everyone agrees that tuples make this code much more readable.
Given that we all do agree that there are cases where having tuples makes
for better code, I don't actually know why Go doesn't support them in
general. Is it out of fear that people will use them poorly, or is it
actually pretty complex to implement and not worthwhile?

-- 
Dan Lepage

-- 
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/CAAViQtg6ec7u-iHAo4_%3DvgbcrLLN6-%3DNW-argB_3U8prJ_5cMQ%40mail.gmail.com.

Re: [go-nuts] Re: Why not tuples?

[Roman Kuprov]

I might be missing something, but you can just iterate over your list of 
structs and delete/set-to-default-value the offending field before shipping 
it to your client. Same as tuples afaic.

On Monday, December 5, 2022 at 8:39:17 PM UTC-7 diogo...@gmail.com wrote:

> Hi folks,
>
> Thanks for all the inputs, I really appreciate the effort and help :-)
>
> Regardless of the whole discussion of whether or not tuples are a good or 
> bad data structure, they exist out there in the wild, and we have to deal 
> with them in many situations - of course, in our own code we can opt by 
> continuing to use them or not, depending on the language we're using. It 
> would be nice if Go could support them as first-class citizens - I know 
> it's not the only language that doesn't, though, Java for example doesn't 
> support them either (BTW there's a nice Java library, javatuples, which 
> gives nice names like Pair, Triplet, Quartet etc, to n-sized "tuples" - I 
> find that enjoyable).
>
> Anyways, thanks for the discussion, that helps me get a better grasp of 
> the language!
>
> Cheers!
>
> On Sunday, December 4, 2022 at 11:39:41 PM UTC-3 Kevin Chowski wrote:
>
>> If you really need anonymous tuple types that support decoding that sort 
>> of JSON, it isn't too hard to write one: 
>> https://go.dev/play/p/Fn_wUXh2drs
>>
>> Go's generics don't support varargs types (...yet? who knows) so there'd 
>> be a little copypasta if you needed many different tuple lengths, but Java 
>> has been doing that for years ;)
>>
>> (IMO, using these anonymous tuple types across a whole codebase is not 
>> great: data should be labeled with useful names as it is passed around a 
>> program. But if you really are just using this to make json parsing code 
>> easier, that seems reasonable to me.)
>>
>> On Saturday, December 3, 2022 at 8:47:03 PM UTC-7 diogo...@gmail.com 
>> wrote:
>>
>>> Hi there, sorry for weighting in so late in the game, but I just started 
>>> again to learn Go and was thinking why the language still doesn't have a 
>>> tuple type.
>>>
>>> Now, imagine this scenario: I have a web application which has to access 
>>> a webservice that responds with JSON payloads; These payloads are a list of 
>>> values, where each value is a smaller list like '[20220101, 1.234, "New 
>>> York"]'. And these smaller lists follow the same type sequence: int64, 
>>> float64, string. Suppose that I want to filter those values and send a 
>>> response to the client, with the data structure unchanged (same format and 
>>> types). Today, it doesn't seem to be possible to do that in Go, unless I do 
>>> some dirty hack like decoding to '[]any' and then cast to the other types, 
>>> and then hack again to put these values in the response to the client.
>>>
>>> I totally understand the reasoning for preferring the usage of structs 
>>> for heterogeneous data (and I myself do prefer them, they're much more 
>>> powerful in general), but there's real world data that's available like in 
>>> the example above, and we just can't go on changing them at their sources. 
>>> I might be mistaken (please let me know if it's the case), but it seems 
>>> like Go is missing an opportunity to interoperate with what's a fundamental 
>>> data structure in many other languages (Python, Rust etc). I'm having a lot 
>>> of fun learning to use the language, and would be happy to see this feature 
>>> being implemented at the core.
>>>
>>> (Maybe what I said above is total BS, I acknowledge that since I'm an 
>>> almost complete ignorant in the language)
>>>
>>> Cheers!
>>>
>>> On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
>>>
 Multiple return values. They do kinda exist in a declarative form of 
 sorts, in the type signature, this sets the number and sequence and types 
 of return values. You could even make functions accept them as also input 
 values, I think, but I don't think it works exactly like this. I'm not a 
 fan of these things because of how you have to nominate variables or _ and 
 type inference will make these new variables, if you  := into whatever the 
 return was.

 I'm not sure what the correct word is for them. Untyped in the same way 
 that literals can be multiple types (especially integers) but singular in 
 their literal form.


 On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy <
> louki.sumir...@gmail.com> wrote:
>
> > Sorry for the self-promotion but it was relevant in that I was 
> working on how to tidy up the readability of my code and needed multiple 
> returns and simple untyped tuples were really not nearly as convenient as 
> using a type struct.
>
> I have no idea what you mean by 'untyped tuples' because Go does not 
> have tuples, or at least not as a well defined thing. I can only guess if 
> you're trying to implement tuples in Go with 

Re: [go-nuts] Re: Why not tuples?

[Robert Engels]

I worked on a system one time - in Java - that used a Sextuplet. I kid you not. 
Please. Please. Please use typed structures and save the futures maintainers 
they pain. It’s a little extra work up front that pays big dividends. 

> On Dec 5, 2022, at 9:39 PM, Diogo Baeder  wrote:
> 
> 
> Hi folks,
> 
> Thanks for all the inputs, I really appreciate the effort and help :-)
> 
> Regardless of the whole discussion of whether or not tuples are a good or bad 
> data structure, they exist out there in the wild, and we have to deal with 
> them in many situations - of course, in our own code we can opt by continuing 
> to use them or not, depending on the language we're using. It would be nice 
> if Go could support them as first-class citizens - I know it's not the only 
> language that doesn't, though, Java for example doesn't support them either 
> (BTW there's a nice Java library, javatuples, which gives nice names like 
> Pair, Triplet, Quartet etc, to n-sized "tuples" - I find that enjoyable).
> 
> Anyways, thanks for the discussion, that helps me get a better grasp of the 
> language!
> 
> Cheers!
> 
>> On Sunday, December 4, 2022 at 11:39:41 PM UTC-3 Kevin Chowski wrote:
>> If you really need anonymous tuple types that support decoding that sort of 
>> JSON, it isn't too hard to write one: https://go.dev/play/p/Fn_wUXh2drs
>> 
>> Go's generics don't support varargs types (...yet? who knows) so there'd be 
>> a little copypasta if you needed many different tuple lengths, but Java has 
>> been doing that for years ;)
>> 
>> (IMO, using these anonymous tuple types across a whole codebase is not 
>> great: data should be labeled with useful names as it is passed around a 
>> program. But if you really are just using this to make json parsing code 
>> easier, that seems reasonable to me.)
>> 
>>> On Saturday, December 3, 2022 at 8:47:03 PM UTC-7 diogo...@gmail.com wrote:
>>> Hi there, sorry for weighting in so late in the game, but I just started 
>>> again to learn Go and was thinking why the language still doesn't have a 
>>> tuple type.
>>> 
>>> Now, imagine this scenario: I have a web application which has to access a 
>>> webservice that responds with JSON payloads; These payloads are a list of 
>>> values, where each value is a smaller list like '[20220101, 1.234, "New 
>>> York"]'. And these smaller lists follow the same type sequence: int64, 
>>> float64, string. Suppose that I want to filter those values and send a 
>>> response to the client, with the data structure unchanged (same format and 
>>> types). Today, it doesn't seem to be possible to do that in Go, unless I do 
>>> some dirty hack like decoding to '[]any' and then cast to the other types, 
>>> and then hack again to put these values in the response to the client.
>>> 
>>> I totally understand the reasoning for preferring the usage of structs for 
>>> heterogeneous data (and I myself do prefer them, they're much more powerful 
>>> in general), but there's real world data that's available like in the 
>>> example above, and we just can't go on changing them at their sources. I 
>>> might be mistaken (please let me know if it's the case), but it seems like 
>>> Go is missing an opportunity to interoperate with what's a fundamental data 
>>> structure in many other languages (Python, Rust etc). I'm having a lot of 
>>> fun learning to use the language, and would be happy to see this feature 
>>> being implemented at the core.
>>> 
>>> (Maybe what I said above is total BS, I acknowledge that since I'm an 
>>> almost complete ignorant in the language)
>>> 
>>> Cheers!
>>> 
 On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
 Multiple return values. They do kinda exist in a declarative form of 
 sorts, in the type signature, this sets the number and sequence and types 
 of return values. You could even make functions accept them as also input 
 values, I think, but I don't think it works exactly like this. I'm not a 
 fan of these things because of how you have to nominate variables or _ and 
 type inference will make these new variables, if you  := into whatever the 
 return was.
 
 I'm not sure what the correct word is for them. Untyped in the same way 
 that literals can be multiple types (especially integers) but singular in 
 their literal form.
 
 
> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy  
> wrote:
> 
> > Sorry for the self-promotion but it was relevant in that I was working 
> > on how to tidy up the readability of my code and needed multiple 
> > returns and simple untyped tuples were really not nearly as convenient 
> > as using a type struct.
> 
> I have no idea what you mean by 'untyped tuples' because Go does not have 
> tuples, or at least not as a well defined thing. I can only guess if 
> you're trying to implement tuples in Go with an 

Re: [go-nuts] Re: Why not tuples?

[Diogo Baeder]

Hi folks,

Thanks for all the inputs, I really appreciate the effort and help :-)

Regardless of the whole discussion of whether or not tuples are a good or 
bad data structure, they exist out there in the wild, and we have to deal 
with them in many situations - of course, in our own code we can opt by 
continuing to use them or not, depending on the language we're using. It 
would be nice if Go could support them as first-class citizens - I know 
it's not the only language that doesn't, though, Java for example doesn't 
support them either (BTW there's a nice Java library, javatuples, which 
gives nice names like Pair, Triplet, Quartet etc, to n-sized "tuples" - I 
find that enjoyable).

Anyways, thanks for the discussion, that helps me get a better grasp of the 
language!

Cheers!

On Sunday, December 4, 2022 at 11:39:41 PM UTC-3 Kevin Chowski wrote:

> If you really need anonymous tuple types that support decoding that sort 
> of JSON, it isn't too hard to write one: https://go.dev/play/p/Fn_wUXh2drs
>
> Go's generics don't support varargs types (...yet? who knows) so there'd 
> be a little copypasta if you needed many different tuple lengths, but Java 
> has been doing that for years ;)
>
> (IMO, using these anonymous tuple types across a whole codebase is not 
> great: data should be labeled with useful names as it is passed around a 
> program. But if you really are just using this to make json parsing code 
> easier, that seems reasonable to me.)
>
> On Saturday, December 3, 2022 at 8:47:03 PM UTC-7 diogo...@gmail.com 
> wrote:
>
>> Hi there, sorry for weighting in so late in the game, but I just started 
>> again to learn Go and was thinking why the language still doesn't have a 
>> tuple type.
>>
>> Now, imagine this scenario: I have a web application which has to access 
>> a webservice that responds with JSON payloads; These payloads are a list of 
>> values, where each value is a smaller list like '[20220101, 1.234, "New 
>> York"]'. And these smaller lists follow the same type sequence: int64, 
>> float64, string. Suppose that I want to filter those values and send a 
>> response to the client, with the data structure unchanged (same format and 
>> types). Today, it doesn't seem to be possible to do that in Go, unless I do 
>> some dirty hack like decoding to '[]any' and then cast to the other types, 
>> and then hack again to put these values in the response to the client.
>>
>> I totally understand the reasoning for preferring the usage of structs 
>> for heterogeneous data (and I myself do prefer them, they're much more 
>> powerful in general), but there's real world data that's available like in 
>> the example above, and we just can't go on changing them at their sources. 
>> I might be mistaken (please let me know if it's the case), but it seems 
>> like Go is missing an opportunity to interoperate with what's a fundamental 
>> data structure in many other languages (Python, Rust etc). I'm having a lot 
>> of fun learning to use the language, and would be happy to see this feature 
>> being implemented at the core.
>>
>> (Maybe what I said above is total BS, I acknowledge that since I'm an 
>> almost complete ignorant in the language)
>>
>> Cheers!
>>
>> On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
>>
>>> Multiple return values. They do kinda exist in a declarative form of 
>>> sorts, in the type signature, this sets the number and sequence and types 
>>> of return values. You could even make functions accept them as also input 
>>> values, I think, but I don't think it works exactly like this. I'm not a 
>>> fan of these things because of how you have to nominate variables or _ and 
>>> type inference will make these new variables, if you  := into whatever the 
>>> return was.
>>>
>>> I'm not sure what the correct word is for them. Untyped in the same way 
>>> that literals can be multiple types (especially integers) but singular in 
>>> their literal form.
>>>
>>>
>>> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:

 On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy <
 louki.sumir...@gmail.com> wrote:

 > Sorry for the self-promotion but it was relevant in that I was 
 working on how to tidy up the readability of my code and needed multiple 
 returns and simple untyped tuples were really not nearly as convenient as 
 using a type struct.

 I have no idea what you mean by 'untyped tuples' because Go does not 
 have tuples, or at least not as a well defined thing. I can only guess if 
 you're trying to implement tuples in Go with an array, slice or a struct, 
 ...? To add to my confusion, Go functions can have as many return values 
 as 
 one wishes just fine, ie. I obviously do not even understand what problem 
 you're trying to solve. Sorry.


 -- 

 -j

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 

Re: [go-nuts] Re: Why not tuples?

[Kevin Chowski]

If you really need anonymous tuple types that support decoding that sort of 
JSON, it isn't too hard to write one: https://go.dev/play/p/Fn_wUXh2drs

Go's generics don't support varargs types (...yet? who knows) so there'd be 
a little copypasta if you needed many different tuple lengths, but Java has 
been doing that for years ;)

(IMO, using these anonymous tuple types across a whole codebase is not 
great: data should be labeled with useful names as it is passed around a 
program. But if you really are just using this to make json parsing code 
easier, that seems reasonable to me.)

On Saturday, December 3, 2022 at 8:47:03 PM UTC-7 diogo...@gmail.com wrote:

> Hi there, sorry for weighting in so late in the game, but I just started 
> again to learn Go and was thinking why the language still doesn't have a 
> tuple type.
>
> Now, imagine this scenario: I have a web application which has to access a 
> webservice that responds with JSON payloads; These payloads are a list of 
> values, where each value is a smaller list like '[20220101, 1.234, "New 
> York"]'. And these smaller lists follow the same type sequence: int64, 
> float64, string. Suppose that I want to filter those values and send a 
> response to the client, with the data structure unchanged (same format and 
> types). Today, it doesn't seem to be possible to do that in Go, unless I do 
> some dirty hack like decoding to '[]any' and then cast to the other types, 
> and then hack again to put these values in the response to the client.
>
> I totally understand the reasoning for preferring the usage of structs for 
> heterogeneous data (and I myself do prefer them, they're much more powerful 
> in general), but there's real world data that's available like in the 
> example above, and we just can't go on changing them at their sources. I 
> might be mistaken (please let me know if it's the case), but it seems like 
> Go is missing an opportunity to interoperate with what's a fundamental data 
> structure in many other languages (Python, Rust etc). I'm having a lot of 
> fun learning to use the language, and would be happy to see this feature 
> being implemented at the core.
>
> (Maybe what I said above is total BS, I acknowledge that since I'm an 
> almost complete ignorant in the language)
>
> Cheers!
>
> On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
>
>> Multiple return values. They do kinda exist in a declarative form of 
>> sorts, in the type signature, this sets the number and sequence and types 
>> of return values. You could even make functions accept them as also input 
>> values, I think, but I don't think it works exactly like this. I'm not a 
>> fan of these things because of how you have to nominate variables or _ and 
>> type inference will make these new variables, if you  := into whatever the 
>> return was.
>>
>> I'm not sure what the correct word is for them. Untyped in the same way 
>> that literals can be multiple types (especially integers) but singular in 
>> their literal form.
>>
>>
>> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>>>
>>> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy  
>>> wrote:
>>>
>>> > Sorry for the self-promotion but it was relevant in that I was working 
>>> on how to tidy up the readability of my code and needed multiple returns 
>>> and simple untyped tuples were really not nearly as convenient as using a 
>>> type struct.
>>>
>>> I have no idea what you mean by 'untyped tuples' because Go does not 
>>> have tuples, or at least not as a well defined thing. I can only guess if 
>>> you're trying to implement tuples in Go with an array, slice or a struct, 
>>> ...? To add to my confusion, Go functions can have as many return values as 
>>> one wishes just fine, ie. I obviously do not even understand what problem 
>>> you're trying to solve. Sorry.
>>>
>>>
>>> -- 
>>>
>>> -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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a44eddb7-55d5-4203-a0bc-393b6ec31baan%40googlegroups.com.

Re: [go-nuts] Re: Why not tuples?

[burak serdar]

On Sat, Dec 3, 2022 at 8:47 PM Diogo Baeder  wrote:

> Hi there, sorry for weighting in so late in the game, but I just started
> again to learn Go and was thinking why the language still doesn't have a
> tuple type.
>
> Now, imagine this scenario: I have a web application which has to access a
> webservice that responds with JSON payloads; These payloads are a list of
> values, where each value is a smaller list like '[20220101, 1.234, "New
> York"]'. And these smaller lists follow the same type sequence: int64,
> float64, string. Suppose that I want to filter those values and send a
> response to the client, with the data structure unchanged (same format and
> types). Today, it doesn't seem to be possible to do that in Go, unless I do
> some dirty hack like decoding to '[]any' and then cast to the other types,
> and then hack again to put these values in the response to the client.
>

What you described above is a struct.


>
> I totally understand the reasoning for preferring the usage of structs for
> heterogeneous data (and I myself do prefer them, they're much more powerful
> in general), but there's real world data that's available like in the
> example above, and we just can't go on changing them at their sources. I
> might be mistaken (please let me know if it's the case), but it seems like
> Go is missing an opportunity to interoperate with what's a fundamental data
> structure in many other languages (Python, Rust etc). I'm having a lot of
> fun learning to use the language, and would be happy to see this feature
> being implemented at the core.
>

In general, you can implement most tuple functionality using []any.
However, when dealing with unpredictable data structures like an unknown
JSON document, third-party libraries might be better suited than a
map[string]any. When you have a tuple like that, you have to "discover" the
type of each variable and parse it to do any nontrivial processing. You
can't really unmarshal a string from a JSON document and expect to get a
date in the tuple. My current work is on the interoperability of
heterogeneous data, so for XML documents we use DOM libraries, for JSON
documents we wrote https://github.com/bserdar/jsonom, etc.


>
> (Maybe what I said above is total BS, I acknowledge that since I'm an
> almost complete ignorant in the language)
>
> Cheers!
>
> On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
>
>> Multiple return values. They do kinda exist in a declarative form of
>> sorts, in the type signature, this sets the number and sequence and types
>> of return values. You could even make functions accept them as also input
>> values, I think, but I don't think it works exactly like this. I'm not a
>> fan of these things because of how you have to nominate variables or _ and
>> type inference will make these new variables, if you  := into whatever the
>> return was.
>>
>> I'm not sure what the correct word is for them. Untyped in the same way
>> that literals can be multiple types (especially integers) but singular in
>> their literal form.
>>
>>
>> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>>>
>>> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy 
>>> wrote:
>>>
>>> > Sorry for the self-promotion but it was relevant in that I was working
>>> on how to tidy up the readability of my code and needed multiple returns
>>> and simple untyped tuples were really not nearly as convenient as using a
>>> type struct.
>>>
>>> I have no idea what you mean by 'untyped tuples' because Go does not
>>> have tuples, or at least not as a well defined thing. I can only guess if
>>> you're trying to implement tuples in Go with an array, slice or a struct,
>>> ...? To add to my confusion, Go functions can have as many return values as
>>> one wishes just fine, ie. I obviously do not even understand what problem
>>> you're trying to solve. Sorry.
>>>
>>>
>>> --
>>>
>>> -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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8e728e0f-341d-4340-a868-aac028dfc443n%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/CAMV2Rqq%2BDmRDuqcxW-DF%2ByDqTrAu%3DNv51wLWZsx2ERiYEv%3DZ1w%40mail.gmail.com.

Re: [go-nuts] Re: Why not tuples?

[Diogo Baeder]

Hi there, sorry for weighting in so late in the game, but I just started 
again to learn Go and was thinking why the language still doesn't have a 
tuple type.

Now, imagine this scenario: I have a web application which has to access a 
webservice that responds with JSON payloads; These payloads are a list of 
values, where each value is a smaller list like '[20220101, 1.234, "New 
York"]'. And these smaller lists follow the same type sequence: int64, 
float64, string. Suppose that I want to filter those values and send a 
response to the client, with the data structure unchanged (same format and 
types). Today, it doesn't seem to be possible to do that in Go, unless I do 
some dirty hack like decoding to '[]any' and then cast to the other types, 
and then hack again to put these values in the response to the client.

I totally understand the reasoning for preferring the usage of structs for 
heterogeneous data (and I myself do prefer them, they're much more powerful 
in general), but there's real world data that's available like in the 
example above, and we just can't go on changing them at their sources. I 
might be mistaken (please let me know if it's the case), but it seems like 
Go is missing an opportunity to interoperate with what's a fundamental data 
structure in many other languages (Python, Rust etc). I'm having a lot of 
fun learning to use the language, and would be happy to see this feature 
being implemented at the core.

(Maybe what I said above is total BS, I acknowledge that since I'm an 
almost complete ignorant in the language)

Cheers!

On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:

> Multiple return values. They do kinda exist in a declarative form of 
> sorts, in the type signature, this sets the number and sequence and types 
> of return values. You could even make functions accept them as also input 
> values, I think, but I don't think it works exactly like this. I'm not a 
> fan of these things because of how you have to nominate variables or _ and 
> type inference will make these new variables, if you  := into whatever the 
> return was.
>
> I'm not sure what the correct word is for them. Untyped in the same way 
> that literals can be multiple types (especially integers) but singular in 
> their literal form.
>
>
> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>>
>> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy  
>> wrote:
>>
>> > Sorry for the self-promotion but it was relevant in that I was working 
>> on how to tidy up the readability of my code and needed multiple returns 
>> and simple untyped tuples were really not nearly as convenient as using a 
>> type struct.
>>
>> I have no idea what you mean by 'untyped tuples' because Go does not have 
>> tuples, or at least not as a well defined thing. I can only guess if you're 
>> trying to implement tuples in Go with an array, slice or a struct, ...? To 
>> add to my confusion, Go functions can have as many return values as one 
>> wishes just fine, ie. I obviously do not even understand what problem 
>> you're trying to solve. Sorry.
>>
>>
>> -- 
>>
>> -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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8e728e0f-341d-4340-a868-aac028dfc443n%40googlegroups.com.

Re: [go-nuts] Re: Why not tuples?

[Louki Sumirniy]

Multiple return values. They do kinda exist in a declarative form of sorts, 
in the type signature, this sets the number and sequence and types of 
return values. You could even make functions accept them as also input 
values, I think, but I don't think it works exactly like this. I'm not a 
fan of these things because of how you have to nominate variables or _ and 
type inference will make these new variables, if you  := into whatever the 
return was.

I'm not sure what the correct word is for them. Untyped in the same way 
that literals can be multiple types (especially integers) but singular in 
their literal form.

On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy  > wrote:
>
> > Sorry for the self-promotion but it was relevant in that I was working 
> on how to tidy up the readability of my code and needed multiple returns 
> and simple untyped tuples were really not nearly as convenient as using a 
> type struct.
>
> I have no idea what you mean by 'untyped tuples' because Go does not have 
> tuples, or at least not as a well defined thing. I can only guess if you're 
> trying to implement tuples in Go with an array, slice or a struct, ...? To 
> add to my confusion, Go functions can have as many return values as one 
> wishes just fine, ie. I obviously do not even understand what problem 
> you're trying to solve. Sorry.
>
>
> -- 
>
> -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: Why not tuples?

[Jan Mercl]

On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

> Sorry for the self-promotion but it was relevant in that I was working on
how to tidy up the readability of my code and needed multiple returns and
simple untyped tuples were really not nearly as convenient as using a type
struct.

I have no idea what you mean by 'untyped tuples' because Go does not have
tuples, or at least not as a well defined thing. I can only guess if you're
trying to implement tuples in Go with an array, slice or a struct, ...? To
add to my confusion, Go functions can have as many return values as one
wishes just fine, ie. I obviously do not even understand what problem
you're trying to solve. Sorry.


-- 

-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: Why not tuples?

[Louki Sumirniy]

Just to clarify. Yes, the parent/child relationships are purely based on 
the indices of the nodes. It's not a conventional vector reference based 
binary tree. I was surprised when I came up with the idea that such did not 
even exist. Just to explain, it's a non-rectilinear array mapping. There is 
rows, and a root, and each row is double the size of the one above it. The 
name BAST comes from Bifurcation Array Search Tree. As far as I know it is 
the only non-linear/non-grid based ever invented. By me of course, so of 
course I am proud of it.

The coordinates stored in Cursor do not have any meaning except in a 
specific instance of the BAST array at a specific moment. I haven't worked 
out any strategies for multiple readers of the array, but I imagine it 
would just take a blocking table based on sections of the array, such as 4k 
pages or so, while the write process is changing it. Probably even, it's 
not possible to partially block read access for concurrency at all because 
many times write operations will stomp all over the tree in a random way 
because that's how hashes tend to be... random... Besides this, the atomic 
write operations generally won't block read access for long periods of time 
anyway. 

If I have piqued your curiosity, go check out the repo 
here: https://github.com/calibrae-project/bast - To sum it up in short 
words, it aims at eliminating retrieval latency caused by nonlinear seeking 
on memory devices. It has applicability to database lookup tables and 
should perform also quite well even on spinning disk cached stores (if they 
are allocated in one giant 2-4Gb blob).

Sorry for the self-promotion but it was relevant in that I was working on 
how to tidy up the readability of my code and needed multiple returns and 
simple untyped tuples were really not nearly as convenient as using a type 
struct. After doing a bunch of work on getting parametric polymorphism 
implemented in go, which is only obliquely relevant, I wrote a Gist about 
it: https://gist.github.com/l0k1verloren/469a4e467a2789daa04de60449af11cc 
No idea why nobody has written such a simple explanation and example of how 
to do it. You will spend 2 minutes on that and understand that actually, 
yes, you can do multiple inheritance in Go quite easily once you understand 
interface{} and parametric polymorphism is the simplest case.

On Thursday, 19 April 2018 08:31:01 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 6:57 AM Louki Sumirniy  > wrote:
>
>>
>> func (b *Bast) Parent(c Cursor) Cursor {
>> if c.Index == 0 {
>> c.Err = errors.New("No parent from the root")
>> return c
>> }
>> c.Row--
>> c.Index = c.Index>>1 - (c.Index+1)%2
>> c.Err = nil
>> return c
>> }
>>
>
> This method looks like it should be defined be on *Cursor receiver, not 
> *Bast.
>
> -- 
>
> -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: Why not tuples?

[Louki Sumirniy]

Ok, it may look like it but I don't want to track the cursor in the 
datatype itself most especially for reasons being that even one of the 
'sideways walk' functions in the library needs to keep a copy of the 
coordinate of the previous node iterated past in order to identify when the 
direction (left or right) changes, for specific (common) cases. The Bast is 
the data structure and contains all the data. Cursor is just a convenience 
way of storing the coordinate in the tree, the row of the coordinate and an 
easy way to return error values. So the 'cursor' has to be usable in 
external code, and external also to the data it points at, because there 
could be multiple trees being operated on within one application using this 
library.

On Thursday, 19 April 2018 08:31:01 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 6:57 AM Louki Sumirniy  > wrote:
>
>>
>> func (b *Bast) Parent(c Cursor) Cursor {
>> if c.Index == 0 {
>> c.Err = errors.New("No parent from the root")
>> return c
>> }
>> c.Row--
>> c.Index = c.Index>>1 - (c.Index+1)%2
>> c.Err = nil
>> return c
>> }
>>
>
> This method looks like it should be defined be on *Cursor receiver, not 
> *Bast.
>
> -- 
>
> -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: Why not tuples?

[Jan Mercl]

On Thu, Apr 19, 2018 at 6:57 AM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

>
> func (b *Bast) Parent(c Cursor) Cursor {
> if c.Index == 0 {
> c.Err = errors.New("No parent from the root")
> return c
> }
> c.Row--
> c.Index = c.Index>>1 - (c.Index+1)%2
> c.Err = nil
> return c
> }
>

This method looks like it should be defined be on *Cursor receiver, not
*Bast.

-- 

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