It's important to start by remembering that expl3 is a language ultimately written in TeX primitives, which means it is a a macro expansion language. Whilst expl3 provides various abstractions and as far as possible is intended to be understood/documented 'on its own terms', that is not yet complete and there is sometimes a need to know some 'raw' TeX. That's particularly true where there are still things to be worked out, and complex data structures are such an area.
In terms of variable scope, TeX and thus expl3 works on the basis of explicit begin/end group markers
\tl_set:Nn \l_tmpa_tl { abc } \tl_gset:Nn \g_tmpa_tl { abc } \group_begin: \tl_set:Nn \l_tmpa_tl { 123 } \tl_gset:Nn \g_tmpa_tl { 123 } \group_end: \tl_show:N \l_tmpa_tl % abc \tl_show:N \g_tmpa_tl % 123
The difference in naming here is one of convention (e.g. \tl_gset:Nn \l_tmpa_tl will work, at least unless extra checking is set up). The reason for the convention is that TeX has to keep a track of local values for variables, and mixing local/global freely will lead to save-stack exhaustion ('bad news'). The approach that variables are set only locally or only globally helps to avoid that.
Note that \tl_new:N and so forth globally allocate the name even if for local variables. The team did explore alternative approaches in which variables can be declared locally, but these seemed to work poorly with the fact that TeX scoping is based on explicit groups.
Before tackling the requested 'function translation', it's worth noting what relevant data structures are currently available. The most basic data structure is the token list (tl): a load of tokens with no defined internals at all (TeX and so expl3 deals with tokens). We do have a string data type, which is a special form of the tl in which all characters are 'other' except spaces which are still normal spaces. It's not clear, but I don't think you actually want a TeX string.
Building on the tl we have sequences (seq) and property lists (prop). A seq is an ordered data type which is good for mapping but can also be accessed numerically (indexing from 1 for reasons that would be best I think in a separate question). A prop is a key-value data structure without any defined key order. Thus at present there is no 'array' in a general sense. To understand some of this requires some insight into implementation but also into why they've been implemented.
At present, both seq and prop structures are constructed with the data contained within a single tl. This is partly for historical reasons (TeX systems in the past were much more limited in terms of csnames than they are today), but partly as this approach makes certain use cases easier. Copying a single tl is easy (a one-step process) and it is trivial to implement mappings. On the other hand, this approach makes random access somewhat slower, particularly when expandable. As detailed in How to implement (low-level) arrays in TeX, the fastest approach to making an array-like structure in TeX is to use a series of names and rely on the hash table for access. That though makes operations such as mapping harder, and also ultimately may make it more likely that name storage will be exhausted.
The team have had various discussions and attempts focussed on creating new data types. However, these have not progressed as we are mindful of the need to cover some extensible form (for example, nesting arrays in arrays, etc.). At the same time, the current data formats are there as they have concrete use cases for the team. Use cases for TeX/typesetting are what is important here. (One can implement all sorts of things in TeX but that does not necessarily make it a good idea!) The net result of this is that at present there is not a single 'array' data structure that does everything which might be wanted.
As indicated by the other answers, there are various formulations one might use to implement the request. It's not clear for example exactly what other uses the data is for, whether expandability is required, whether the lists may be large (performance considerations), etc. One possible approach is
\documentclass{article} \usepackage{expl3} \begin{document} \ExplSyntaxOn \seq_new:N \l__bob_tmp_seq \int_new:N \l__bob_tmp_int \cs_new_protected:Npn \bob_print:nn #1#2 { \group_begin: \seq_set_split:Nnn \l__bob_tmp_seq { \n } {#1} \int_zero:N \l__bob_tmp_int \seq_map_inline:Nn \l__bob_tmp_seq { \int_incr:N \l__bob_tmp_int \int_compare:nNnT \l__bob_tmp_int > {#2} { \seq_map_break: } ##1 \c_space_tl \tl_use:N \l__bob_tmp_tl \par } \group_end: } \bob_print:nn { a \n b \n c \n d \n e } { 3 } \ExplSyntaxOff \end{document}
whilst others (particularly faster ones) would feature a hash table based appraoch (at the cost of being very much low-level TeX 'dressed up'). In the above, I've used a mapping rather than \seq_item:Nn (index loop-up) for performance reasons. The latter approach has to read through the sequence at each step (at least with the current implementation) so will be poor for long sequences. On the other hand, the mapping approach already has the items available with a fast int operation keeping track of position. (Using a hash table array we can do direct access quickly.)
k > count. you meank < count, right?