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.224.172.200 with SMTP id m8mr6697154qaz.0.1364260515247; Mon, 25 Mar 2013 18:15:15 -0700 (PDT) X-Received: by 10.50.27.1 with SMTP id p1mr3805igg.11.1364260515207; Mon, 25 Mar 2013 18:15:15 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!ca1no7193180qab.0!news-out.google.com!k8ni11100qas.0!nntp.google.com!ca1no7193178qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 25 Mar 2013 18:15:14 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.20.190.126; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 69.20.190.126 References: <99929f93-b80f-47c3-8a37-c81002733754@googlegroups.com> <87ec4b1d-f7cd-49a4-8cff-d44aeb76a1ad@googlegroups.com> <78103a2f-5d19-4378-b211-1917175d5694@googlegroups.com> <3p6p8k0yfly7.ctazdw7fc5so$.dlg@40tude.net> <1jtvzi1v65aqm.1k5ejsveno59f.dlg@40tude.net> <1hvv2kd9smnfx.6spgz9thd1mh$.dlg@40tude.net> <1raubw1sk48ca$.69rdgczvnnf.dlg@40tude.net> <2qwq2cdeuvhu$.qtnb8zyhuob9$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Is this expected behavior or not From: Shark8 Injection-Date: Tue, 26 Mar 2013 01:15:15 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 5646 Xref: number.nntp.dca.giganews.com comp.lang.ada:180773 Date: 2013-03-25T18:15:14-07:00 List-Id: On Monday, March 25, 2013 4:24:10 PM UTC-6, Randy Brukardt wrote: > "Shark8" wrote in message=20 >=20 > news:c231e327-0859-4430-adfc-ed4de4de2208@googlegroups.com... >=20 > > On Friday, March 22, 2013 8:33:02 PM UTC-6, Randy Brukardt wrote: > >> > >> I'd never trust any program with more than a handful of generics, it's= =20 > >> just > >> too hard to get the compilers to handle those right). > > > > That seems a bit odd... I would think that once you had a generic* meth= od=20 > > for handling overloading you could apply that to generics as well. > > > > [* Pun intended.] >=20 > It's the combination of a wealth of things, overloading is the easy one. After posting -- and thinking about it a little more -- I did suspect that = would be the case. {Though I would certainly love to hear the "whyfor" it's= harder than overloading.} > Certainly a shared implementation (like the one in Janus/Ada) makes=20 > everything harder, That reminds me: I need to consider getting a copy of Janus/Ada when/if I e= ver restart my OS-project idea. -- I do think an OS based entirely in Ada {= except, *maybe*, the boot-loader} could be a much better foundation than th= e [general purpose] OSes we currently have. > but there are enough oddities in the handling of formals=20 > that it won't ever be easy. Well, that's understandable given that generic [packages] have a lot more l= eeway in their 'discriminants' than discriminated-records. {According to ht= tp://www.cs.dartmouth.edu/reports/TR86-104.pdf records and generic-packages= have a lot of overlap such that they are virtually entirely interchangeabl= e... though this does raise the interesting possibility of unifying, on "th= e underside" of a compiler, a common format to handle both.} But speaking of unifying things, would it make things easier to have Float = and Fixed unified w/ a common base? {So that, say, one could have an algori= thm parametrized w/ one or the other and still work -- that could be useful= for DSP and other embedded systems.} Perhaps a Universal_Radix could be im= agined as the 'Base of Universal_Fixed and Universal_Float, having all the = asthmatic-functions [and aspects and attributes] common to both. > It's really the result of having a strong=20 > contract model for generics; that prevents using simple textual substitut= ion=20 > for thing. > I'm pretty sure textual substitution is almost always the wrong answer. When I was working on a web-based program (handling medical records[!]) one= of the modules included text-based merge-fields using textual substitution= ... it was horribly, horribly fragile. > Of course, you need a strong contract model if you want the=20 > generic to be correct without knowing anything about the instantiations.= =20 > (Same as you do for subprograms.) True -- though if Ada does get a bit more attention/popularity there's like= ly going to be a push for the ARG to reduce contracts's strength. I think a= lot of some [new to Ada] people's difficulties could be alleviated somewha= t by subverting their wish to subvert the type-system with, perhaps, a user= -defined attribute "To_Type'Convert( From_Type_Var )" used in much the same= manner we handle stream-attributes... though it would have to support over= loading (and I'm not sure that is such a good idea in an attribute).