padTo - why append but no prepend?

[Luigi]

Any ideas why we have a padTo method on SeqLike that appends elements to the end, but no corresponding method to prepend them? I thought we were supposed to favour prepending over appending. And it would be pretty useful for things like padding string representations of numbers with zeros, right-alligning text etc.

[Rex Kerr]

We already have too many methods that do trivial variants of things that other methods can do.  Prepending can be done with xs.reverse.padTo(n).reverse.  A padOnLeft(n) method isn't worth the overhead (or if you think it is, you can pimp it in).
  --Rex

[Tom Switzer]

Not a huge use case for strings, as format does lots:

"%8s" format "hello" // Right justified: "   hello"

"%08d" format 123   // 0 padded: "00000123"

On Fri, Sep 16, 2011 at 11:03 PM, Luigi <rjon...@gmail.com> wrote:

[Lars Hupel]

> Prepending can be done with xs.reverse.padTo(n).reverse.

I disagree with that solution. `.reverse` is an O(n) operation, but a
hypothetical `padToFront` might be implemented in O(1) if the collection
supports efficient prepending. If not, it is still faster because only
one copy operation is needed instead of two.

> (or if you think it is, you can pimp it in).

Indeed, that would be the better solution.

[Luigi]

Hi Rex. Lars hit on what I was thinking: if you're only going to include one padTo method, wouldn't it be more efficient to include a prepend one instead, and make people reverse their Lists twice if they want to append (which the implementation would have to do anyway)?

I'm interested why you say there are too many methods. What exactly are these overheads you mention, and what would be the effect on performance if there were, say, 5x as many methods on SeqLike? Have such things been measured? From a naive (i.e. my) perspective, it looks like the padTo method is only a couple of hundred characters, and presumably even shorter in bytecode. Other missing but potentially useful methods like dropRightWhile would take even less space.

I could try to pimp this method onto the Collections library myself, but as your Stack Overflow Q/A shows, this isn't exactly trivial (beyond the abilities of the average Scala dabbler, at least). It also requires a fair amount of wheel-reinvention by each user and/or dependency introduction, which it would be nicer to avoid. Overall it's not worth the effort, so my code becomes just a bit less elegant and efficient as a result.

[Lars Hupel]

> Hi Rex. Lars hit on what I was thinking: if you're only going to include one
> padTo method, wouldn't it be more efficient to include a prepend one
> instead, and make people reverse their Lists twice if they want to append
> (which the implementation would have to do anyway)?

Neither of one should be preferred. There are indeed collections which
support efficient appending (or even efficient appending and prepending,
e. g. Finger Trees).

[Rex Kerr]

On Sat, Sep 17, 2011 at 5:53 PM, Luigi <rjon...@gmail.com> wrote:

Hi Rex. Lars hit on what I was thinking: if you're only going to include one padTo method, wouldn't it be more efficient to include a prepend one instead, and make people reverse their Lists twice if they want to append (which the implementation would have to do anyway)?

I wouldn't include padTo at all, but you do have a point that prepending to lists is more efficient (and appending to arrays, so you need both).
 

I'm interested why you say there are too many methods. What exactly are these overheads you mention, and what would be the effect on performance if there were, say, 5x as many methods on SeqLike?

It increases the size of the classes in memory, but that's only a problem if you're running on Android or somesuch.  I meant that it introduced a lot of memorization overhead; instead of building the operation that you want with a small number of powerful primitives, you have a separate command for each thing that you could wish for (or most of them, and not entirely consistently).  It also increases the maintenance overhead; each method has to be unit-tested, checked, converted when needed, etc. etc..

I would rather tell people to write
  (xs /: (1 to N - xs.size)){ "pad" :: _ }  // Pad xs on left to size N
and teach people to read this even without the comment, than have a new method for each different type of fold.
 

Have such things been measured? From a naive (i.e. my) perspective, it looks like the padTo method is only a couple of hundred characters, and presumably even shorter in bytecode. Other missing but potentially useful methods like dropRightWhile would take even less space.

Agreed.
 

I could try to pimp this method onto the Collections library myself, but as your Stack Overflow Q/A shows, this isn't exactly trivial (beyond the abilities of the average Scala dabbler, at least).

Also agreed.  I would welcome language changes that made this easier for the vast majority of cases.  (For example, 95% of the time, the builder stuff could be replaced by an implementation of MyType.)

In the meantime, I'd be happy to have various pimps like padTo be a library that you could use when you wanted to use key words instead of write algorithms.  This would simplify implementation and testing since you would only have to guarantee the correct behavior of fold, map, etc., and all the pimps would work just fine.  As it is, it's challenging to figure out which method might have an altered implementation and what that might do to the behavior of the rest of the library.

  --Rex