ccount@athena.mit.edu (Craig A Counterman) (02/21/90)
Emulated multidimensional arrays are not intuitive. I.e. I haven't been able to figure out how to do what I want with them. Is there any chance of making '$var[2][0] = 3; $var[2][1] = 4; print $var[2];' do the right thing? Also, since there are lists I'd also like the whole suite of Lisp functions like 'mapcar'. Actually, I think most exist under other names, e.g. it looks like 'grep' is actually 'mapcar' by another name. If this is true, could lisp-ish names also be used, or at least documented as such? And I'd like more stream input functions, like scanf or a 'get_word' function. I've written the latter easily enough as a subroutine, but still... And while I'm at it... No, nevermind. Thanks, Craig
tchrist@convex.COM (Tom Christiansen) (02/21/90)
In article <1990Feb20.225434.2045@athena.mit.edu> ccount@athena.mit.edu (Craig A Counterman) writes: |Emulated multidimensional arrays are not intuitive. I.e. I haven't |been able to figure out how to do what I want with them. Is there any |chance of making '$var[2][0] = 3; $var[2][1] = 4; print $var[2];' do |the right thing? Is that you want them to do? The problem I see with doing multi-dimensional arrays the way you've said them is growing both indices dynamically. I'll think on your example overnight and come up with a way to do that, although I imagine Larry or Randal or someone else will beat me to it. |Also, since there are lists I'd also like the whole suite of Lisp |functions like 'mapcar'. Actually, I think most exist under other |names, e.g. it looks like 'grep' is actually 'mapcar' by another name. If |this is true, could lisp-ish names also be used, or at least |documented as such? Don't we have enough reserved functions? I can see documenting how grep can be used like mapcap, but don't think alternate names are the way to go. |And I'd like more stream input functions, like scanf or a 'get_word' |function. I've written the latter easily enough as a subroutine, but |still... ICK! Why would you want a scanf() when you have perl unbelievably more powerful regular expression parsing mechanism? If you're dead-set to do this, you could probably write your own scanf. I don't think it's a good idea though. For the array thing, you may have a point, but for both the mapcar and the scanf things, it seems that you're trying to turn perl into languages that they're not. It reminds me of lisp-like alias for csh lists. --tom -- Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
schwartz@barad-dur.endor.cs.psu.edu (Scott E. Schwartz) (02/21/90)
Craig A Counterman writes: >Emulated multidimensional arrays are not intuitive. I.e. I haven't >been able to figure out how to do what I want with them. I agree, except that I want generalized associative arrays. patch 10? :-) -- Scott Schwartz schwartz@cs.psu.edu "the same idea is applied today in the use of slide rules." -- Don Knuth
flee@shire.cs.psu.edu (Felix Lee) (02/21/90)
Tom Christiansen <tchrist@convex.COM> wrote: >The problem I see with doing multi-dimensional arrays the way you've >said them is growing both indices dynamically. You promote lists to first-class objects and let lists contain lists: @a = (1, (2, 3), (4, 5)); And similarly with associations: %a{'rgb'} = ('red', 1, 'green', 2, 'blue', 3); Except Perl's syntax makes this a little strange. Compare $b{'rgb'} = ('red', 1, 'green', 2, 'blue', 3); It's ($a{'rgb'}{'red'} == 1), but ($b{'rgb'}[1] == 1). At least, that's what I think. Perl's use of % $ and @ is pretty bizarre. And associations really shouldn't get confused with lists. Non-trivial change to Perl. Version 4? -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (02/22/90)
In article <1990Feb20.225434.2045@athena.mit.edu> ccount@athena.mit.edu (Craig A Counterman) writes:
: Emulated multidimensional arrays are not intuitive. I.e. I haven't
: been able to figure out how to do what I want with them. Is there any
: chance of making '$var[2][0] = 3; $var[2][1] = 4; print $var[2];' do
: the right thing?
What's the right thing? What should be the value of $var[2]? "34"? "3 4"?
Where did that space come from? What if one element had the value "the time"
and the other element had the value "is now"?
What is the interpretation of any of these?
@foo = @var
@foo[0..$#var] = @var[0..$#var]
print @var;
$var[2] = "the time is now";
It's can-of-worms time...
: Also, since there are lists I'd also like the whole suite of Lisp
: functions like 'mapcar'. Actually, I think most exist under other
: names, e.g. it looks like 'grep' is actually 'mapcar' by another name. If
: this is true, could lisp-ish names also be used, or at least
: documented as such?
Hmm. Usually people want me to turn perl into apl...
You could certainly say something like
#!/usr/bin/perl -P
#define mapcar grep
: And I'd like more stream input functions, like scanf or a 'get_word'
: function. I've written the latter easily enough as a subroutine, but
: still...
I detest and abhor scanf. I always have.
However, you should know that I'm strongly considering letting you do
pattern matching against the input symbol:
<STDIN> =~ /^pattern/;
If you do this currently it will just read one line and pattern match on
it. I'm considering making it read any extra lines it needs to satisfy the
pattern match. Except that this could break existing scripts...
Larryccount@athena.mit.edu (Craig A Counterman) (02/22/90)
In article <7125@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >It's can-of-worms time... Ok, so the answer is 'NO'. I can live with that. Actually, I know the dimensions of the array before I start using it, so I can use a 1d array and calculate the subscript, e.g. vvals[$i*$nvars+$j]. But I wish for some syntactic sugar. > >You could certainly say something like > >#!/usr/bin/perl -P >#define mapcar grep Well, grep isn't identical to mapcar, but I think it can be used for that functionality. > >: And I'd like more stream input functions, like scanf or a 'get_word' >: function. I've written the latter easily enough as a subroutine, but >: still... > >I detest and abhor scanf. I always have. I don't disagree, but I do need it from time to time. > >However, you should know that I'm strongly considering letting you do >pattern matching against the input symbol: > > <STDIN> =~ /^pattern/; > >If you do this currently it will just read one line and pattern match on >it. I'm considering making it read any extra lines it needs to satisfy the >pattern match. Except that this could break existing scripts... > YES, that's exactly what I wish for. Skip the file till a keyword is found, then do something to the contents till another is found, etc. >Larry I really look forward to a BOOK I can sit down with and pick up all the idioms. But I'll get the hang of it soon. perl does seem to fill a niche for me. Thanks for the language/program. Craig