On Wed, Aug 20, 2008 at 00:54, Tony Balinski <[EMAIL PROTECTED]> wrote:
> Quoting Bert Wesarg <[EMAIL PROTECTED]>:
>
>> >
>> > I've been playing in parse.y, implemented (both)
>> > for ([k] = v in array) { ... }
>> > and
>> > for (v = [k] in array) { ... }
>> I saw this too (see below). But I don't see a benefit for both
>> syntaxes. I fixed today my extended for-array patches [2]:
>>
>> The problem was, that I like to have the ability to iterate only over
>> n-dimensional keys.
>> So the simple [k]=v was not possible anymore (because the case for
>> N==1 was missing), and the simple k=v didn't work, because the parser
>> bails now out by the 'normal' for (i=0;;) loop. And my previous
>> solution with k:v looks nasty. So, I fixed this by a big look ahead
>> function for the '=' sign ('= SYMBOL IN'). A new feature is the
>> k[0]=v/k[]=v syntax, for all keys, but nicely split-up and put into
>> the k array.
>>
>> Here is all in one rush:
>> for (k in a) .. # all keys assigned to k
>> for (k = v in a) .. # -"- with v := a[k]
>> for ([k1,..,kN] in a) .. # all N-dim keys assigned to k1,..,kN
>> for ([k1,..,kN] = v in a) .. # -"- with v := a[k1,..,kN]
>> for (k[N] in a) .. # all N-dim keys assigned to k[0],..,k[N-1]
>> # N == 0 => all keys, same as missing N
>> (i.e. 'k[] in a')
>> for (k[N] = v in a) .. # -"- with v := a[join(k, $array_sep)]
>
> I don't really like the syntax of the last one - it seems less obvious than
> when the key(s) is/are in the brackets. Hmmm. Does N provide a placeholder
> for the key array's dimension, or an upper limit on its size?
No, this loop will only iterate over keys with exactly N dimensions.
Not more, not less, so possibly an empty loop.
>
> Honestly, though, since there's nothing to stop you using keys of different
> dimension in the same array, I didn't trouble myself with key-string
> breakdown. I almost never use multi-dimension keys anyway, although I used
> nested ones all the time. So I'm content with
> for ([k] = v in a) {
> kdims = split(k, $array_sep) # decompose to one array or ...
> ( k0, k1, k2 ) = split($array_sep k, $array_sep) # ... to variables
> ...
> }
> In your scheme, what happens when there are more/less dimensions than you
> provide placeholders for?
As I sad, if you provide N placeholders (either with [k1, .., kN] or
with k[N]) than this loop will only iterate over keys with dimension
N. If there are no keys with this dimension, this loop will never
execute the body. keys with other dimension will be simply skipped.
> And what do you use multidim keys for anyway?
Honestly, I don't use multi dim keys. I just think that this is a
valuable syntax addition for the multi-dim key feature.
>
>> > meaning the same thing, and similarly
>> > if (v = [k] in array) { ... }
>> true if array[k] == v, right?
>
> no - it means
> if ([k] in array) { v = array[k]; ... }
Ahh, ok. Maybe this would be a nice addition:
if ([k] == v in array) { ... }
would be the same as:
if (([k] in array) && (array[k] == v)) { ... }
But I can't see a value for this right now ;-)
>> > if ([k] ! in in array) { ... }
>> true if k is not a key in array, right?
> indeed (though I see there are two "in"s there - should be only one.
>
> BTW, you also get (.key = v in array) doing the same value retrieval; this
> is identical to (v = ["key"] in array)...
>
>> Both sounds reasonable, except my previous concern about v=[k].
>
> Like you I prefer putting the value placeholder after the "=", to match the
> anonymous array syntax.
Than why do have this syntax in the first place?
>
>> > ex-or (^^) and conditional (?:) operators; and adding parser location
>> > information so you can go from an instruction to a position in a source
>> > code string. I'd like to get it to the point of being able to provide
>> > a debugging service.
>
> (and integer signed bit-shifts, and array compares!)
Yeah, I saw this too (at least the shift ops) ;-)
>
>> Ahh, thats these CALL_TAG/LINK_TAG tags in your code at [1]. I just
>> 'discovered' this last week. I just started coding with Nedit again.
>
> I get the feeling I'm being watched ;-)
Isn't this, what FOSS is all about ;-)
>
> I was concentrating there on limiting stack frame management to two
> functions: callSubroutineFromSymbol() and returnValOrNone(). I thought
> it would be good to cut down on the number of link/argument entries
> required on the stack, since they are big enough to hold more than one
> pointer. They don't really need new ..._TAG type values though, since
> we should know where they are! It's just easier for stack dumping code.
>
> Anyway the program location code is driven by parse.y - not sure it's in
> the tarball you mention - time to put a new one up.
Ok, thanks for the pointer.
>
>> > But building patch files for each of these and combining with the
>> > others is turning into a real can of worms!
>> Sounds like its time to change your tools ;-)
>
> I'm not sure that would help since my intention was to provide "single
> functionality patches" which would always apply to the code base, and
> combine with intermediate ones to get the assemblage I want (as you've
> seen in the past). The accumulation of changes is really too much.
"my intention was to provide", if this isn't your intention anymore,
you know you don't need to stick at this.
Bert
>> [2] http://kgb.endoftheinternet.org/git/nedit-bw/
>> but its currently down :(
> Yes, sadly... can I get it anywhere else?
Just a note what that is: there is a file called series, its the order
of the patches.
The patches you may looking for are these:
extend-if-key-in-array-syntax.patch
extend-for-key-in-array-syntax.patch
multi-dim-key-iterator.patch
multi-dim-key-iterator-arr.patch
--
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop
