hi,
can you explain why: random(allocate(3,9)[*]); or random(({9,9,9})[*]); don't work,
while array foo = allocate(3,9); random(foo[*]); does?
greetings, martin.
Mostly any question about why automap does not work in some particular context can be explained by automap being a play construct no core dev feels for enough to make it a well-integrated core language feature.
really?
now that would be sad. automap is one of the nicest recent improvements to pike. it sometimes helps me reduce my code to half the size.
so, core devs: we all love automap! please integrate it better!
greetings, martin.
Just to register the opposite opinion: Automap has the possibility to turn all Pike programs into something as unreadable as Perl. It should not be used casually.
it's not that bad. it is not any less readable than using operators for array or string manipulation. good use of operators can make pike code quite unreadable to the unsuspecting eye already.
the difference is the number of operators to choose from and the big number of syntax variations in perl. pike has very few syntax variations.
besides, what makes perl really unreadable is its hidden default variables and cryptic special variables that change the behaviour. pike does not have any of that.
automap can also enhance readability if used wisely.
automap should either work correctly everywhere, or not at all, instead of the current guesswork, where it sometimes works and sometimes not.
greetings, martin.
The main issue I have with automap is that the limits of the automapping are implicit. I can write
a[*] + 1
and
a[*] + b[*]
and it works as expected, but when I try
a[*] + b[*] + 1
it suddenly breaks since the "+ 1" part is outside the implicit limits of the automap. The limits are what they are just because the abstract syntax tree happen to be built a certain way. That is icky. They should be stated explicitly with a special syntax. When this dubious feature was discussed way back in the internal lyskom at RIS, I suggested
(a[*] + b[*] + x)[/]
where the idea behind "[/]" was that it looked somewhat like the inverse of "[*]". It's the full expression in the parenthesis before it that is automapped. No more, no less. So if x shouldn't be added to each element but instead be added to the end of the result array, it'd be
(a[*] + b[*])[/] + x
IIRC, this idea was turned down because it caused a bit more bulky syntax in the simplest cases, and because implementing it would require a considerably more complicated solution. Now it might be difficult to amend this for compatibility reasons.
Your idea wasn't exactly turned down. Automap was implemented differently because I saw an oppertunety to make a simple implementation based on function calls rather than implementing a new loop construct into the interpreter.
`+(a[*],b[*],1) should work though.
rereading this now, what does
(a[*] + b[*])[/] + x
do, that you can't just do with:
(a[*] + b[*]) + ({ x }) or (a[*] + b[*]) + x
greetings, martin.
With that proposal, you'd write
(a[*] + b[*])[/] + x
to do what
(a[*] + b[*]) + x
does now. The "[/]" thing wouldn't be optional.
that makes no sense.
(a[*] + b[*])
returns an array, and even with the existance of [/] then the behaviour of
(a[*] + b[*]) + x
must not change.
(a[*] + b[*])[/] + x
may only provide something additional.
greetings, martin.
You seem to think I was talking about a new extension to the automap feature. I wasn't, I was reiterating a proposal for a different implementation that I did at the time the automap feature was about to be implemented.
well, i was aware that you were not talking about a new proposal, but you are right i missed that there would be no need for compatibility, however just out of curiosity,
if
(a[*] + b[*])[/]
is needed to get an array as result what is the result of the part:
(a[*] + b[*])
that [/] is applied on?
greetings, martin.
The idea was that any [*] expression must be matched by a surrounding [/] so that there's no ambiguity about which part of the expression is getting mapped. So leaving out the [/] would be a syntactic error just like leaving out e.g. a closing paren.
As for "[/]" I don't think it's particularly good really; I just couldn't think of anything better. If there were any unused paren chars I'd suggested using them instead of ordinary parens.
pike-devel@lists.lysator.liu.se
-
Fredrik (Naranek) Hubinette (pappa) ＠ Pike (-) developers forum -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Bähr
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum