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?
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? And what do you use multidim keys for anyway?
> > 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]; ... }
> > 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.
> > 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!)
> 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 ;-)
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.
> > 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.
> > We need the next release and a new branch!
> ACK.
>
> Good Night
> Bert
>
> [1] http://ajbj.free.fr/nedit/neditHome/neditHome-2008-08-04.tar.gz
> [2] http://kgb.endoftheinternet.org/git/nedit-bw/
> but its currently down :(
Yes, sadly... can I get it anywhere else?
Anyway, sleep well,
Tony
--
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop
