www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allocatoin policy in Phobos - Was: Vote for std.process

reply Manu <turkeyman gmail.com> writes:
--047d7b2e08871bee7204da296016
Content-Type: text/plain; charset=UTF-8

On 12 April 2013 21:00, Vladimir Panteleev <vladimir thecybershadow.net>wrote:

 Consider the following hypothetical decisions and outcomes:

 1. std.process is left at is. One user is angry / turned away because it
 performs 0.1% slower than it can be.

 2. std.process is rewritten to minimize allocations. Code complexity goes
 up, new improvements are challenging to add; bugs pop up and go unfixed for
 a while because fewer programmers are qualified or willing to commit the
 effort of making correct fixes. More people are angry / turned away from D
 because its standard library is buggy.

 Of course, the above is an exaggerated illustration. But would optimizing
 all code left and right really make more D users happier?

Just to be clear, I'm not arguing optimisation for performance here, I'm arguing intolerance for __unnecessary__ allocations as a policy, or at least a habit. There's a whole separate thread on the topic of fighting unnecessary garbage, and having the ability to use D with strict control over the GC and/or allocation in general. If std functions have no reason to allocate, why should they? There's also the question of priorities. Would you rather than effort is
 spent on optimizing std.process (and dealing with all the fallout from any
 such optimizations), or working on something that is acutely missing and
 hurting D?

If it's somehow hard to put a string on the stack, then there may be a hole in phobos. I'm not suggesting changes that are somehow hard to implement, or obscure in some way... they should be utterly trivial. D is a systems programming language, there is hope that it will penetrate
 a wide range of systems and environments - sure in many cases a little bit
 of memory use or performance loss is unimportant, but for many it will be
 the decisive factor which makes D unusable there.

This is surely an exaggeration. D does not attempt to please everyone out there who is choosing a programming language for their next project. There is no such language, nor can one exist. One has to accept that D has a number of goals, none of which are absolute, but merely point towards a certain, but not overly specific, point in the multidimensional matrix of trade-offs. D never was about achieving maximum performance in all possible cases.

And I never suggested we scrap phobos and rewrite it so it maximises performance at all costs. I highlighted, and suggested trivial changes that would make a big difference and don't hurt anyone. If it were habit of phobos devs to generally consider and try and avoid unnecessary allocations (almost all of which would be approached by using the stack wherever applicable), the situation would be much better in general. End-users can write D code however they want, but phobos should strive to be usable in as many types of software as possible, otherwise what good is a standard library? --047d7b2e08871bee7204da296016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 12 April 2013 21:00, Vladimir Panteleev <span dir=3D"lt= r">&lt;<a href=3D"mailto:vladimir thecybershadow.net" target=3D"_blank">vla= dimir thecybershadow.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra= "><div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3= 4,34,34)">Consider the following hypothetical decisions and outcomes:</span=
<br>

<br> 1. std.process is left at is. One user is angry / turned away because it pe= rforms 0.1% slower than it can be.<br> <br> 2. std.process is rewritten to minimize allocations. Code complexity goes u= p, new improvements are challenging to add; bugs pop up and go unfixed for = a while because fewer programmers are qualified or willing to commit the ef= fort of making correct fixes. More people are angry / turned away from D be= cause its standard library is buggy.<br> <br> Of course, the above is an exaggerated illustration. But would optimizing a= ll code left and right really make more D users happier?<br></blockquote><d= iv><br></div><div style>Just to be clear, I&#39;m not arguing optimisation = for performance here, I&#39;m arguing intolerance for __unnecessary__ alloc= ations as a policy, or at least a habit.</div> <div style>There&#39;s a whole separate thread on the topic of fighting unn= ecessary garbage, and having the ability to use D with strict control over = the GC and/or allocation in general.</div><div><br></div><div style>If std = functions have no reason to allocate, why should they?</div> <div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> There&#39;s also the question of priorities. Would you rather than effort i= s spent on optimizing std.process (and dealing with all the fallout from an= y such optimizations), or working on something that is acutely missing and = hurting D?</blockquote> <div><br></div><div style>If it&#39;s somehow hard to put a string on the s= tack, then there may be a hole in phobos. I&#39;m not suggesting changes th= at are somehow hard to implement, or obscure in some way... they should be = utterly trivial.</div> <div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> D is a systems programming language, there is hope that it will penetrate a= wide range of systems and environments - sure in many cases a little bit o= f memory use or performance loss is unimportant, but for many it will be th= e decisive factor which makes D unusable there.<br> </blockquote> <br></div> This is surely an exaggeration.<br> <br> D does not attempt to please everyone out there who is choosing a programmi= ng language for their next project. There is no such language, nor can one = exist. One has to accept that D has a number of goals, none of which are ab= solute, but merely point towards a certain, but not overly specific, point = in the multidimensional matrix of trade-offs. D never was about achieving m= aximum performance in all possible cases.<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>And I never s= uggested we scrap phobos and rewrite it so it maximises performance at all = costs. I highlighted, and suggested trivial changes that would make a big d= ifference and don&#39;t hurt anyone. If it were habit of phobos devs to gen= erally consider and try and avoid unnecessary allocations (almost all of wh= ich would be approached by using the stack wherever applicable), the situat= ion would be much better in general. End-users can write D code however the= y want, but phobos should strive to be usable in as many types of software = as possible, otherwise what good is a standard library?</div> </div> --047d7b2e08871bee7204da296016--
Apr 12 2013
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 12 April 2013 at 12:52:39 UTC, Manu wrote:
 If it's somehow hard to put a string on the stack, then there 
 may be a hole
 in phobos. I'm not suggesting changes that are somehow hard to 
 implement,
 or obscure in some way... they should be utterly trivial.

Well, ironically or not, it is not something utterly trivial. The main issue is that the stack can't hold a lot of data. This is not a problem with the heap, which is limited by the amount of memory and address space; these (usually abundant) limits are usually the user's concern, not the programmer's. Did you know that Linux does not impose a limit on the size of the environment? The default stack size seems to be 8MB... Now, what would happen if on certain machines that, for one reason or another, have an environment larger than that, and std.process did not account for it? So, to perform the task correctly, std.process would need to perform most allocations on the stack if they are up to a certain size, and on the heap otherwise. What would be a good limit for stack allocations? You may want to choose a value based on whatever's the default stack size on today's Linux versions (after all, std.process is near the "leaf" parts of call stacks). However, certain applications create a lot of stacks, for example for use in lightweight threads (fibers). When restricted by a small address space (32-bit architecture), the stacks need to be much smaller than usual...
 I highlighted, and suggested trivial changes that
 would make a big difference and don't hurt anyone.

Well, why do you think they would make a big difference in std.process? I don't think any of the Phobos developers are against improving performance when the cost is low. So, it's not that I think you're wrong in general, but that the std.process scapegoat (for lack of better word) was not the best choice. I suggest that you file enhancement requests on Bugzilla for each specific component of Phobos / Druntime, improving the allocation behavior of which would result in a real-world benefit for you.
Apr 12 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2013 7:05 AM, Manu wrote:
 I'll start doing it myself, but I also suggest it be made a policy, and
 carefully considered when considering acceptance of ANY new module. That way,
 new code that suffers the unpredictable/"surprise!" allocation problems won't
be
 introduced.

I would also expect that Phobos modules that know the lifetimes of their allocated data use malloc/free rather than the gc. Of course, that entails more effort in coding the modules to ensure no leaks, but we can certainly expect that of phobos developers.
Apr 12 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2013 10:56 AM, Steven Schveighoffer wrote:
 On Fri, 12 Apr 2013 13:41:57 -0400, Walter Bright <newshound2 digitalmars.com>
 wrote:

 On 4/12/2013 7:05 AM, Manu wrote:
 I'll start doing it myself, but I also suggest it be made a policy, and
 carefully considered when considering acceptance of ANY new module. That way,
 new code that suffers the unpredictable/"surprise!" allocation problems won't
be
 introduced.

I would also expect that Phobos modules that know the lifetimes of their allocated data use malloc/free rather than the gc.

I would like a better solution. Allocating things with malloc/free means no GC references involved,or clunky addroot/removeroot calls. That is dangerous to say the least.

Yes, it takes some engineering work to do it right.
 What about dsimcha's region allocator?

Seems like overkill for a small issue.
Apr 12 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b2e0887a301b304da2a650a
Content-Type: text/plain; charset=UTF-8

On 12 April 2013 23:32, Vladimir Panteleev <vladimir thecybershadow.net>wrote:

 On Friday, 12 April 2013 at 12:52:39 UTC, Manu wrote:

 If it's somehow hard to put a string on the stack, then there may be a
 hole
 in phobos. I'm not suggesting changes that are somehow hard to implement,
 or obscure in some way... they should be utterly trivial.

Well, ironically or not, it is not something utterly trivial. The main issue is that the stack can't hold a lot of data. This is not a problem with the heap, which is limited by the amount of memory and address space; these (usually abundant) limits are usually the user's concern, not the programmer's. Did you know that Linux does not impose a limit on the size of the environment? The default stack size seems to be 8MB... Now, what would happen if on certain machines that, for one reason or another, have an environment larger than that, and std.process did not account for it? So, to perform the task correctly, std.process would need to perform most allocations on the stack if they are up to a certain size, and on the heap otherwise. What would be a good limit for stack allocations? You may want to choose a value based on whatever's the default stack size on today's Linux versions (after all, std.process is near the "leaf" parts of call stacks). However, certain applications create a lot of stacks, for example for use in lightweight threads (fibers). When restricted by a small address space (32-bit architecture), the stacks need to be much smaller than usual...

Yes, you're right, there's an 'if' required here to catch unreasonably large environment blocks, but I still consider that within the realm of 'trivial'. This is processed in an appending loop, just check the next bit fits, and if it overflows 1kb or so of stack string, revert to the heap and continue. I reckon helpers could be written to assist with common cases of this (which would have to be mixin template based I guess?)... And I really like the variable-length static array idea! I highlighted, and suggested trivial changes that
 would make a big difference and don't hurt anyone.

Well, why do you think they would make a big difference in std.process? I don't think any of the Phobos developers are against improving performance when the cost is low. So, it's not that I think you're wrong in general, but that the std.process scapegoat (for lack of better word) was not the best choice.

Fuck, I've repeated myself so many times now. The point I make is a general issue I have with phobos, I consider it an issue that should be made policy (irrespective of module being considered), and std.process came into question right at the moment I thought to make the point. It may not be the strongest case for the principle, it's just the one that appeared. I suggest that you file enhancement requests on Bugzilla for each specific
 component of Phobos / Druntime, improving the allocation behavior of which
 would result in a real-world benefit for you.

I'll start doing it myself, but I also suggest it be made a policy, and carefully considered when considering acceptance of ANY new module. That way, new code that suffers the unpredictable/"surprise!" allocation problems won't be introduced. --047d7b2e0887a301b304da2a650a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 12 April 2013 23:32, Vladimir Panteleev <span dir=3D"lt= r">&lt;<a href=3D"mailto:vladimir thecybershadow.net" target=3D"_blank">vla= dimir thecybershadow.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra= "><div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Friday, 12 April 2013 a= t 12:52:39 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> If it&#39;s somehow hard to put a string on the stack, then there may be a = hole<br> in phobos. I&#39;m not suggesting changes that are somehow hard to implemen= t,<br> or obscure in some way... they should be utterly trivial.<br> </blockquote> <br></div> Well, ironically or not, it is not something utterly trivial.<br> <br> The main issue is that the stack can&#39;t hold a lot of data. This is not = a problem with the heap, which is limited by the amount of memory and addre= ss space; these (usually abundant) limits are usually the user&#39;s concer= n, not the programmer&#39;s.<br> <br> Did you know that Linux does not impose a limit on the size of the environm= ent? The default stack size seems to be 8MB... Now, what would happen if on= certain machines that, for one reason or another, have an environment larg= er than that, and std.process did not account for it?<br> <br> So, to perform the task correctly, std.process would need to perform most a= llocations on the stack if they are up to a certain size, and on the heap o= therwise.<br> <br> What would be a good limit for stack allocations? You may want to choose a = value based on whatever&#39;s the default stack size on today&#39;s Linux v= ersions (after all, std.process is near the &quot;leaf&quot; parts of call = stacks). However, certain applications create a lot of stacks, for example = for use in lightweight threads (fibers). When restricted by a small address= space (32-bit architecture), the stacks need to be much smaller than usual= ...</blockquote> <div><br></div><div style>Yes, you&#39;re right, there&#39;s an &#39;if&#39= ; required here to catch unreasonably large environment blocks, but I still= consider that within the realm of &#39;trivial&#39;.</div><div style>This = is processed in an appending loop, just check the next bit fits, and if it = overflows 1kb or so of stack string, revert to the heap and continue.</div> <div style><br></div><div style>I reckon helpers could be written to assist= with common cases of this (which would have to be mixin template based I g= uess?)...</div><div style>And I really like the variable-length static arra= y idea!</div> <div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I highlighted, and suggested trivial changes that<br> would make a big difference and don&#39;t hurt anyone.<br> </blockquote> <br></div> Well, why do you think they would make a big difference in std.process?<br> <br> I don&#39;t think any of the Phobos developers are against improving perfor= mance when the cost is low. So, it&#39;s not that I think you&#39;re wrong = in general, but that the std.process scapegoat (for lack of better word) wa= s not the best choice.<br> </blockquote><div><br></div><div style>Fuck, I&#39;ve repeated myself so ma= ny times now. The point I make is a general issue I have with phobos, I con= sider it an issue that should be made policy (irrespective of module being = considered), and std.process came into question right at the moment I thoug= ht to make the point. It may not be the strongest case for the principle, i= t&#39;s just the one that appeared.</div> <div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I suggest that you file enhancement requests on Bugzilla for each specific = component of Phobos / Druntime, improving the allocation behavior of which = would result in a real-world benefit for you.<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>I&#39;ll star= t doing it myself, but I also suggest it be made a policy, and carefully co= nsidered when considering acceptance of ANY new module. That way, new code = that suffers the unpredictable/&quot;surprise!&quot; allocation problems wo= n&#39;t be introduced.</div> </div> --047d7b2e0887a301b304da2a650a--
Apr 12 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2013 5:52 AM, Manu wrote:
 Just to be clear, I'm not arguing optimisation for performance here, I'm
arguing
 intolerance for __unnecessary__ allocations as a policy, or at least a habit.
 There's a whole separate thread on the topic of fighting unnecessary garbage,
 and having the ability to use D with strict control over the GC and/or
 allocation in general.

 If std functions have no reason to allocate, why should they?

Absolutely right. All phobos functions should not allocate unless absolutely necessary.
Apr 12 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2013 10:51 AM, Steven Schveighoffer wrote:
 Define "absolutely."  For example, there was an objection to accepting an AA as
 an "environment" map to std.process.spawnX functions because even though
reading
 the AA would not require allocation, allocation would certainly be required to
 build the AA.  Is that acceptable?  Certainly we could invent a new
 non-allocating map type and accept that instead.

 I think we need clearer lines drawn here, if they are to be respected.

I think this is best done on a case-by-case basis using best engineering judgement.
Apr 12 2013
prev sibling next sibling parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Friday, 12 April 2013 at 17:37:52 UTC, Walter Bright wrote:
 Absolutely right. All phobos functions should not allocate 
 unless absolutely necessary.

Well that came out of nowhere, when has this rule ever been defined anywhere?
Apr 12 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 13:37:50 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 4/12/2013 5:52 AM, Manu wrote:
 Just to be clear, I'm not arguing optimisation for performance here,  
 I'm arguing
 intolerance for __unnecessary__ allocations as a policy, or at least a  
 habit.
 There's a whole separate thread on the topic of fighting unnecessary  
 garbage,
 and having the ability to use D with strict control over the GC and/or
 allocation in general.

 If std functions have no reason to allocate, why should they?

Absolutely right. All phobos functions should not allocate unless absolutely necessary.

Define "absolutely." For example, there was an objection to accepting an AA as an "environment" map to std.process.spawnX functions because even though reading the AA would not require allocation, allocation would certainly be required to build the AA. Is that acceptable? Certainly we could invent a new non-allocating map type and accept that instead. I think we need clearer lines drawn here, if they are to be respected. -Steve
Apr 12 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 13:41:57 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 4/12/2013 7:05 AM, Manu wrote:
 I'll start doing it myself, but I also suggest it be made a policy, and
 carefully considered when considering acceptance of ANY new module.  
 That way,
 new code that suffers the unpredictable/"surprise!" allocation problems  
 won't be
 introduced.

I would also expect that Phobos modules that know the lifetimes of their allocated data use malloc/free rather than the gc.

I would like a better solution. Allocating things with malloc/free means no GC references involved,or clunky addroot/removeroot calls. That is dangerous to say the least. What about dsimcha's region allocator? -Steve
Apr 12 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 12 April 2013 at 17:41:59 UTC, Walter Bright wrote:
 On 4/12/2013 7:05 AM, Manu wrote:
 I'll start doing it myself, but I also suggest it be made a 
 policy, and
 carefully considered when considering acceptance of ANY new 
 module. That way,
 new code that suffers the unpredictable/"surprise!" allocation 
 problems won't be
 introduced.

I would also expect that Phobos modules that know the lifetimes of their allocated data use malloc/free rather than the gc.

Why not use GC.free ? malloc is invisible for the GC, so nothing GCed can be stored there safely.
Apr 12 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 12 April 2013 at 17:41:59 UTC, Walter Bright wrote:
 I would also expect that Phobos modules that know the lifetimes 
 of their allocated data use malloc/free rather than the gc.

Or even better use new/delete. Delete also nullifies the pointer.
Apr 12 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
--089e013a0a1e81008804da34e3e8
Content-Type: text/plain; charset=UTF-8

On 13 April 2013 03:51, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 On Fri, 12 Apr 2013 13:37:50 -0400, Walter Bright <
 newshound2 digitalmars.com> wrote:

  On 4/12/2013 5:52 AM, Manu wrote:
 Just to be clear, I'm not arguing optimisation for performance here, I'm
 arguing
 intolerance for __unnecessary__ allocations as a policy, or at least a
 habit.
 There's a whole separate thread on the topic of fighting unnecessary
 garbage,
 and having the ability to use D with strict control over the GC and/or
 allocation in general.

 If std functions have no reason to allocate, why should they?

Absolutely right. All phobos functions should not allocate unless absolutely necessary.

Define "absolutely." For example, there was an objection to accepting an AA as an "environment" map to std.process.spawnX functions because even though reading the AA would not require allocation, allocation would certainly be required to build the AA. Is that acceptable? Certainly we could invent a new non-allocating map type and accept that instead. I think we need clearer lines drawn here, if they are to be respected.

Great! I was raising the issue, with the intent to open it for discussion. I never said an AA was intrinsically bad, only that it was impossible to call the function with an environment without allocating, ie, there is no way to pass a literal, and it's just being parsed and piped straight through to a system call, seems redundant to me. --089e013a0a1e81008804da34e3e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 13 April 2013 03:51, Steven Schveighoffer <span dir=3D"= ltr">&lt;<a href=3D"mailto:schveiguy yahoo.com" target=3D"_blank">schveiguy= yahoo.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class= =3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D""><div class=3D"h5">On Fri, 12 Apr 2013 13:3= 7:50 -0400, Walter Bright &lt;<a href=3D"mailto:newshound2 digitalmars.com"= target=3D"_blank">newshound2 digitalmars.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> On 4/12/2013 5:52 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Just to be clear, I&#39;m not arguing optimisation for performance here, I&= #39;m arguing<br> intolerance for __unnecessary__ allocations as a policy, or at least a habi= t.<br> There&#39;s a whole separate thread on the topic of fighting unnecessary ga= rbage,<br> and having the ability to use D with strict control over the GC and/or<br> allocation in general.<br> <br> If std functions have no reason to allocate, why should they?<br> </blockquote> <br> Absolutely right. All phobos functions should not allocate unless absolutel= y necessary.<br> </blockquote> <br></div></div> Define &quot;absolutely.&quot; =C2=A0For example, there was an objection to= accepting an AA as an &quot;environment&quot; map to std.process.spawnX fu= nctions because even though reading the AA would not require allocation, al= location would certainly be required to build the AA. =C2=A0Is that accepta= ble? =C2=A0Certainly we could invent a new non-allocating map type and acce= pt that instead.<br> <br> I think we need clearer lines drawn here, if they are to be respected.<br><= /blockquote><div><br></div><div style>Great! I was raising the issue, with = the intent to open it for discussion.</div><div style><br></div><div style> I never said an AA was=C2=A0intrinsically=C2=A0bad, only that it was imposs= ible to call the function with an environment without allocating, ie, there= is no way to pass a literal, and it&#39;s just being parsed and piped stra= ight through to a system call, seems redundant to me.</div> </div></div></div> --089e013a0a1e81008804da34e3e8--
Apr 12 2013