> Is it possible to solve this? Yes, of course -- it's just software after > all. But does it make the system substantially more complicated for what > amounts to syntactic sugar? Yes, again. And by the way: yes, you > can envision ways to tell lies to get this to work (e.g., by putting > each potential execution in its own clause with an appropriate > predicate), but again, it's complicated and (like many lies), the truth > will leak which will require patches of yet more lies.
Yes, and so the question is whether or not the 'lies' (I prefer compiler directives/features ;-)) are worth the effort, in the sense that they promote end-user efficiency. And a simple pragma that tells a predicate how many bytes to return is not all that onerous from a end-user's point of view. (and from a dtrace-programming perspective I would guess, too, if done correctly, ie: not too fancy) So I put it to you that they are worth it, simply because the 'lies' as you say allow for first party, and third party pluggable modules for dtrace, *written in dtrace*. This last point IMO is a big deal. Yes, you can have code generation GUIs that generate d scripts, and I suppose you could have a language on top of d which generates an underlying d script (d with conditionals), but those are far bigger lies from the end-user's point of view - what you lose in the process is both simplicity and clarity. I'd love to be able to program reusable objects for d - it increases the bang for my programming buck, and the GUI/uber-d approach is bad in the long run because it locks people into third party solutions (including their own), leads to read-only scripts (have you ever tweaked outputted code, only to find that that tweak makes it into production?), and in general is a *bad thing*. So limiting this stunts what could otherwise be a great win for consumers of your product, and a community that could write modules for you. And it limits how user friendly dtrace could be. Just MO. Paul -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list [email protected]
