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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9e7db243dfa070d7 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,CP1252 Path: g2news2.google.com!postnews.google.com!p1g2000yqm.googlegroups.com!not-for-mail From: "Chad R. Meiners" Newsgroups: comp.lang.ada Subject: Re: Do people who use Ada also use ocaml or F#? Date: Fri, 29 Oct 2010 18:32:53 -0700 (PDT) Organization: http://groups.google.com Message-ID: <4aacf4ab-6e56-421d-8381-26f8aeb5c840@p1g2000yqm.googlegroups.com> References: NNTP-Posting-Host: 173.48.246.55 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1288402374 6316 127.0.0.1 (30 Oct 2010 01:32:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 30 Oct 2010 01:32:54 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: p1g2000yqm.googlegroups.com; posting-host=173.48.246.55; posting-account=XRGbKgoAAACag8f1Ww4XGf81DDZtyfbX User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7,gzip(gfe) Xref: g2news2.google.com comp.lang.ada:15922 Date: 2010-10-29T18:32:53-07:00 List-Id: On Oct 28, 10:58=A0pm, Yannick Duch=EAne (Hibou57) wrote: > Le Fri, 29 Oct 2010 04:27:40 +0200, Chad =A0R. Meiners =A0 > a =E9crit:> I am love the elegance of static ty= ping > > without explicit type declarations > > Type inference may seems appealing due to its conciseness. Just that as = =A0 > source become bigger, you do not enjoy it any more. That is the work of a good IDE. Visual studios does an excellent job of giving me the type of any variable in F#. Plus you can also constrain the parameters ( let x (y : #foo) =3D ... ) when you want to prevent certain types of automatic generalization. Learning Ada's type system was an excellent introduction how to think about type systems. I don't really agree that when the source becomes bigger that type inference is a problem. Modules and functors allow you to break up the system's code so that each piece is understandable, but more importantly, less work is needed to compose data structures and functions. > > Do any other Ada programmers also use functional languages like > > these? =A0If so, has anyone given any thoughts on how to incorporate th= e > > nice features of both languages? > > Ada 2012 introduced something looking like coroutines with the yield =A0 > function (formally, generators), which is a famous feature of functional = =A0 > paradigm languages (gonna be great for kinds of streams of any kind of = =A0 > data or iterators). > > However, adding this and that =93cool=94 feature of that language A in th= is =A0 > language B, is easier said than done (you guess?), although this may be a= =A0 > popular topic. I don't want to add cool features to Ada. I was thinking more of how concepts from ML based languages and Ada could be combined to create a nice statically typed language that would preferably have formal semantics. The structural typing of ML makes stuff like type foo is new Integer range 0..255; very difficult. This sort of strong typing with constraints is something I miss when programming in ML-based languages. However, sometimes the verbosity of Ada programs tends towards the monotonous. In many cases, the repetition of type assertion is a desirable sanity check; however, ML-based languages allows for the functionally to be more efficiently expressed in some cases. Take pattern matching and automatic generalization for an example let reduce foo =3D let rec go carry =3D function | [] -> carry | value :: tail -> go (foo carry value) tail in go the equivalent Ada would be (don't have an Ada compiler accessible) generic type t is private; type t_list is limited private; with function foo(Left : t; Right : t) return t; with function head(item : t_list) return t; with function tail(item : t_list) return t_list; with function isNull(item : t_list) return Boolean; function reduce(carry : t; list : t_list) return t is begin if isNull(list) then return carry; else return reduce(foo(carry, head(list)), tail(list)); end if; end reduce; It seems to me others may want to combine the nice traits in each language. I build research algorithms, conciseness is very desirable because I want to be able to fit complete algorithms on a page and I do not want to commit to specific implementations. However, I want the compiler to check my type in a rigorous manner so it is easier to make sure the implementations are correct. > Cannot reply this question unless you precisely say which feature and for= =A0 > what reason. A lot of job is done by the maintainers (and in some part, = =A0 > the Ada community), to preserve Ada language definition's soundness. Too = =A0 > much risky to talk about adding features just because it sounds cool and = =A0 > buzzy without more reasons (this is not a target). So the question : what= =A0 > feature and for which reason ? I do not want to change Ada. I haven't programmed in Ada since 2004. I might start programming in it again sometime though. > Honestly, I feel just a few things are missing to Ada, and this have =A0 > nothing to deal with functional paradigm (which is one among numerous =A0 > others), as these are more subtilities related to what Ada is already, = =A0 > like the topic of extendable enumerations which pops-up again a few days = =A0 > ago. Well you can write functional programs in Ada. It can actually be quite fun. > I personally enjoy the paradigm of functional programing (and many others= =A0 > do, the Ada community is open-mind and enjoy to learn to understand), but= =A0 > this is clearly not Ada's target and its principle of least-surprise =A0 > (predictability). Functional programming better express a modal than a = =A0 > concrete implementation. As I suppose you know, there are many talks abou= t =A0 > the ability of this/that xML compiler to produce efficient binary =A0 > application. Ada clearly has nothing to deal with this kind of question, = =A0 > as talks about Ada compilers even goes the opposite way, and more talks = =A0 > about =93does that compiler really compiles the input it gets without any= =A0 > error or bad alterations ?=94. What you may understand, is that this do = =A0 > exactly the opposite of what a functional programming language compiler i= s =A0 > expected to do. I know the comp.lang.ada is filled with wise and open minded people. This is why I asked if these wise people have thought of combining nice features from both languages. > In shorter words : yes, many people in the Ada world know about FP, its = =A0 > part of their culture; if they use Ada instead of FP (for some things), = =A0 > that is not because they do not know enough about FP; and last, Ada is no= t =A0 > and will never be an FP language (but feel free to create an FP compiler = =A0 > targeting Ada). I know that people here know more than Ada. > If Ada tends to integrate some features, these are more the one suggested= =A0 > by SPARK users expectations (SPARK is a language intended to run formal = =A0 > proofs of correctness on an Ada program) or by some Ada profiles for =A0 > short-memory systems, short time response systems, etc. FP does not reall= y =A0 > help here (well, FP is in some way related to formal proofs, but only in = =A0 > its own language area=85 adding FP features to Ada will not help to make = Ada =A0 > designs easier to prove). I know. I have used SPARK before, and I have built model checker generator in Ada. I know a little bit about formal methods ;-p > Still feel free to tell about your concrete ideas. I was asking for others' vague and concrete ideas. It is pretty difficult to figure out how ML feature and Ada features can be combined. I am working on a gut feeling that the combination could be pretty awesome. t'class would be pretty nice in an ML language.