Map command works (incorrect) recursively

[evgaster]

Running the simulator on Fedora 43, DB48x version = 0.9.16

{
	"Z" 26
	{ "A" 1 }
	{ "B" 2 }
}
«Typename»
Map

Expected result:

{
	"text" "integer"
	"list"
	"list"
}

but gives:

{
 	"text" "integer"
	{ "text" "integer" }
	{ "text" "integer" }
}

Looks like Map recursively processes the elements of elements of a list.
In my view this is incorrect. Map should not recurs.

[evgaster]

The Filter command does something similar (actually that's what I stumbled upon first).

{
	"Z" 26
	{ "A" 1 }
	{ "B" 2 }
}
«Typename "integer" =»
Filter

gives:

{
	26
	{ 1 }
	{ 2 }
}

[c3d]

I see value in having commands that do not recurse. However, the HP50G MAP command does explicitly recurse, as indicated on page 3-141 of the HP50G advanced reference manual. The example there states that { 1 2 { 3 4 } } « →STR » MAP returns { "1" "2" { "3" "4" } }.

For the REDUCE command, which is called STREAM on the HP50G, a quick experiment indicates that it does not recurse on the HP50G. Experimentally, { A B C { D E { X Y } } F } « + » STREAM gives {A+B+C D E { X Y } F} For FILTER, this is a DB48x extension, so we can do what we want, and one-level filter only seems good.

I see two options:

1. Adding a flag that selects recursion.
2. Adding separate commands that recurse or not.

In any case, the documentation needs clarification.

[evgaster]

With map, reduce, filter ... my mind is in Scala / Python mode. Seems "logical" behaviour.

In the "HP 50g advanced user's reference manual" PDF I have, there is no example in the "3. Full Command and Function Reference" section for map. map is on page 3-100. Mine is "Edition 1.1","Printed Date: 2006/3/20". Picked up Edition 2. Thanks for putting me on that track. The (more recent) manual indeed has the example and mentions "recursively".

I admit, I didn't test this on my HP 50g.

I prefer non recursive behaviour, as a default, for map, filter, reduce. For map backwards compatibility seems appropriate. I prefer the flag option.