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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: in defense of GC References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> <14hm72xd3b0bq$.axktv523vay8$.dlg@40tude.net> <4zwt33xm4b.fsf@hod.lan.m-e-leypold.de> <1j7neot6h1udi$.14vp2aos6z9l8.dlg@40tude.net> <1pzx3y7d2pide.y744copm0ejb$.dlg@40tude.net> From: Markus E Leypold Organization: N/A Date: Sun, 04 Feb 2007 21:24:01 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:BkKAYbMOgap7kVzLgodNBTVkAoQ= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.198.57 X-Trace: news.arcor-ip.de 1170620340 88.72.198.57 (4 Feb 2007 21:19:00 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news2.google.com!news.germany.com!news-stu1.dfn.de!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:8925 Date: 2007-02-04T21:24:01+01:00 List-Id: "Dmitry A. Kazakov" writes: > On Sat, 03 Feb 2007 15:28:53 +0100, Markus E Leypold wrote: > >> "Dmitry A. Kazakov" writes: >> >>> On Fri, 02 Feb 2007 13:44:42 +0100, Markus E Leypold wrote: >>> >>>> Closure don't "make things global". They do it as much as returning an >>>> Integer, makes, GOD FORBID!, a value global (don't return Integers >>>> people, that makes a value global and we all know, global is bad -- >>>> how nonsensical is that?). >>> >>> You return a value of the type (Integer) which scope encloses the >>> subprogram returning that value. >> >> Same applies to closures when they are returned. Where is the problem? > > The problem is this: > > function Foo return ?What? is > type Bar is ...; > X : Bar; > begin > return X; > end Foo; > >>> I am a long proponent of procedural types for Ada. Now consider. A >>> procedure is a limited object. Limited objects can be returned in Ada 2005. >>> What else you need? [Note, this is still not an upward closure, I am >>> opposing.] >> >> I do need that >> >> function Make_a_Stepper (K:Integer) return ... is >> >> N : Integer := Complicated_Function(K); >> >> function Stepper(F:Foo) return Foo is >> >> begin >> >> return Foo + N; >> >> end; >> >> begin >> return Stepper; >> end; >> >> >> would work. And no nitpicking, please, if I made syntax error here: The >> intention should be clear. > > I suppose it is. Here I propose a closure-free solution: > > package Something_Very_Functional is > type function Stepper (F : Foo) return Foo; > -- The type of a function we want to pass somewhere > procedure Step_It (Visitor : Stepper'Class); > ... > end Something_Very_Functional; > > package Stepper_Factory is > function Create (K : Integer) return Stepper'Class; > -- This is a constructor for the stepper provided here. We > -- don't want to expose any details about it, so the > -- Stepper type is made private. > private > type Stepper_With_A_Parameter (N : Integer) is new Stepper; > -- This is a derived type to have a discriminant, which could serve > -- as a carrier for the locally computed value. > end Stepper_Factory; > > package body Stepper_Factory is > function Create (K : Integer) return Stepper'Class is > begin > return > Stepper_With_A_Parameter' > ( N => Complicated_Function (K), > with > begin > return F + N; > end; > ); > end Stepper_Factory; > > Some notes. Within the "procedural record extension" the visibility rules > are such that local variables of Create are invisible. The package data are > visible and accessibility checks are made to ensure that the scope of > Stepper_With_A_Parameter is not statically deeper than one of Stepper. > > ----------------- > BTW, I prefer an OO design with Stepper being an abstract primitive > operation of some object: > > type Data is abstract ...; > function Stepper (State : in out Data; F : Foo) return Foo is abstract; > procedure Step_It (Data : in out Data'Class); > ------------------- Yes. That is exactly what I referred to in earlier posts as clumsy -- to replace closure by this kind of dance. > >> If it works, we have closures. If it doesn't I fail to see what you >> mean by 'returning procedures'. > > Hmm, it must be obvious. How could it be so that we have > access-to-procedure types, but no procedure types? ?? I still do not understand. If memory serves me right, I cannot return an access to a local procedure. So? >>>> I can't believe I even have to spell it out. On the other side -- why >>>> do I argue? You're even opposing generics. >>> >>> Yes I do! (:-)) >> >> Yes I notice. That does make you avantgarde, certainly. Even the Java >> people learned that there is no live without generics / functors. > > As if Java weren't bad enough for them... (:-)) Well -- actually that was one of the things they did right for once, and it wasn't even tacked on ad hoc, but carefully designed by people who do know hwat they are talking about (i.e. Philip Wadler of FP fame). Regards -- Markus