* Ada2012 : When to use expression functions rather than function bodies? @ 2011-12-16 12:25 Martin 2011-12-16 13:24 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Martin @ 2011-12-16 12:25 UTC (permalink / raw) Are there any good arguments for *not* replacing all simple, single line functions that don't [directly] access package body state information with expression functions? -- Martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 12:25 Ada2012 : When to use expression functions rather than function bodies? Martin @ 2011-12-16 13:24 ` Dmitry A. Kazakov 2011-12-17 1:03 ` Randy Brukardt 2011-12-16 18:03 ` Adam Beneschan 2011-12-16 22:01 ` Jeffrey Carter 2 siblings, 1 reply; 15+ messages in thread From: Dmitry A. Kazakov @ 2011-12-16 13:24 UTC (permalink / raw) On Fri, 16 Dec 2011 04:25:09 -0800 (PST), Martin wrote: > Are there any good arguments for *not* replacing all simple, single > line functions that don't [directly] access package body state > information with expression functions? 1. Readability 2. Proper encapsulation (to have interface and implementation separated) 3. Re-use (the same function must be refactored) 4. Maintainability (because of 1..3) 5. Safety (proper bodies are defined on the context where they have no access to the caller's context, otherwise than through parameters) 6. Deployment (proper bodies can be put into a library, have versions etc) 7. It is not Ada -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 13:24 ` Dmitry A. Kazakov @ 2011-12-17 1:03 ` Randy Brukardt 0 siblings, 0 replies; 15+ messages in thread From: Randy Brukardt @ 2011-12-17 1:03 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1s7pzkf4hmdl5.15o0cmwoy5alh$.dlg@40tude.net... > On Fri, 16 Dec 2011 04:25:09 -0800 (PST), Martin wrote: > >> Are there any good arguments for *not* replacing all simple, single >> line functions that don't [directly] access package body state >> information with expression functions? > > 1. Readability > 2. Proper encapsulation (to have interface and implementation separated) > 3. Re-use (the same function must be refactored) > 4. Maintainability (because of 1..3) > 5. Safety (proper bodies are defined on the context where they have no > access to the caller's context, otherwise than through parameters) > 6. Deployment (proper bodies can be put into a library, have versions etc) > 7. It is not Ada Umm, an expression function is just another (shorter) way to write a function body, so it hard to imagine that there is any difference. Using them to replace a function body *in place* is completely harmless. I suppose you are talking about the use of expression functions directly in a specification (without an explicit body), which is a totally separate issue. There, I tend to agree with you in the sense that they ought to be used in moderation. The intent was to use them for things like accessors for private components where there is no real value to the separate body. For those sorts of uses, the issues you talk about above don't arise. (How could you "refactor" Obj.Field??). Moreover, everything in the private part is part of the implementation anyway; you're still enforcing that separation so long as the expression functions are in the private part. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 12:25 Ada2012 : When to use expression functions rather than function bodies? Martin 2011-12-16 13:24 ` Dmitry A. Kazakov @ 2011-12-16 18:03 ` Adam Beneschan 2011-12-16 20:36 ` Martin Dowie 2011-12-17 12:26 ` georg bauhaus 2011-12-16 22:01 ` Jeffrey Carter 2 siblings, 2 replies; 15+ messages in thread From: Adam Beneschan @ 2011-12-16 18:03 UTC (permalink / raw) On Dec 16, 4:25 am, Martin <mar...@thedowies.com> wrote: > Are there any good arguments for *not* replacing all simple, single > line functions that don't [directly] access package body state > information with expression functions? If you're talking about a function that is declared in the visible part of a package specification, and talking about replacing the declaration with an expression function, then it would usually be a bad idea to replace it. The visible part should, ideally, express what the package is intended to accomplish, at a conceptual level. So unless the expression is, itself, part of the concept (a rare case), it's an implementation detail that should not be present in the visible part of a package. A good test here, I think, is: "Is it possible that at some later point, I may change the expression returned by an expression function because I've added new features to the package or because I've changed the implementation to improve its efficiency or fix problems?" If the answer is yes, then the expression is probably an implementation detail and not part of the package's "concept", and the function shouldn't be an expression function. I think this is approximately what Dmitry means by "proper encapsulation". Offhand, I don't see any problem with replacing simple function *bodies* with expression functions. But I haven't studied the new rules carefully, so I couldn't tell you if there are some "gotchas" in the language rules that would cause the semantics or the impact on other language rules to be different. In most cases, it's probably OK to replace a function specification in the *private* part of a package with an expression function if the body is simple. But the encapsulation argument could still apply if the function is intended to be usable by child packages. -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 18:03 ` Adam Beneschan @ 2011-12-16 20:36 ` Martin Dowie 2011-12-16 21:34 ` Adam Beneschan 2011-12-17 12:26 ` georg bauhaus 1 sibling, 1 reply; 15+ messages in thread From: Martin Dowie @ 2011-12-16 20:36 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> wrote: > On Dec 16, 4:25 am, Martin <mar...@thedowies.com> wrote: >> Are there any good arguments for *not* replacing all simple, single >> line functions that don't [directly] access package body state >> information with expression functions? > > If you're talking about a function that is declared in the visible > part of a package specification, and talking about replacing the > declaration with an expression function, then it would usually be a > bad idea to replace it. The visible part should, ideally, express > what the package is intended to accomplish, at a conceptual level. So > unless the expression is, itself, part of the concept (a rare case), > it's an implementation detail that should not be present in the > visible part of a package. A good test here, I think, is: "Is it > possible that at some later point, I may change the expression > returned by an expression function because I've added new features to > the package or because I've changed the implementation to improve its > efficiency or fix problems?" If the answer is yes, then the > expression is probably an implementation detail and not part of the > package's "concept", and the function shouldn't be an expression > function. I think this is approximately what Dmitry means by "proper > encapsulation". > > Offhand, I don't see any problem with replacing simple function > *bodies* with expression functions. But I haven't studied the new > rules carefully, so I couldn't tell you if there are some "gotchas" in > the language rules that would cause the semantics or the impact on > other language rules to be different. > > In most cases, it's probably OK to replace a function specification in > the *private* part of a package with an expression function if the > body is simple. But the encapsulation argument could still apply if > the function is intended to be usable by child packages. > > -- Adam The most common usage I can image is functions used in Pre/Post conditions: package Foos is type Foo is tagged private; ... procedure Bar (Self : in out Foo) with Pre => Is_Valid (Self); function Is_Valid (Self : Foo) return Boolean; ... private ... function Is_Valid (Self : Foo) return Boolean is (<validate_Self>); ... end Foos; There isn't really an expectation that Is_Valid would be of use to a user of package Foos. But I guess the same idiom could be used for other 'simple' functions...public declaration, private expression function implementation, leaving the package body of more interesting stuff. -- Martin -- -- Sent from my iPad ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 20:36 ` Martin Dowie @ 2011-12-16 21:34 ` Adam Beneschan 2011-12-16 23:08 ` Adam Beneschan 0 siblings, 1 reply; 15+ messages in thread From: Adam Beneschan @ 2011-12-16 21:34 UTC (permalink / raw) On Dec 16, 12:36 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com> wrote: > Adam Beneschan <a...@irvine.com> wrote: > > On Dec 16, 4:25 am, Martin <mar...@thedowies.com> wrote: > >> Are there any good arguments for *not* replacing all simple, single > >> line functions that don't [directly] access package body state > >> information with expression functions? > > > If you're talking about a function that is declared in the visible > > part of a package specification, and talking about replacing the > > declaration with an expression function, then it would usually be a > > bad idea to replace it. The visible part should, ideally, express > > what the package is intended to accomplish, at a conceptual level. So > > unless the expression is, itself, part of the concept (a rare case), > > it's an implementation detail that should not be present in the > > visible part of a package. A good test here, I think, is: "Is it > > possible that at some later point, I may change the expression > > returned by an expression function because I've added new features to > > the package or because I've changed the implementation to improve its > > efficiency or fix problems?" If the answer is yes, then the > > expression is probably an implementation detail and not part of the > > package's "concept", and the function shouldn't be an expression > > function. I think this is approximately what Dmitry means by "proper > > encapsulation". > > > Offhand, I don't see any problem with replacing simple function > > *bodies* with expression functions. But I haven't studied the new > > rules carefully, so I couldn't tell you if there are some "gotchas" in > > the language rules that would cause the semantics or the impact on > > other language rules to be different. > > > In most cases, it's probably OK to replace a function specification in > > the *private* part of a package with an expression function if the > > body is simple. But the encapsulation argument could still apply if > > the function is intended to be usable by child packages. > > > -- Adam > > The most common usage I can image is functions used in Pre/Post conditions: > > package Foos is > type Foo is tagged private; > ... > procedure Bar (Self : in out Foo) > with Pre => Is_Valid (Self); > function Is_Valid (Self : Foo) return Boolean; > ... > private > ... > function Is_Valid (Self : Foo) return Boolean is (<validate_Self>); > ... > end Foos; > > There isn't really an expectation that Is_Valid would be of use to a user > of package Foos. I don't see a problem (from a proper encapsulation standpoint) with putting the expression function in the private part. Like I said before, though, I haven't studied the new rules enough to know whether there could be any other problems caused by the language rules. Offhand, it seems possible that if the expression involves a call to a function in another package, there could be cases where moving the definition from the body to the specification could fail because a different elaboration order is required. -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 21:34 ` Adam Beneschan @ 2011-12-16 23:08 ` Adam Beneschan 0 siblings, 0 replies; 15+ messages in thread From: Adam Beneschan @ 2011-12-16 23:08 UTC (permalink / raw) On Dec 16, 1:34 pm, Adam Beneschan <a...@irvine.com> wrote: > On Dec 16, 12:36 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com> > wrote: I wrote: > > Adam Beneschan <a...@irvine.com> wrote: > > > On Dec 16, 4:25 am, Martin <mar...@thedowies.com> wrote: > > >> Are there any good arguments for *not* replacing all simple, single > > >> line functions that don't [directly] access package body state > > >> information with expression functions? > > > > If you're talking about a function that is declared in the visible > > > part of a package specification, and talking about replacing the > > > declaration with an expression function, then it would usually be a > > > bad idea to replace it. The visible part should, ideally, express > > > what the package is intended to accomplish, at a conceptual level. So > > > unless the expression is, itself, part of the concept (a rare case), > > > it's an implementation detail that should not be present in the > > > visible part of a package. A good test here, I think, is: "Is it > > > possible that at some later point, I may change the expression > > > returned by an expression function because I've added new features to > > > the package or because I've changed the implementation to improve its > > > efficiency or fix problems?" If the answer is yes, then the > > > expression is probably an implementation detail and not part of the > > > package's "concept", and the function shouldn't be an expression > > > function. I think this is approximately what Dmitry means by "proper > > > encapsulation". > > > > Offhand, I don't see any problem with replacing simple function > > > *bodies* with expression functions. But I haven't studied the new > > > rules carefully, so I couldn't tell you if there are some "gotchas" in > > > the language rules that would cause the semantics or the impact on > > > other language rules to be different. > > > > In most cases, it's probably OK to replace a function specification in > > > the *private* part of a package with an expression function if the > > > body is simple. But the encapsulation argument could still apply if > > > the function is intended to be usable by child packages. > > > > -- Adam > > > The most common usage I can image is functions used in Pre/Post conditions: > > > package Foos is > > type Foo is tagged private; > > ... > > procedure Bar (Self : in out Foo) > > with Pre => Is_Valid (Self); > > function Is_Valid (Self : Foo) return Boolean; > > ... > > private > > ... > > function Is_Valid (Self : Foo) return Boolean is (<validate_Self>); > > ... > > end Foos; > > > There isn't really an expectation that Is_Valid would be of use to a user > > of package Foos. > > I don't see a problem (from a proper encapsulation standpoint) with > putting the expression function in the private part. > > Like I said before, though, I haven't studied the new rules enough to > know whether there could be any other problems caused by the language > rules. Offhand, it seems possible that if the expression involves a > call to a function in another package, there could be cases where > moving the definition from the body to the specification could fail > because a different elaboration order is required. On thinking about it further: A good reason *not* to put an expression function in the private part of a specification, if the function is an "implementation detail", is that if the details of the implementation are mostly in the package body (in procedures or in more complex functions), then moving some of it arbitrarily to the private part, which is separate from the package body and is often in a different source file, can impair readability and maintainability. When a programmer is trying to maintain a package, either by adding new features, improving performance, or fixing problems, it's helpful for related pieces of information about the package's implementation to be near each other. Otherwise, it's too easy to miss something. And moving one implementation detail to a package's private part while other details are still in the body increases the chance of missing something. So yes, I think there is a good argument for *not* mechanically moving all simple functions to the package specification as expression functions, even into the private part. The programmer needs to think about readability/maintainability issues such as I've described. -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 18:03 ` Adam Beneschan 2011-12-16 20:36 ` Martin Dowie @ 2011-12-17 12:26 ` georg bauhaus 1 sibling, 0 replies; 15+ messages in thread From: georg bauhaus @ 2011-12-17 12:26 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> wrote: . > > In most cases, it's probably OK to replace a function specification in > the *private* part of a package with an expression function if the > body is simple. But the encapsulation argument could still apply if > the function is intended to be usable by child packages. A pragma Pure is, I think, helpful when writing expression functions in particular if it forces thinking about the kind of functions one is writing: expression functions that have effects other than computing the result value seem out of (some) style. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 12:25 Ada2012 : When to use expression functions rather than function bodies? Martin 2011-12-16 13:24 ` Dmitry A. Kazakov 2011-12-16 18:03 ` Adam Beneschan @ 2011-12-16 22:01 ` Jeffrey Carter 2011-12-16 22:52 ` Adam Beneschan 2 siblings, 1 reply; 15+ messages in thread From: Jeffrey Carter @ 2011-12-16 22:01 UTC (permalink / raw) On 12/16/2011 05:25 AM, Martin wrote: > Are there any good arguments for *not* replacing all simple, single > line functions that don't [directly] access package body state > information with expression functions? Are there any good arguments for expression functions? -- Jeff Carter "I like it when the support group complains that they have insufficient data on mean time to repair bugs in Ada software." Robert I. Eachus 91 --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net --- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 22:01 ` Jeffrey Carter @ 2011-12-16 22:52 ` Adam Beneschan 2011-12-16 23:09 ` Adam Beneschan 2011-12-17 1:21 ` Randy Brukardt 0 siblings, 2 replies; 15+ messages in thread From: Adam Beneschan @ 2011-12-16 22:52 UTC (permalink / raw) On Dec 16, 2:01 pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org> wrote: > On 12/16/2011 05:25 AM, Martin wrote: > > > Are there any good arguments for *not* replacing all simple, single > > line functions that don't [directly] access package body state > > information with expression functions? > > Are there any good arguments for expression functions? Quote from AI05-0177-1 (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ ai05s/ai05-0177-1.txt?rev=1.13): With the advent of pre and postconditions (see AI05-0145-1), and conditional expressions (see AI05-0147-1), expressions in specifications are going to grow much larger and become more complicated. It is important that parts of such expressions can be abstracted. Abstraction of expressions is usually done by introducing functions. However, this puts the expression in the body, rather than the specification. This has several negative side-effects: -- Hiding of the expression from the compiler and other tools that primarily process specifications; -- Requiring the body to exist in order to do static analysis of the pre/post conditions (meaning static analysis cannot be performed early in the development of a system or on the use of skelton [sic] placeholder packages). -- Introduction of otherwise unnecessary bodies and/or otherwise unnecessary inline body dependencies (increasing system build times). Apparently the ARG thought this was a good argument. I'm not endorsing it personally -- I don't have a particular opinion -- but it appears sensible on its face. -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 22:52 ` Adam Beneschan @ 2011-12-16 23:09 ` Adam Beneschan 2011-12-17 1:21 ` Randy Brukardt 1 sibling, 0 replies; 15+ messages in thread From: Adam Beneschan @ 2011-12-16 23:09 UTC (permalink / raw) On Dec 16, 2:52 pm, Adam Beneschan <a...@irvine.com> wrote: > > Quote from AI05-0177-1 (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ > ai05s/ai05-0177-1.txt?rev=1.13): Sorry, Google broke up my link. Hopefully this will work better. http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0177-1.txt?rev=1.13 -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-16 22:52 ` Adam Beneschan 2011-12-16 23:09 ` Adam Beneschan @ 2011-12-17 1:21 ` Randy Brukardt 2011-12-17 12:45 ` georg bauhaus 1 sibling, 1 reply; 15+ messages in thread From: Randy Brukardt @ 2011-12-17 1:21 UTC (permalink / raw) "Adam Beneschan" <adam@irvine.com> wrote in message news:12acbf57-01fc-43dd-8881-d39c2a63146b@q9g2000yqe.googlegroups.com... ... >Apparently the ARG thought this was a good argument. I'm not >endorsing it personally -- I don't have a particular opinion -- but it >appears sensible on its face. One of the things we learned when thinking about Preconditions and the like is that there is such a thing as too much encapsulation. The entire point of preconditions is that they be understandable to the client, so the client (caller) knows what they must ensure before calling the routine. You could write all of your preconditions like: procedure Do_It (A, B : in out Integer) with Pre => Do_It_Precondition (A, B); but no one would have any idea what the precondition is. After all, an important part of the point of preconditions is to change what currently is specified in English in the comments in a more formal way that can be checked (statically and dynamically). So it is best to use as little encapsulation as possible in preconditions and the like, breaking them down to the primitive operations of the type(s) involved. But preconditions can get very long, and the need to simplify them for readability surely exists. Thus expression functions provide a middle ground. They're also handy for simple accessor functions (which can give the effect of read-only components of a private type). There also is one more fact: an expression function can almost always be inlined (beware of recursion, though), and that can be done automatically when it makes sense (no need for pragmas or body dependencies -- inlining is something the compiler should be deciding upon anyway, it is stupid for users to have to declare something that should always be done if it makes sense -- and not be done when it doesn't make sense). Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-17 1:21 ` Randy Brukardt @ 2011-12-17 12:45 ` georg bauhaus 2011-12-17 13:11 ` Dmitry A. Kazakov 0 siblings, 1 reply; 15+ messages in thread From: georg bauhaus @ 2011-12-17 12:45 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote: . > > You could write all of your preconditions like: > > procedure Do_It (A, B : in out Integer) > with Pre => Do_It_Precondition (A, B); > > but no one would have any idea what the precondition is. I'm guessing that Dmitry will suggest Procedure Do_It (A, B: Int_Sats_Pre) with Pre => True; will be safer and will convey the idea of the precondition better: it is in the type system. Whether this approach is feasible in general I don't know. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-17 12:45 ` georg bauhaus @ 2011-12-17 13:11 ` Dmitry A. Kazakov 2011-12-19 23:34 ` Randy Brukardt 0 siblings, 1 reply; 15+ messages in thread From: Dmitry A. Kazakov @ 2011-12-17 13:11 UTC (permalink / raw) On 17 Dec 2011 12:45:38 GMT, georg bauhaus wrote: > "Randy Brukardt" <randy@rrsoftware.com> wrote: >> >> You could write all of your preconditions like: >> >> procedure Do_It (A, B : in out Integer) >> with Pre => Do_It_Precondition (A, B); >> >> but no one would have any idea what the precondition is. > > I'm guessing that Dmitry will suggest > > Procedure Do_It (A, B: Int_Sats_Pre) with > Pre => True; > > will be safer and will convey the idea > of the precondition better: it is in the type system. Not really. The key question is whether Do_It_Precondition is statically checkable. Note also that it is not always possible to break a [true] precondition into a set of *independent* subtype constraints. As an example consider: function "+" (Left, Right : Dimensioned) return Dimensioned; The precondition here (IFF measurement units have to be checked statically) is that Left and Right have the same unit. If the measurement units cannot be checked statically THEN the precondition is "true" and the contract of "+" includes Unit_Error. Argument against Do_It_Precondition is same as against a formula: declarations should include minimum executable code. The language of declarations (types algebra operations) must be clearly, visibly separated from the object (executable) language. All cases when executable code slips into the declarations cause difficulties because of the contexts mismatch, e.g. procedure Foo (Default : Integer := Get); -- What is the default here? When the default is read from standard -- input? Pure and static expressions are OK because the context is irrelevant. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada2012 : When to use expression functions rather than function bodies? 2011-12-17 13:11 ` Dmitry A. Kazakov @ 2011-12-19 23:34 ` Randy Brukardt 0 siblings, 0 replies; 15+ messages in thread From: Randy Brukardt @ 2011-12-19 23:34 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1xbajufyxdf4j.1moa6g6ouhykk$.dlg@40tude.net... > On 17 Dec 2011 12:45:38 GMT, georg bauhaus wrote: ... >> I'm guessing that Dmitry will suggest >> >> Procedure Do_It (A, B: Int_Sats_Pre) with >> Pre => True; >> >> will be safer and will convey the idea >> of the precondition better: it is in the type system. > > Not really. The key question is whether Do_It_Precondition is statically > checkable. Note also that it is not always possible to break a [true] > precondition into a set of *independent* subtype constraints. Right. We had this (sub)discussion in the ARG. It seemed better to extend subtype constraints for parameters rather than the heavier mechanism of preconditions. But the counter argument is that a constraint can act only on a single parameter, while a precondition might involve multiple parameters. Dmitry shows a good example. BTW, we recently added a rule stating that it is a bounded error to call a function from a contract (precondition, predicate, etc.) that has a side effect that changes the value of some other contract of the same evaluation. The latter part is a sop to the people who insist that we have to support "benign" side-effects (such as "memo functions"). (IMHO, there are no benign side-effects, but there are strong opinions to the contrary out there.) The effect is that the vast majority of contracts will be "pure" expressions, so Dmitry will be happier. (The state-of-the-art will not allow static checking of these things today in general, but as the technology improves that should become possible without having to rewrite your code). Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-12-19 23:34 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-12-16 12:25 Ada2012 : When to use expression functions rather than function bodies? Martin 2011-12-16 13:24 ` Dmitry A. Kazakov 2011-12-17 1:03 ` Randy Brukardt 2011-12-16 18:03 ` Adam Beneschan 2011-12-16 20:36 ` Martin Dowie 2011-12-16 21:34 ` Adam Beneschan 2011-12-16 23:08 ` Adam Beneschan 2011-12-17 12:26 ` georg bauhaus 2011-12-16 22:01 ` Jeffrey Carter 2011-12-16 22:52 ` Adam Beneschan 2011-12-16 23:09 ` Adam Beneschan 2011-12-17 1:21 ` Randy Brukardt 2011-12-17 12:45 ` georg bauhaus 2011-12-17 13:11 ` Dmitry A. Kazakov 2011-12-19 23:34 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox