Re: Ideas for next Eu
On Wed, 10 Nov 1999 16:31:33 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>On Wed, 10 Nov 1999, Lewis Townsend wrote:
>
>> Yes, that is a good ideah too. In fact I hope that this syntax
>> is implemented before subscripting functions. However I don't
>> think this is a complete workaround for subsciption. The point
>> of which is to throw out anything that you don't need. While I'm
>> on the subject here's some more subscription ideas I would like:
>>
>> object x
>> x = {{1,2},{3,4},{5,6}}
>> ? x [1..3][2] -- HERE'S THE TRICK
>> -- output: {2,4,6}
>
>This (I call it "vertical" slicing) would be very handy in any number of
>places, especially when dealing with business programs. Anything from
>extracting a sequence of names from a name, address, phone # list,
>searching columns for certain values, or doing math on whole columns of figures
>(!) would be simplified.
>
>> object x
>> x = {9,8,7,6}
>> ? x [1,3]
>> -- output: {9,7}
>
>Very handy, especially if find() or match() would return a sequence of
>matching
>items from a list:
>{1,3,12,55} , say, would mean the matching data was found in
>record 1,3,12 and 55. Which you could then proceed to extract into a new
>sequence : matchingitems = masterlist[{1,3,12,55}]
>In conjunction with "vertical" sliceing, this could be extremely powerful.
>matchingnames = masterlist[{1,3,12,55}][NAME]
In common parlance, those two functions would be called findall and
matchall. In the SPF and Rexx editors in the IBM world, these
functions lend themselves to a technique so useful for code
correction, that I have sought it in every editor since then and not
found it. Specifically the TSO/SPF editor allows line numbering to be
turned on and off. It can be used for editing without saving it. In line "1"
in the number field, I can type x99999, which means exclude from here
the next 99999 lines from the display. In this case, that means all
lines. Then, you do something that is of the following form:
find all "xyz" from line 1 to 9999 and column 1 to 80 searching only
excluded lines
which translates to something like
fa 1 99999 1 80 "xyz" x
This little jewel then displays only the lines that contain the found
text that are currently excluded. Now, instead of seeing the whole
blankety-blank program with the field highlighted, I get to see only
the lines that contain the sought object. With a little adjustment to
options or preferences, I can see the line before and after the
occurrence with the found line. In SPF, there was a line in between
found items with the number of lines still excluded between the
found items. I hope that somebody besides me can see the utility of
that kind of thing for doing program changes or corrections. Most
people using the SPF editor had never thought of the technique,
even though there was one example in the manual with it. They
never "got" it. To make a long story short, Your extended find()
or match() function with the vertical slice sequence would allow this
very powerful form of editing. If somebody else doesn't do it, I
will.
>
>> Of course I would like these to work in combination and on
>> functions as well. I know it's asking a lot but it makes
>> sense to me.
>
>A lot of sense. Most of this seems do-able. I'm not sure how difficult it would
>be to subscript functions, or what side effects it would cause, but there are a
>lot of places it would be very useful.
>
>>There seem to be mixed feelings about indexing a function...
>> Yes
>> >(which I feel is a bit hard to follow as far as readability,
>> No (IMO)
>
>Agreed. For example, I think that date[YEAR] or perhaps date([YEAR]) or
>maybe date.year is more useful and readable than the alternative:
>create a sequence
> sequence x
>assign
> x = date()
>extract
> ? = x[YEAR]
>
>especially if, somehow, date() _knows_ the names of its members, so you don't
>have to declare them as constants, which will sooner or later collide with
>another of your or someone else's "YEAR", "MONTH", or "DAY".
>
>Regards,
>Irv
In effect, you are asking the interpreter to do automatic selective
sub-sequencing based on arguments to a function. With proper
structure naming, this would be a lot less necessary, but still very
nice. Intuitive, too...which in my world makes it even more desirable.
Everett L.(Rett) Williams
|
Not Categorized, Please Help
|
|
