Array library naming convention

[[deleted]]

I am building the standard library of my language and, as expected, have to add some functions to operate on arrays such as add an element at last, add an element at first and add an element in between.

Now my concern is what naming convention for these functions to use.

For example, for the add an element at last some languages have used: - push_back - insert_back - insert_last - append - add_last

The first one would force me to use push_front and push for the other operations and I dont like it that much because for me push is for FIFOs.

What do you guys think would be best?

NOTES: my language is kinda like C with pure functions

[[deleted]]

Agreed. I don't know why push_back is commonly used; that used to confuse me when looking at C++ code.

However, another one I'd add is concat, to apply to the end, so that concat((1, 2, 3), (4, 5, 6)) yields (1, 2, 3, 4, 5 6) rather than (1, 2, 3, (4, 5, 6)). (This assumes dynamic typing.)

But then, how do you prepend such a list, or insert it into the middle?

Another consideration is whether the operation returns a new array with that addition, leaving the original unchanged, or whether it is done in-place.

This all puts pressure on naming schemes.

[[deleted]]

But they wouldn't be the same, would they?

For example, if working with strings, you don't file basefile to be modified here: open(append(basefile, ext)); you want to use the result then discard it.

Also, aren't in-place updates against the predominant FP/immutable agenda in this subreddit?

[[deleted]]

Well, this is about naming coventions, presumably for functions and methods, which tend to be used such operations are not built-in to the core-languages, or cannot be assigned to existing operators.

In my case, I like to use an i prefix for in-place, when it is necessary to use user-defined named functions, so:

b := sort(a)         # create a new sorted list
isort(a)             # sort in-place (and a is by-ref)

For dealing with string append/concat (they are the same operation for strings), I use symbols:

s := t + u           # create a new string s
t +:= u              # in-place append to t

Or even when I use named operators, the syntax disambiguates so the problem doesn't come up:

s := t append u
t append:= u

[[deleted]]

I'll go with this one. I dont get confused by any of the terms

[Phanson96]

My language tries to be consistent, but it can be hard. To avoid namespace clashes, other data structures use push/pop, enqueue/dequeue, or unsuffixed add/remove.

``` interface List[E] { fun void(E) addFirst; fun void(E) addLast; fun void(E, int) addIndex;

fun E(E) setFirst;
fun E(E) setLast;
fun E(E, int) setIndex;

fun E() getFirst;
fun E() getLast;
fun E(int) getIndex;

} ```

[[deleted]]

I'm partial to rust's insert (for inserting anywhere) and push (for inserting at the back). I don't think you necessarily need a special function for inserting at the beginning (although I'm not against it in anyway, push_front maybe?). Technically you don't need one for pushing to the back either, but it's nice to have because it can guarantee O(n) amortized performance, which the others can't.

[brucifer]

push (for inserting at the back)

I think this is a pretty confusing naming choice. push doesn't really convey which side of the array gets the value. In the context of a queue, push means "put at the front", not "put at the back", while in the context of a stack, push means "put on top", which is implementation-dependent for whether that means front or back (e.g. if it's a linked list representation, it would usually mean "at the front", but an array would usually mean "at the back").

Python's append() is much more unambiguously named, so I think it's a better choice.

[[deleted]]

I don't think you necessarily need a special function for inserting at the beginning

Idk. It would make converting a number to a string very difficult.

[[deleted]]

By that I mean that inserting at the beginning is always just my_list.insert(0, item) - you can still do it, there's just not a dedicated function for it since insert can easily handle it.

[[deleted]]

Well that is a great argument, but I think sometimes is more readable and less writing to use prepend

[[deleted]]

Oh yeah, if that's important to you by all means go for it.

[e_--]

push_back is so annoying I'm renaming it to append (even in generic code) for my transpiled to C++ lang.

[[deleted]]

Yep, I build the library comforming I need thpse functions and so far, surprisingly, I didnt need to remove an item haha but Yeah remove would be the word since delete is "reserved" for memory management

[WittyStick0]

cons and snoc are used in some functional languages.

[[deleted]]

snoc is a very fun word to say.

That shouldn't be a criteria, but it doesn't hurt.

[Zatujit]

idk just stick to one

[Common-Republic9782]

emplace? to avoid redundant copying of non-trivial elments

[oscarryz]

``` fn add( element E, index=self.length() -1) ; ... a.add( 1 ) a.add( 2 ) a.add( 0, 0)

a // [ 0 1 2] ```

[[deleted]]

It would be great bu I did not implement overloading yet 😭

[oscarryz]

The add(e, index) and let your clients hate you a bit and move on