List indexing problems

[TravisE]

I'm encountering a lot more trouble with list subscripting than it feels I should for such a basic operation.

Code:


LOCAL a:={1,2,3};
a(1);   // returns 1
a[1];   // returns 2

But:

Code:


{1,2,3}(1);   // → {1,2,3}
{1,2,3}[1];   // → {[1],[2],[3]} (?!)
{"a","b","c"}(2);   // Error: Bad argument type

And, most importantly to me at the moment:

Code:


LOCAL a:={{"A",1,2},{"B",3,4}};
EXECON("&1(1)",a);   // Expected: retrieve a list of first elements in each sublist
   // Actual result: “Error: Bad argument type”
   // Same result if [ ] are used instead of ( )

Someone please tell me there's an alternative function or syntax for list indexing that works reliably.…

[Didier Lachieze]

(10-01-2016 05:16 AM)TravisE Wrote:  But:

Code:


{1,2,3}(1);   // → {1,2,3}
{1,2,3}[1];   // → {[1],[2],[3]} (?!)
{"a","b","c"}(2);   // Error: Bad argument type

Here the issue comes from the implicit multiplication as {1,2,3}(1) is interpreted as {1,2,3}*(1) and not as "take the first element of {1,2,3}".

(10-01-2016 05:16 AM)TravisE Wrote:  And, most importantly to me at the moment:

Code:


LOCAL a:={{"A",1,2},{"B",3,4}};
EXECON("&1(1)",a);   // Expected: retrieve a list of first elements in each sublist
   // Actual result: “Error: Bad argument type”
   // Same result if [ ] are used instead of ( )

Someone please tell me there's an alternative function or syntax for list indexing that works reliably.…

Instead of EXECON try with :

Code:

MAKELIST(a(I,1),I,1,SIZE(a));

[TravisE]

Thanks! MAKELIST appears to work in this situation (even though the syntax isn't quite as concise, but better than having to build a list from scratch via an ugly FOR loop).

It did appear that implied multiplication was a problem. And IMO, it seems like implied multiplication on the Prime is a bit too aggressive and keeps sticking its nose in where it isn't wanted. It's really frustrating to keep unexpectedly running into what feels like arbitrary rules and restrictions in the parser and then having to waste time attempting to code around them, instead of simply being able to concentrate on the application I'm trying to write.

[StephenG1CMZ]

(10-01-2016 09:29 PM)TravisE Wrote:  Thanks! MAKELIST appears to work in this situation (even though the syntax isn't quite as concise, but better than having to build a list from scratch via an ugly FOR loop).

It did appear that implied multiplication was a problem. And IMO, it seems like implied multiplication on the Prime is a bit too aggressive and keeps sticking its nose in where it isn't wanted. It's really frustrating to keep unexpectedly running into what feels like arbitrary rules and restrictions in the parser and then having to waste time attempting to code around them, instead of simply being able to concentrate on the application I'm trying to write.

As a programmer, I am used to typing in the * whenever needed, and would be happy to turn off implicit multiplication. But if that were a configuration option (because I know many people like it) I would then expect {1, 2,3}2 to fail to compile because of the missing *. Having to type in {1,2,3}*2 would avoid it being mistaken for a list index.
To have {1, 2,3}2 sometimes read as a list index and sometimes as a multiply depending on a configuration setting would be just too confusing.

[TravisE]

To me, {1,2,3}2 vs. {1,2,3}(2) (or {1,2,3}[2]) look like two different things. It would seem reasonable to treat a numeric expression in parentheses or square brackets directly after any list expression (explicit or as a variable) as a subscript if there is no '*' operator. Maybe there would be users expecting implied multiplication whom this would trip up, but as things are, it appears a lot easier to work around that (just type a *) than it currently is to convince the Prime parser that I want list subscripting and not implied multiplication. Except, of course, now changing anything is apt to cause compatibility issues with programs of older OS versions.

(For what it's worth, it seems that both the TI-89/89T and 50g in algebraic mode have managed to support implied multiplication without this trouble with list indexing syntax, though maybe I'm missing something in the big picture.)

I agree that despite the temptation, having an option for implied multiplication probably isn't a good idea. Just look at how much trouble the .,; separator stuff causes. And the flags on the 48/49/50 are a pain as well, especially the ones that change the effective semantics of the programming language itself (e.g., LASTARGS vs. IFERR). But I think this does reflect a possible weakness in the parser or syntax design (such as too many cases of ambiguous syntax, perhaps, or not enough provision for explicitly indicating the desired operation to the parser in such cases).

I don't know, maybe adding 49/50-style “get” and “put” functions as alternate list subscripting syntax (to use in cases where implied multiplication would otherwise get in the way) would provide an escape route without breaking the existing things too much?