I see, so

"if ($x{$key1}[$i][$j]{$key2} eq $y{$key3}[$k][$l]{$key4})"

"if ($x{$key1}->[$i]->[$j]->{$key2} eq $y{$key3}->[$k]->[$l]->{$key4})"

in Jmol would be:

if ( (((x[key1])[i])[j])[key2] == ...

and that is a pain because of all the parens. You would like this to read:

if ( x[key1]..[i]..[j]..[key2] == ...

or even:

if ( x[key1].[i].[j].[key2] == ...

No reason we couldn't do that.

Bob


On Fri, Mar 27, 2015 at 7:00 PM, Rolf Huehne <rhue...@fli-leibniz.de> wrote:

> Am 27.03.15 um 21:52 schrieb Robert Hanson:
> > Interesting idea. Rolf. Are you aware of Jmol's recently added ..
> notation?
> >
> > x = {"a": {"1": ["x", "y", "z"], "2": ["I", "II"]}}
> >
> > print x
> > print x..a
> > print x..a..1
> > print x..a..1..2
> >
> > Does that satisfy your needs? It is only for regular arrays or
> > associative arrays with simple keys. You can't do this:
> >
> Usually my hash keys are contained in variables. And as far as I know
> the '..' notation doesn't work with variables.
>
> >
> > Personally, I would not like to try to build Perl-like syntax into Jmol.
> > Overall it is very unlike C++ or Java or JavaScript, and I've tried to
> > keep as close to those as possible. In Perl I believe the -> notation is
> > for /array references:/
> >
> >      my @array = (1, 2, 3, 'four');
> >      my $reference = \@array;
> >      print $reference->[0];
> >
> > not actual array names, right? You can't do this:
> >
> >      my @array = (1, 2, 3, 'four');
> >      print $array->[0];
> >
> > right? So I would prefer not to add that confusion to the mix.
> >
> Bob, you are right, the '->' is for references. Although it is not
> limited to array references. So with variable names it can only be used
> at the second level or higher. But I wasn't suggesting to change that
> within Jmol.
>
> > Ambiguity of ranges: It's not that there is any ambiguity. I assure you
> > that is not the case. But Jmol's notation is a bit idiosyncratic, I
> > admit. The fact that the first model in a file was always "1" led me to
> > develop 1 as the base for array elements. Was it a good choice? Maybe
> > not. But that's what we have. And the fact that we often want the last
> > model suggested then that [0] could mean "the last" rather than "the
> > first". And so we have ranges such as a[3][-3]. It's not ambiguous. But
> > it is multipurpose. So, as you point out, for associative arrays,
> > a[1][1] is not a range. (What would a "range" in an associative array
> > mean, after all.) It must  be that "1" is a key in a, and that key
> > refers to either another associative array with a "1" key or a serial
> > array with at least one element. (Maybe that's what you mean by
> > "ambiguous".  That's true.)
> >
> What I mean by "ambiguous" is that you don't know at first sight what an
> expression like "x[1][3]" will actually mean. You have to analyze
> carefully what is contained within "x". The '->' notation would change
> that. For Jmol it will hopefully be always clear. But for someone
> looking at foreign or own older code it might take some more time to
> fully understand it.
>
> What I really like with the '->' notation is that it makes working with
> multi-level data structures in Perl much more efficient for me (saving
> development and debug time).
> See for example the following expressions:
>
> "if ($x{$key1}[$i][$j]{$key2} eq $y{$key3}[$k][$l]{$key4})"
>
> "if ($x{$key1}->[$i]->[$j]->{$key2} eq $y{$key3}->[$k]->[$l]->{$key4})"
>
> Regards,
> Rolf
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to