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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.157.37 with SMTP id wj5mr5232704pab.30.1447923378865; Thu, 19 Nov 2015 00:56:18 -0800 (PST) X-Received: by 10.182.112.234 with SMTP id it10mr89017obb.13.1447923378776; Thu, 19 Nov 2015 00:56:18 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!i2no4959566igv.0!news-out.google.com!f6ni7032igq.0!nntp.google.com!i2no5162452igv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 19 Nov 2015 00:56:18 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=82.216.245.129; posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr NNTP-Posting-Host: 82.216.245.129 References: <14533506-4289-4148-b8c4-e970f5778b26@googlegroups.com> <87si45msuz.fsf@nightsong.com> <35d6dc4f-4f2e-4e75-925c-e4acc7c8f112@googlegroups.com> <76ea0bc9-537b-4c68-a728-4f634cf6de52@googlegroups.com> <87a8qccxj4.fsf@nightsong.com> <0ff849e9-11d7-438d-abf9-853f79348640@googlegroups.com> <874mgjnctv.fsf@nightsong.com> <87ziyblkzn.fsf@nightsong.com> <937b88b1-66aa-4205-a412-9588d83a3f26@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <36a48f94-41ee-491a-8312-d6e7732bf482@googlegroups.com> Subject: Re: Haskell, anyone? From: Hadrien Grasland Injection-Date: Thu, 19 Nov 2015 08:56:18 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:28454 Date: 2015-11-19T00:56:18-08:00 List-Id: Le jeudi 19 novembre 2015 00:06:20 UTC+1, Randy Brukardt a =E9crit=A0: > ... > >This does not mean that there isn't a benefit to the functional ways. Bu= t I=20 > >don't > > think that we can handwave away their additional complexity with a simp= le=20 > > "it > > depends on what you're used to". Functional constructs are, indeed, les= s=20 > > intuitive, > >and according to Occam's principle such extra learning complexity deserv= es=20 > >a > >good motivation (which I believe most functional programming fans will b= e > >happy giving anyway). >=20 > I agree. In addition, this is an Ada forum, and it would be nice to get b= ack=20 > to conversation about Ada. >=20 > So, let me say that it certainly possible to program in a functional styl= e=20 > using Ada. >=20 > It's always been possible to construct pure functions (those with no=20 > side-effects) in Ada, and it's likely that Ada 2018 will have a way to=20 > declare and enforce that. >=20 > One can use the advanced data structures in Ada.Containers to program usi= ng=20 > lists, maps, trees, and so on without messing with the ugly details=20 > (including storage management). It would be easy to use these structures = as=20 > a basis for even higher level operations if one really wanted to hide=20 > iterators and the like. (You can already use the call-back form of iterat= ion=20 > to avoid any visible imperative code, if you wanted to do that.) >=20 > As Hadrien said, it's useful to have FP techniques available when they wo= rk=20 > well, but one really doesn't want to be fenced into any single programmin= g=20 > paradyme. Basic imperative programming alone, or ADTs alone, or OOP alone= ,=20 > or FP alone, or whatever alone, is almost never the best way to get thing= s=20 > done. Some problems map naturally into one style or another, and its craz= y=20 > to be fenced into some other style for such problems. >=20 > Randy. Actually, speaking of functional programming Ada, I'm curious : would there= be an elegant way to produce a higher-order function equivalent in Ada ? Ada sure has the very powerful ability to declare functions within function= s, and it also has function pointers. But due to the way accessibility rule= s work, my understanding is that this would not be enough to implement thin= gs like partial application or containers of functions, because once we lea= ve the scope of a function, it instantly ceases to exist. This would leave us to using ad-hoc functor objects which are declared at g= lobal scope and whose state is filled up as needed, as in the C++98 era, wh= ich is certainly not what I would call an elegant solution. Or have I missed some important language feature which could be used to thi= s end, like a way to serialize a function and its state to a stream ?