vefatica wrote:
| On Wed, 15 Apr 2009 08:27:24 -0500, Steve Fábián <> wrote:
|
|| I agree with Dave's request to make @FIELD vs. @WORD type parsing
|| selectable. I'd also suggest:
|
| Under consideration.
If using two functions/commands instead of an option switch, I'd suggest
WPARSE and FPARSE. Symmetry negates need to remember which is default. First
character is more distinctive than last. (Just my personal opinion. Your
choice.)
|| 1/ Make delimiter list specification optional, as in @word/@field,
|| in the form /D"delims"; use the same default as @word and @field
Are you considering this?
|| 2/ make it both a command and a function, with the function value
|| the number of elements in the array
|
| Wouldn't @PARSE be sufficient (no command)? I considered returning
| the highest index (count - 1). Whatever behavior I settle on, it
| won't be optional.
Yes, @parse would be sufficient (just as we have @fileclose[]).
Running from low to high end of array is much more common than the frequency
of using the array size, and for this reason I prefer the uppermost index.
(Of course, in many HLLs it's the same... )
| As it stands, if the array already exists, PARSE does not try to
| create it. If it's not big enough or is not 1-dimensional this will
| lead to errors (from SET). I like the idea of re-using an array, but
| this puts the obligation on the user to ensure the array is 1-D and
| big enough for all intended purposes. Any thoughts?
Cumbersome and not likely to be very useful would be to control it using the
NoClobber option - arrays are like internal files. I see no conceptual
difference between reusing an ordinary environment variable and an array
variable when writing a program. The practicality is slightly different. If
the array variable already exists but has more than one dimension it should
be considered as one that needs to be unset before a new one is created. If
it has a single dimension, and it is reused rather than destroyed and
recreated, the first issue is undersized or oversized; the second issue is
relevant only to @FPARSE - matching empty resulting elements to the array.
All in all, it seems cheaper to just unconditionally destroy the existing
array, and define a new one.
Additional functions in the same genre are also possible. For example
@FADD/@WADD - these would perform arithmetic addition of matching elements
if both old and new are numeric (or one of them is empty), else string
concatenation. Other "vector" functions likewise. Am I making TCC into a
spreadsheet processor? Or just dreaming?
--
Steve