From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!us.feeder.erje.net!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada 2012 Corrigendum Date: Fri, 12 Sep 2014 15:08:27 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls7.std.com 1410548873 30897 192.74.137.71 (12 Sep 2014 19:07:53 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 12 Sep 2014 19:07:53 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:GcbSbgqGQfHP6jZPO70C3aoWPLw= Xref: number.nntp.dca.giganews.com comp.lang.ada:188987 Date: 2014-09-12T15:08:27-04:00 List-Id: Shark8 writes: > Issue 2: Static (and compile-time) Functions > > !topic Compile-time Executed Functions > !reference None [?] Reference the section on static expressions, and possibly the expression-functions section. > !from Edward Fish, 12 Sep 14 > !keywords Compile-time Static Pure Functions Macro > > Given the advent of expression-functions, and the loosening of > 'Function' from the more mathematical concept [that is, allowing IN OUT > parameters] it makes some sense to introduce an aspect [or set of > aspects] that re-introduces [and strengthens] the guarantees that were > implicit (or initially intended) in the language. Well, Ada functions have never been pure mathematical functions. They've always been allowed to read and write global variables, heap data, etc. You make a good argument that this suggestion would be useful, but without actual RM wording, it's impossible to know exactly what you are proposing. For example, is this aspect allowed only on expression functions? If it's allowed on functions with regular old bodies, what happens if the body contains machine-code inserts? If it's only allowed on expression functions, then why do you need an aspect? -- you could just say a call to an expression function is a static expression if the function and its actual parameters have certain properties. In fact, I think that idea was discussed when expression functions were invented -- you might find it useful to read the AI that introduced expression functions. There must be some restrictions on what can go in these functions (e.g. calls to other impure functions?). What happens if you call one of these things with nonstatic actual parameters? I'd guess that should be legal, but that call won't itself be a static expression. Are these things allowed to have parameters/results of access type? Composite type? > Function MSB (N : Integer) Return Integer > with PRE_COMPILE -- or STATIC, or PURE_FUNCTION, or whatever I don't like "Pre_Compile" -- it seems too mechanistic. Why not "Pure"? "Pure_Function" already exists in GNAT, and it means something different, so we wouldn't want to use that name. All in all, I suspect that this is too big of a change for the benefit. It's not a bad idea, though, in the abstract. - Bob