V: Flexible array Base

Created on 30 Dec 2019  路  6Comments  路  Source: vlang/v

There are mostly 2 kind of programming language, those using arrays with 0 as base as c, c# kotlin etc (ranging from 0..n-1 for n objects in each dimension) and those that doesn't use 0 as array Base, such Fortran Julia (1..n) , while it may look trivial, is not since adds another source of bugs as you migrate code/algorithm from those language with 0 as base it 1 as base, this is very an issue working with numerical analisys algorithm as most mathematician code algorithm using 1 as base for array origin, if course it has deep implications at every instruction looking or storing data in arrays which also should be updated.

My proposal it to declare arrays by default with 0 as Base, but also enable an alternative array declaration with specific ranges at each dimension.

Like this

//default as currently implemented:

mut nums0to9 := [0,1,2,3,4,5,6,7,8,9]
n := 10
println( nums0to9[0] )// 0
println( nums0to9[n-1] )// 9

// arbitrary base as proposed by

mut nums1to10 := [1,2,3,4,5,6,7,8,9,10] base 1
println( nums1to10[0] )// error
println( nums1to10[1] )// 1
println( nums1to10[n-1] )// 9
println( nums1to10[n] )// 10

// M煤ltiple dimensions

mut nums3x3square := [ [1,2,3], [4,5,6], [7,8,9] ] base 1,1

println( nums3x3square[1,1] )// 1
println( nums3x3square[2,2] )// 5
println( nums3x3square[3,3] )// 9

Feature Request

Most helpful comment

But would not you in that way get the bugs from both cases, as well as some additional ones (where you switch between the 0 and 1 array bases)???

All 6 comments

But would not you in that way get the bugs from both cases, as well as some additional ones (where you switch between the 0 and 1 array bases)???

Zero based indexing is an important issue for people that is not used to it.

But we can not mess V.

How about a parallel set of methods incorporated in the built in vlib? Bad idea?

For example, we have:

pub fn (a mut array) delete(i int) { ...

Could we also have this?:

pub fn (a mut array) one_base_delete(i int) { ... // verbose but clear

Or this?:

pub fn (a mut array) delete1(i int) { ... // not verbose, but not so clear

I think it won't mess V as long is carefully implemented, as base 1 array are just base 0 array called with index-1, if someone here ever tried to migrate some algorithm coded in Fortran knows the hell it is, as often the alternative is to grow dimension by 1 and assume the unexpected inherited corruption risk by referencing 0 indexing and memory inefficiency (at least while debugging)

Accidentally closed

My suggestion of a parallel library is very far from perfect.
It is just a verbose workaround.
Its upside is that is easy to implement: just expand the library; not change the language.
Whoever is comfortable with zero based arrays might completely ignore that methods.

The downside is

arr[1]

would continue to give the second element,

so we would have to write

arr[n-1]

or write something like

arr.one_base_get_at(n)

which is not nice.


Another idea is put a flag on top of the file like:

__one_base_arrays // a bit ugly I know

and nothing more is needed to write the whole program with one base arrays.

Of course, compiler would not compile when some source file has the flag and other doesn't.

I don't know if is just a case of adapt the code of the current libraries to this flag or if it has deeper implications in the compiler.

I don't know if it would create bugs when importing third party modules or not.

What I like in this idea is

  1. the simplicity of the design
  2. no chance to create one array with base zero and other with base one (in same program)

If the only motivation is migration of existing code bases, then I'd definitely choose a non-manual method (nowadays pretty common is to do transpilation - I saw e.g. Fortran to C++ quite efficient transpiler). So I think there is no real need for such functionality in V.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

medvednikov picture medvednikov  路  3Comments

radare picture radare  路  3Comments

arg2das picture arg2das  路  3Comments

lobotony picture lobotony  路  3Comments

shouji-kazuo picture shouji-kazuo  路  3Comments