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: border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! Date: Sat, 21 Jun 2014 08:35:52 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1402308235.2520.153.camel@pascal.home.net> <85ioo9yukk.fsf@stephe-leake.org> <255b51cd-b23f-4413-805a-9fea3c70d8b2@googlegroups.com> <5ebe316d-cd84-40fb-a983-9f953f205fef@googlegroups.com> <2100734262424129975.133931laguest-archeia.com@nntp.aioe.org> <857442918424729589.090275laguest-archeia.com@nntp.aioe.org> Injection-Date: Sat, 21 Jun 2014 08:35:52 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="76a49b86bc3e16725b7cfca3d85cb4c8"; logging-data="3861"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18HIOfzaaKmjANzTHISotma" User-Agent: slrn/1.0.1 (FreeBSD) Cancel-Lock: sha1:+Ad6eNPe5/lO0nMGN7j4Qv8GWHs= Xref: number.nntp.dca.giganews.com comp.lang.ada:187105 Date: 2014-06-21T08:35:52+00:00 List-Id: On 2014-06-20, Randy Brukardt wrote: > "Natasha Kerensikova" wrote in message > news:slrnlq7oge.i0l.lithiumcat@nat.rebma.instinctive.eu... > ... >> The way I understand the whole situation is that ASIS provider diversity >> would be a good thing too (though not as much as compiler diversity), >> and Gela is not too far from there, so pushing Gela forward would be a >> good thing both globally and for my self-improvement. > > That would work, of course, but all of the hard stuff (well, almost all) > would be in the GELA ASIS front-end. And you'd have to do frequent > maintenance on the ASIS stuff if you wanted to actually compile Ada (as > almost every bug would be in the ASIS part). It certainly could work, but it > would mean having to understand the GELA ASIS code in detail (not just the > interface). For me, I'd rather fix my own code than someone else's. Funnily, it's the first time I'm warned against re-using code instead of re-writing it, usually I'm warned against re-writing instead of re-using. The thing is, writing an ASIS provider is still frightening me, and I really thing it's not something I can complete by myself. And if I drop a re-write attempt, it's a pure loss. On the other hand, fixing Gela for Adacontrol is within human reach, and it's already a gain by itself, and might be the best way to assess how comfortable I would feel about maintaining Gela in Adacontrol and/or compiler (or other ASIS users) versus starting a new ASIS provider from scratch. >> If that succeeds, it might be a good start for an independent Ada >> compiler, or I might have acquired the certainty that it's not. Then the >> ASIS-to-LLVM-intermediate-form vs brand-new-parser-to-LLVM-IF situation >> will be much easier to assess, and in the meantime I will have acquired >> knowledge and skills that are valuable for both paths. >> >> Sounds good? > > Sounds possible. "Good" only applies if it works out and something useful > comes out of it. :-) Else it's just effort that could have been used on > something working. I meant "does such a plan sound good?". Of course you can't assess result goodness without knowing how everything turns out. Unfortunately, decisions have to be taken without knowing how everything turns out. However, as far as I plans go, it seems I have enough checkpoints and fallbacks to minimize effort loss while still moving towards meaningful goals, unless I'm missing something (and my question is really "with your experience in such endeavors, do you see something I'm missing?"). Thanks for your insights, Natasha