Re: [go-nuts] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Aram Hăvărneanu]

> On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck  wrote:
>> bytes.Replace(s []byte, pos int, len uint, new []byte)
>
> I have no idea what this bizarre hypothetical function does. It's an
> awful interface that aims to solve an unknown problem nobody has
> claimed to have.
>
> Also, bytes.Replace already exists.
>

Also, slice lengths are signed integers, not unsigned integers. I
suggest you familiarize more with slices before suggest these
"improvements".

-- 
Aram Hăvărneanu

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Aram Hăvărneanu]

On Mon, Oct 17, 2016 at 8:29 PM, Liam Breck  wrote:
> bytes.Replace(s []byte, pos int, len uint, new []byte)

I have no idea what this bizarre hypothetical function does. It's an
awful interface that aims to solve an unknown problem nobody has
claimed to have.

Also, bytes.Replace already exists.

-- 
Aram Hăvărneanu

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Liam Breck]

On Oct 16, 2016 6:03 PM, "Liam Breck"  wrote:
>
>
>
> On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor  wrote:
>>
>> On Sun, Oct 16, 2016 at 5:25 PM, Liam  wrote:
>> >
>> > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor
wrote:
>> >>
>> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam  wrote:
>> >> >
>> >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor
wrote:
>> >> >
>> >> >> To argue that this should go into the standard library, look at
some
>> >> >> corpus of Go code and find out how often it occurs.  If it occurs
>> >> >> fairly often, you've got a good case.
>> >> >
>> >> >
>> >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it
>> >> > passes
>> >> > that test.
>> >>
>> >> This is something that can actually be measured.
>> >
>> >
>> > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ?
>> > Neither of these will be accurate.
>> >
>> > Part of my point is that Insert operations are semantically obscured.
>>
>> Understood.  But my guess is that insertion operations are fairly
>> rare--much less common than Replace or Trim.  People obviously append
>> to slices all the time, but I suspect that they tend to write their
>> slice operations to not require inserting a single element in the
>> middle of the slice, because insertion is by definition O(N) rather
>> than O(1).  I could certainly be wrong, but that guess leads me to
>> suspect that adding a function for something that can easily be
>> written in a single expression is overkill.  Since I am only guessing,
>> and since it seems to me that you are also guessing, I think we should
>> measure rather than guess.
>
>
> You characterize optimization as a widespread habit. Most code isn't
optimized, as it doesn't need to be. Most coders follow the first advice
found, which in my case was Insert() on [1]. If you wish the most optimal
solution to be widespread, stdlib would be a good vehicle :-)
>
> I would attempt to provide data confirming my guess, but I can't see how
to do that without spending a lot of time hunting for semantically
invisible operations. Since there are two authoritative suggestions for
this op, it's a reasonable guess that it's widely done.
>
> BTW, we are having this discussion because fmt does not support thousands
grouping, which also seems like a common need.
>
> [1] https://blog.golang.org/slices

As an alternative to bytes.Insert/Delete how about

bytes.Replace(s []byte, pos int, len uint, new []byte)

A zero len is insert, and empty new is delete.

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Liam Breck]

On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor  wrote:

> On Sun, Oct 16, 2016 at 5:25 PM, Liam  wrote:
> >
> > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote:
> >>
> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam  wrote:
> >> >
> >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor
> wrote:
> >> >
> >> >> To argue that this should go into the standard library, look at some
> >> >> corpus of Go code and find out how often it occurs.  If it occurs
> >> >> fairly often, you've got a good case.
> >> >
> >> >
> >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it
> >> > passes
> >> > that test.
> >>
> >> This is something that can actually be measured.
> >
> >
> > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ?
> > Neither of these will be accurate.
> >
> > Part of my point is that Insert operations are semantically obscured.
>
> Understood.  But my guess is that insertion operations are fairly
> rare--much less common than Replace or Trim.  People obviously append
> to slices all the time, but I suspect that they tend to write their
> slice operations to not require inserting a single element in the
> middle of the slice, because insertion is by definition O(N) rather
> than O(1).  I could certainly be wrong, but that guess leads me to
> suspect that adding a function for something that can easily be
> written in a single expression is overkill.  Since I am only guessing,
> and since it seems to me that you are also guessing, I think we should
> measure rather than guess.
>

You characterize optimization as a widespread habit. Most code isn't
optimized, as it doesn't need to be. Most coders follow the first advice
found, which in my case was Insert() on [1]. If you wish the most optimal
solution to be widespread, stdlib would be a good vehicle :-)

I would attempt to provide data confirming my guess, but I can't see how to
do that without spending a lot of time hunting for semantically invisible
operations. Since there are two authoritative suggestions for this op, it's
a reasonable guess that it's widely done.

BTW, we are having this discussion because fmt does not support thousands
grouping, which also seems like a common need.

[1] https://blog.golang.org/slices

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Ian Lance Taylor]

On Sun, Oct 16, 2016 at 5:25 PM, Liam  wrote:
>
> On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Sun, Oct 16, 2016 at 3:34 PM, Liam  wrote:
>> >
>> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote:
>> >
>> >> To argue that this should go into the standard library, look at some
>> >> corpus of Go code and find out how often it occurs.  If it occurs
>> >> fairly often, you've got a good case.
>> >
>> >
>> > Fairly often; i.e. as often as Replace or Trim*? In my experience it
>> > passes
>> > that test.
>>
>> This is something that can actually be measured.
>
>
> By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ?
> Neither of these will be accurate.
>
> Part of my point is that Insert operations are semantically obscured.

Understood.  But my guess is that insertion operations are fairly
rare--much less common than Replace or Trim.  People obviously append
to slices all the time, but I suspect that they tend to write their
slice operations to not require inserting a single element in the
middle of the slice, because insertion is by definition O(N) rather
than O(1).  I could certainly be wrong, but that guess leads me to
suspect that adding a function for something that can easily be
written in a single expression is overkill.  Since I am only guessing,
and since it seems to me that you are also guessing, I think we should
measure rather than guess.

Ian

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Liam]

On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote:
>
> On Sun, Oct 16, 2016 at 3:34 PM, Liam  
> wrote: 
> > 
> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote: 
> > 
> >> To argue that this should go into the standard library, look at some 
> >> corpus of Go code and find out how often it occurs.  If it occurs 
> >> fairly often, you've got a good case. 
> > 
> > 
> > Fairly often; i.e. as often as Replace or Trim*? In my experience it 
> passes 
> > that test. 
>
> This is something that can actually be measured. 
>

By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ?
Neither of these will be accurate.

Part of my point is that Insert operations are semantically obscured.

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Ian Lance Taylor]

On Sun, Oct 16, 2016 at 3:34 PM, Liam  wrote:
>
> On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote:
>
>> To argue that this should go into the standard library, look at some
>> corpus of Go code and find out how often it occurs.  If it occurs
>> fairly often, you've got a good case.
>
>
> Fairly often; i.e. as often as Replace or Trim*? In my experience it passes
> that test.

This is something that can actually be measured.

Ian

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Liam]

On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote:
>
>  
> > A function to insert a byte into a slice is conspicuous by its absence. 
>
> It's a one-liner. 
> append(s[:p], append([]byte{b}, s[p:]...)...) 
>

This is already gobbledygook :) Does that read "Insert" to you? It doesn't 
to me.
 

> it's easy enough to write a helper function yourself. 
>

Of course, but two reasons for the stdlib are:
  foster semantic clarity in client code
  prevent innumerable variations across packages in the name and signature 
of a common function

To argue that this should go into the standard library, look at some 
> corpus of Go code and find out how often it occurs.  If it occurs 
> fairly often, you've got a good case. 
>

Fairly often; i.e. as often as Replace or Trim*? In my experience it passes 
that test.

That Insert and Delete are missing implies to me that there is something 
strange about such operations.

-- 
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] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Ian Lance Taylor]

On Sun, Oct 16, 2016 at 1:49 PM, Liam  wrote:
>
> A function to insert a byte into a slice is conspicuous by its absence.

It's a one-liner.
append(s[:p], append([]byte{b}, s[p:]...)...)
(You may want to look at https://github.com/golang/go/wiki/SliceTricks).


> // but instead it's gobbledygook:

In particular cases where the one-liner is goobledygook, it's easy
enough to write a helper function yourself.

To argue that this should go into the standard library, look at some
corpus of Go code and find out how often it occurs.  If it occurs
fairly often, you've got a good case.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Liam]

A function to insert a byte into a slice is conspicuous by its absence.

Consider this code to parse /proc/meminfo into a 2D array and insert commas:

MemTotal: 497464 kB
MemFree:  386232 kB
MemAvailable: 452420 kB
Buffers:8612 kB
Cached:60160 kB
...
.
aLine := bytes.SplitN(fileBuf, []byte("\n"), 6)
var aPair [5][][]byte
for a := 0; a < 5; a++ {
  aPair[a] = bytes.SplitN(aLine[a], []byte(":"), 2)
  aPair[a][1] = sRegEx.FindSubmatch(aPair[a][1])[1] // " *([0-9]+)"
  if len(aPair[a][1]) > 3 {
// should be:
// aPair[a][1] = bytes.InsertByte(aPair[a][1], len(aPair[a][1])-3, 
',')

// but instead it's gobbledygook:
aPair[a][1] = aPair[a][1][:len(aPair[a][1])+1]
copy(aPair[a][1][len(aPair[a][1])-2:], 
aPair[a][1][len(aPair[a][1])-3:])
aPair[a][1][len(aPair[a][1])-4] = ','
  }
}

Surely this is common enough to merit inclusion in stdlib.

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