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-Thread: 103376,3ef3e78eacf6f938 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!a37g2000prd.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Wed, 24 Mar 2010 13:48:57 -0700 (PDT) Organization: http://groups.google.com Message-ID: <104cd8d2-d4b4-4e47-9780-30746251da2d@a37g2000prd.googlegroups.com> References: <7a0c7a19-5d83-4cc6-be68-95ebf41533e7@t23g2000yqt.googlegroups.com> <3b3f991b-8fcd-435c-83f6-e1a1a5e8f6ed@a31g2000prd.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1269463737 24773 127.0.0.1 (24 Mar 2010 20:48:57 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 24 Mar 2010 20:48:57 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: a37g2000prd.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:10719 Date: 2010-03-24T13:48:57-07:00 List-Id: On Mar 24, 1:00=A0pm, Warren wrote: > Adam Beneschan expounded innews:bf27602c-09c5-45e4-97c1-608bf9729cbb@s2g2= 000prd.googlegroups.com: > >> I smell an interpreter! > > >> >> This doesn't meet my criteria for what I'd call an interpreted > >> >> language. =A0For that, I'd assume that the interpreter reads the > >> >> original source statements, or some sort of tokenized form that > >> >> bears a close relation to the original source statements, while > >> >> running the program. =A0 > > >> That's a pretty narrow view. > > >> Usually ppl talk of "interpreted" vs "native code execution". > >> It would be incorrect IMO to call p-code natively executed > >> code. > > > So it's executed by an interpreter. =A0That doesn't make the *language* > > compiled into p-code an INTERPRETED LANGUAGE, which is what we were > > talking about---not any old "interpreter". > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 -- Adam > > So by your definition, my "tokenized basic" isn't interpreted either? > It saves as an intermediate byte code also. So did GWBASIC IIRC. But > nobody would say that GWBASIC wasn't interpreted. Please read carefully what I wrote earlier: "For that, I'd assume that the interpreter reads the original source statements, or some sort of tokenized form that bears a close relation to the original source statements, while running the program." I don't know what GWBASIC's intermediate byte code looked like. But if it was, in essence, an encoded representation of the source---"that bears a close relation to the original source statements", to quote myself---then it's an interpreted language. p-code does not bear any such relation to the Pascal source. I know that the question of "how close is the byte code to the source" is a fuzzy one. > Sorry, but if any "execution" requires the help of an interpreter, > it is "interpreted" at some level(s), even in Java's case. > > Now if the O/S could load and hand control over control to the > loaded code (exec) without involving a separate process, then > that would be different. Otherwise, I still smell an interpreted > "language". I think your definition of "interpreted language" is too broad to be meaningful. Suppose I had a Pascal compiler that generated code for a processor that is no longer manufactured. So I write a program that emulates that processor. That's effectively an interpreter, but does that make Pascal an interpreted language? Not in any meaningful sense. And what's the difference if the interpreter is for a processor that no longer exists, or for a processor that never existed such as the p-machine? To relate it back to the topic of discussion: I think it was you that claimed that it was meaningless to compare C/C++ results to Java, C#, or Pascal (variants) because the latter were "largely interpreted languages". To be meaningful, a statement like that has to be talking about the language as a whole, not just one or a few idiosyncratic implementations of a language. Some languages are definitely designed to be interpreted---APL, Perl, and Lisp all allow you to build strings or list structures at runtime that can be executed, and then execute them. Also, all of those languages support variables whose types can change during execution, making it difficult to generate efficient machine code. I don't know much about Java, but I believe it was designed to be interpreted (by a virtual Java machine) on different platforms, although apparently it can be compiled; I don't know whether the language design prevents it from being compiled into code that's as efficient as other languages. I don't know anything about C#. Pascal, on the other hand, doesn't have any of the characteristics that make "interpreted languages" what they are. Its variables are statically typed, and there is no built-in facility for parsing and executing a Pascal statement at runtime. Whatever other features there may be that are interesting about "interpreted languages", Pascal doesn't have them. In short, Pascal, as a *language*, is a traditional compiled language and there is absolutely no basis for putting it into the "interpreted language" category, period. The fact that one popular implementation of this language used a virtual machine and an interpreter for that machine is irrelevant. -- Adam