Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

Why should it be strictly defined? Why tie your hands so thoroughly?

There really isn't some one compelling argument on either side.

There are advantages to defining the order of things and advantages to leaving the order of things unspecified. Your question really boils down to "Why don't we define the order of everything?". And I think it doesn't take much contemplation to realize that the middle ground is the place to be.

Perl goes futher than C in defining the order of some things. There is advantage in knowning that ( foo(), bar() )[-1] will call foo() before it calls bar(). It allows you to express some complex instructions in concise ways (which is a very Perlish thing to allow).

A similar expression in C might call the functions in either order, depending on the implementation. There is good reason for this. C runs on systems were the low-level calling conventions specified that you pushed the first argument first (and where C wanted to use the same conventions to ease interoperability with the non-C routines on such systems) but C also runs on systems that take good advantage of pushing the first argument last (which allows you to pass in extra arguments with little impact). Overspecifying such things could mean slower code on some system (having to compute the values in one order and then push them onto the stack in the reverse order) that was also more complicated and more likely to be buggy.

To go all the way in one direction would require writing up all of the details of exactly how order is determined and require a lot of work to figure out all of the bugs in this specification and the implementation. It just isn't worth the small gain of being able to define exactly how things happen even if you write something that most people won't have a good feel for exactly in what order it should be evaluated.

Leaving some things unspecified gives you the freedom to re-implement things in a way that makes more sense, is more efficient, or to just not have to sweat so dang much when making a trivial change because it might have some subtle effect of the order of evaluation of some convoluted expression that noone should have to bother to figure out exactly what order it should be evaluated in.

You define what it makes sense to nail down and give warning that the rest may or may not change because the work hasn't been done to define exactly how it must stay the same and there may be a real benefit to changing it some day (like the real benefit of recently making the order of hash keys vary between runs of the same Perl script).

A major goal of Perl 6 is to support code optimization. If you over-specify the order of evaluation, then you lose the ability to perform some optimizations. You can't move opcodes around to take advantage of efficient ways of combining certain things.

The reason that sometimes the fact that some orders are not defined is so pointedly noted is that people have a tendency to assume that once they figure out X, that X will always be true. You can see it happening with the expression you posted. Some people have already convinced themselves that they know exactly what order things are done and why and even say things like "It must be this way to allow ..." and then they go and write code that breaks if things aren't exactly the way they think they must be (I'm not saying that ikegami writes such code, just that ikegami has demonstrated the first step or two along that path to doom).

And that scenario is worse than having the order exactly specified, because you have different groups tying peoples' hands in different ways for no benefit. So it is important to at least occasionally beat people up and remind them that some things are not defined and if they depend on them being one particular way, the fact that it works for them now doesn't mean it will always work.

- tye        


In reply to Re: Why is the execution order of subexpressions undefined? (why not?) by tye
in thread Why is the execution order of subexpressions undefined? by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (5)
As of 2024-03-28 14:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found