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-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.programming Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Sun, 19 Jul 2009 21:14:52 +0200 Organization: Informatimago Message-ID: <87hbx8bi37.fsf@galatea.local> References: <7cf9peF2758tgU1@mid.individual.net> <1ac0d96f-9dfc-4bcb-abff-2f5cb1c5da8d@e4g2000vbe.googlegroups.com> <87tz18bskg.fsf@galatea.local> <4a635fa9$0$31329$9b4e6d93@newsspool4.arcor-online.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net 4PM+05LAfh9sspEOd44aTQ8SRO5QbsQ1i/b41hwiTfZ+eY3bzG Cancel-Lock: sha1:NWJkOTFjZmU2MmJjM2FkZjJmMGNmNWIxNDQzN2Y2OTMwNDlkZmQyMA== sha1:re5QLzsM9f31dGoOH09P5e8A2Yk= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (darwin) Xref: g2news2.google.com comp.lang.eiffel:317 comp.lang.ada:7156 comp.lang.modula3:43 comp.programming:11847 Date: 2009-07-19T21:14:52+02:00 List-Id: Georg Bauhaus writes: > Pascal J. Bourguignon wrote: > >> Later, when you have a collection of proven algorithms, you may write >> (still in Common Lisp, why reject a winning team?), a translator to >> convert your algorithmic s-exps into the target language of your >> choice, be it Ada, Pascal, C, Eiffel, Fortran, Haskell, Modula-2 or >> Modula-3, whatever you need. It's almost trivial to generate such >> code from a DSL expressed in s-exps. > > How can a translation can be trivial unless it is but a > mere syntactic rewrite? This way one dismisses both an > essential constraint and an opportunity: the programmed > algorithm, the computation, is performed in steps, by a > human, by a Lisp machine, by a von Neumann PU, or by > some innovative parallel computer, each having known > formal properties. Is it possible to let these influence > the s-expressions (the algorithm, that is) such that > the "target language"'s features will be effective? Of course, it depends on your algorithmic language (DSL), and on the target languages. But mostly, it will be trivial, because the target languages are themselves "algorithmic" languages. Nominally, apart from Haskell, all the language mentionned above are mere procedural languages in which imperative algorithms will be trivial to transcribe, yes, basically just a syntactic operation. If we targetted Haskell, Lisp or Prolog, indeed it would be more complex, since procedural algorithms don't translate well there (well for Common Lisp, it would still translate well since Common Lisp is really multi-paradigm a language which includes imperative procedural code (it even has GOTO!), even if an experienced lisp programmer would normally rewrite the imperative algorithms in more idiomatic (higher level) lisp). Moreover, notice how Pr. Knuth use a rather low level language to describe his algorithms (a virtual machine language actually). He doesn't expect anything fancy semantically from his algorithmic language. http://www-cs-faculty.stanford.edu/~knuth/taocp.html Therefore I stand on my affirmation, such a transformation is trivial. -- __Pascal Bourguignon__