Proposal for a 'listlib' library

[Hated Moron]

I suspect it's related to the decision made for "range", and is all consistent with using 0-based numbering. If you write something like

Code: Select all

for x in range(10):
          <Block>

It will execute the block 10 times - but x will run from 0 to 9.

Hmm, "related to", maybe, but I don't really see how one follows from the other. Python arrays/lists are zero-index-based just like BBC BASIC arrays are, but never in BBC BASIC does one specify an index that is one greater than the end of a range, as Python slicing does.

In my experience there are two common ways of representing a range: first and last or first and count. So for example if one has a list of numbers [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] the two ways of representing the subset [4, 5, 6] would be either (in a BBC BASIC-like syntax) 4 TO 6 or 4 BY 3. Python's 4:7 is an outlier.

Range has more sophisticated forms to run between two integers, with an integer step

I referred to that earlier in the thread. I could support it with 'copied' (read-only) slices but not with 'true' (read-write) slices.

As a putative BBC BASIC listlib ought to use a BBC BASIC-like syntax as far as possible, I propose that the range be specified as first and count (which is different from, but not inconsistent with, the Python usage) so my earlier example would become:

Code: Select all

DIM parent(9)
parent() = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

PROC_listslice(parent(), child(), 3, 3)
child() = 11, 12, 13

[Hated Moron]

I've realised that another limitation of a 'true' slice is that the dot-product operator doesn't work; you would have to use the 'copied' kind of slice for that. Taking the dot-product of two 1-dimensional arrays, returning a scalar, is a rather niche requirement anyway, and it can alternatively be achieved by multiplying the arrays and using the SUM() operator, which will work with slices:

Code: Select all

scalar() = one() . two()
PRINT scalar(0)

is equivalent to:

Code: Select all

product() = one() * two()
PRINT SUM(product())

[Hated Moron]

I've abandoned the listlib library. It turns out that the attraction of Python Lists is not just their functionality (which I can substantially provide via a library) but also their elegant syntax (which I can't).

Providing the functionality but not the elegance doesn't cut the mustard, and won't attract Python users back to BBC BASIC.

If I was in the business of once again extending BBC BASIC (which for many reasons, not least my age and health, I'm not) the better solution would be to add native List functionality to the language. This wouldn't be desperately difficult, it would need two principal enabling changes:

1. A syntax for specifying a List Slice, I would suggest list(first TO last) or list(first BY count) or even both.
2. Unlocking the latent ability of a variant variable to be a string instead of a numeric, so a list can contain mixed objects.

In BBCTTY and the coded-in-C editions of BBCSDL, variant (suffixless) variables could hold strings now if there wasn't an explicit 'Type mismatch' error message to stop you doing it! This is admittedly not the case in BB4W or the assembler editions of BBCSDL.

So a prerequisite for incorporating native list functionality would be to discontinue the 32-bit x86 editions of BBC BASIC. The Windows edition(s) would be 64-bits only.

Anyway, this is for somebody else to consider once I've gone, or am too unwell to have an active interest in the language.

[hellomike]

Thanks for looking into this Richard.

Don't worry as I, for one, will firmly stick with doing all my programming using BB4W and BBCSDL.

Regards,

Mike