Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[cbcurl]

On Mar 23, 12:50 pm, Warren <ve3...@gmail.com> wrote:
> I don't think many people would be surprised by these results.
> After all Java, C# and Pascal (variants) are still largely
> interpreted  languages, even if they use some sort of compiled
> intermediate code.

Really?

AFAIK, most Java and C# implementations, JIT-compile to machine code
and are *not* interpreted, and since when was Pascal ever an
interpreted language (perhaps you were thinking of BASIC)?

- C

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[John B. Matthews]

In article 
<7a0c7a19-5d83-4cc6-be68-95ebf41533e7@t23g2000yqt.googlegroups.com>,
 cbcurl <cbcurl@gmail.com> wrote:

> since when was Pascal ever an interpreted language

AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 23, 1:27 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article
> <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.com>,
>
>  cbcurl <cbc...@gmail.com> wrote:
> > since when was Pascal ever an interpreted language
>
> AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.

I wouldn't call it an interpreted language, really.  The UCSD compiler
generated code for a machine that didn't exist, and then programs ran
by interpreting that machine's instructions.  However, my recollection
is that the pseudo-machine's instruction set really didn't have
anything to do with Pascal and could have been used for any language.
A few years later, Western Digital developed a machine that executed
the P-machine's instructions directly (in microcode).  The lab I
worked for back in college (at UC Irvine) used this compiler, and we
had one of the WD machines also, so this is something I'm quite
familiar with, as far as the deteriorating brain cells of my memory
permit.

This doesn't meet my criteria for what I'd call an interpreted
language.  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'd also assume that variables and other identifiers are
stored by name, or by something equivalent such as a pointer into a
string table, but that in any case the interpreter does things "by
name".  In contrast, I believe that UCSD Pascal allocated local stack
variables pretty much the same way a native compiler would,
referencing them via byte or word offsets from the top or bottom of a
stack frame, although it's been a really long time so I could be wrong
here.

                                     -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[John B. Matthews]

In article 
<3b3f991b-8fcd-435c-83f6-e1a1a5e8f6ed@a31g2000prd.googlegroups.com>,
 Adam Beneschan <adam@irvine.com> wrote:

> On Mar 23, 1:27 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > In article
> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.com>,
> >
> >  cbcurl <cbc...@gmail.com> wrote:
> > > since when was Pascal ever an interpreted language
> >
> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.
> 
> I wouldn't call it an interpreted language, really.  The UCSD 
> compiler generated code for a machine that didn't exist, and then 
> programs ran by interpreting that machine's instructions.  However, 
> my recollection is that the pseudo-machine's instruction set really 
> didn't have anything to do with Pascal and could have been used for 
> any language. A few years later, Western Digital developed a machine 
> that executed the P-machine's instructions directly (in microcode).  
> The lab I worked for back in college (at UC Irvine) used this 
> compiler, and we had one of the WD machines also, so this is 
> something I'm quite familiar with, as far as the deteriorating brain 
> cells of my memory permit.
> 
> This doesn't meet my criteria for what I'd call an interpreted 
> language.  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'd also assume that variables and other identifiers are 
> stored by name, or by something equivalent such as a pointer into a 
> string table, but that in any case the interpreter does things "by 
> name".  In contrast, I believe that UCSD Pascal allocated local stack 
> variables pretty much the same way a native compiler would, 
> referencing them via byte or word offsets from the top or bottom of a 
> stack frame, although it's been a really long time so I could be 
> wrong here.

No, I believe you are correct, and you draw a useful distinction. Basic 
interpreters of that era stored tokenized keywords, but the variable 
names--at least the first few characters--were legible in the stored 
program. In contrast, the compiled p-code was quite generic; I briefly 
used a Fortran compiler that generated p-code, and I'm sure others were 
available. The p-code itself was interpreted.

I still enjoy using the system in emulation. As a concrete example,

]list

 10 A% = 12345: PRINT A%

]mtr
*800.81f
00/0800:00 12 08 0A 00 41 25 D0-.....A%P
00/0808:31 32 33 34 35 3A BA 41-12345::A
00/0810:25 00 00 00 64 C1 80 30-%...dA.0
00/0818:39 00 00 00 24 D0 E7 28-9...$Pg(

In Basic, the variable name "A" appears in both the tokenized source and 
the variable table; its value appears as a string literal and a 
twos-complement integer: 16#3039#.

$ ac -e Pascal.2mg test.text
{$R-}
program Test;
var
  a: Integer;
begin
  a := 12345;
  Writeln(a);
end.

$ ac -e Pascal.2mg temp.text
Code file = test.code
The following library bytes are non-zero:

TEST     is a linked segment  (P-code vers.6), length = 42 bytes
** # PROCS = 1, SEGMENT # = 1
Disassembly for procedure # 1; Lex level = 0
P-code procedure 1
Code = 27, parameters = 4, data = 2 bytes; Jump table = 0 words
   0: D7                            NOP    
   1: D7                            NOP    
   2: C7 39 30                      LDCI   12345
   5: AB 03                         SRO    3
   7: B6 01 03                      LOD    1,3
  10: EA                            SLDO 3 
  11: 00                            SLDC 0 
  12: CD 00 0D                      CXP    0,13
  15: 9E 00                         CSP    0
  17: B6 01 03                      LOD    1,3
  20: CD 00 16                      CXP    0,22
  23: 9E 00                         CSP    0
  25: C1 00                         RBP    0

Even without elaborating on the opcodes, it's clear that constant 
remains while variable and procedure names have been elided. When I 
encountered Java bytecode decades later, everything old was new again. 

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

John B. Matthews expounded in news:nospam-E19D5A.22083823032010
@news.aioe.org:

> In article 
> <3b3f991b-8fcd-435c-83f6-e1a1a5e8f6ed@a31g2000prd.googlegroups.com>,
>  Adam Beneschan <adam@irvine.com> wrote:
> 
>> On Mar 23, 1:27 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
>> > In article
>> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.com>,
>> >
>> >  cbcurl <cbc...@gmail.com> wrote:
>> > > since when was Pascal ever an interpreted language
>> >
>> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.
>> 
>> I wouldn't call it an interpreted language, really.  The UCSD 
>> compiler generated code for a machine that didn't exist, and then 
>> programs ran by interpreting that machine's instructions.  
-------------------^^^^^^^^^^^^

I smell an interpreter!

>> This doesn't meet my criteria for what I'd call an interpreted 
>> language.  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.  

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.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 24, 8:23 am, Warren <ve3...@gmail.com> wrote:
> John B. Matthews expounded in news:nospam-E19D5A.22083823032010
> @news.aioe.org:
>
>
>
>
>
> > In article
> > <3b3f991b-8fcd-435c-83f6-e1a1a5e8f...@a31g2000prd.googlegroups.com>,
> >  Adam Beneschan <a...@irvine.com> wrote:
>
> >> On Mar 23, 1:27 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> >> > In article
> >> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.com>,
>
> >> >  cbcurl <cbc...@gmail.com> wrote:
> >> > > since when was Pascal ever an interpreted language
>
> >> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.
>
> >> I wouldn't call it an interpreted language, really.  The UCSD
> >> compiler generated code for a machine that didn't exist, and then
> >> programs ran by interpreting that machine's instructions.  
>
> -------------------^^^^^^^^^^^^
>
> I smell an interpreter!
>
> >> This doesn't meet my criteria for what I'd call an interpreted
> >> language.  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.  
>
> 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.  That doesn't make the *language*
compiled into p-code an INTERPRETED LANGUAGE, which is what we were
talking about---not any old "interpreter".

                                      -- Adam

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]

Adam Beneschan expounded in
news:bf27602c-09c5-45e4-97c1-608bf9729cbb@s2g2000prd.googlegroups.com: 

> On Mar 24, 8:23�am, Warren <ve3...@gmail.com> wrote:
>> John B. Matthews expounded in news:nospam-E19D5A.22083823032010
>> @news.aioe.org:
>>
>>
>>
>>
>>
>> > In article
>> > <3b3f991b-8fcd-435c-83f6-e1a1a5e8f...@a31g2000prd.googlegroups.com>,
>> > �Adam Beneschan <a...@irvine.com> wrote:
>>
>> >> On Mar 23, 1:27�pm, "John B. Matthews" <nos...@nospam.invalid>
>> >> wrote 
>:
>> >> > In article
>> >> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...@t23g2000yqt.googlegroups.co
>> >> > m>, 
>>
>> >> > �cbcurl <cbc...@gmail.com> wrote:
>> >> > > since when was Pascal ever an interpreted language
>>
>> >> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>.
>>
>> >> I wouldn't call it an interpreted language, really. �The UCSD
>> >> compiler generated code for a machine that didn't exist, and then
>> >> programs ran by interpreting that machine's instructions. �
>>
>> -------------------^^^^^^^^^^^^
>>
>> I smell an interpreter!
>>
>> >> This doesn't meet my criteria for what I'd call an interpreted
>> >> language. �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. �
>>
>> 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.  That doesn't make the *language*
> compiled into p-code an INTERPRETED LANGUAGE, which is what we were
> talking about---not any old "interpreter".
> 
>                                       -- 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.

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".

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Adam Beneschan]

On Mar 24, 1:00 pm, Warren <ve3...@gmail.com> wrote:
> Adam Beneschan expounded innews:bf27602c-09c5-45e4-97c1-608bf9729cbb@s2g2000prd.googlegroups.com:

> >> I smell an interpreter!
>
> >> >> This doesn't meet my criteria for what I'd call an interpreted
> >> >> language.  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.  
>
> >> 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.  That doesn't make the *language*
> > compiled into p-code an INTERPRETED LANGUAGE, which is what we were
> > talking about---not any old "interpreter".
>
> >                                       -- 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

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4011 bytes --]

Adam Beneschan expounded in
news:104cd8d2-d4b4-4e47-9780-30746251da2d@a37g2000prd.googlegroups.com: 

> On Mar 24, 1:00�pm, Warren <ve3...@gmail.com> wrote:
>> Adam Beneschan expounded
>> innews:bf27602c-09c5-45e4-97c1-608bf9729cbb@s2g2 
> 000prd.googlegroups.com:
> 
>> >> I smell an interpreter!
..
>> 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."

Apart from efficiencies, what does "close relation to source" have to
do with it? You still have another program "interpreting" it to 
carry out the instructions coded, in the original source.

> ..  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.

Yep, but except where you have the interpreter in hardware, 
it is still interpreted. Of course hardware often uses 
software also (microcode), but usually people draw the
line at that boundary.

>> 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.  

It's clear cut. If you need another executable to run it, then it's
interpreted. Though I will grant that there are a couple of exceptions
here also- the cobrun command that Open Cobol uses is a main program
stub that dynamically calls a cobol module (as a shared library) to 
load and execute it. But the same code can be compiled into a stand
alone executable -- and neither of these are interpreted.

> 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.  

People usually call that "emulation".

> That's effectively an interpreter, but does
> that make Pascal an interpreted language?  

No. This is where the word emulator makes a useful distinction.

> 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?

Emulated theoretical concept of a machine code is usually
just viewed interpreted code. However modern usage has also 
brought in the idea of a "virtual machine". I think that is
more of a marketing concept than a useful term.

> 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".  

I didn't say it was meaningless- just that there is no surprise
in that (aside prehaps from truly compiled Pascal).

> .. 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.  

I'll disagree about the p-code implementation, but would otherwise
generally agree.

> The fact
> that one popular implementation of this language used a virtual
> machine and an interpreter for that machine is irrelevant.
>                                      -- Adam

It's not irrelevant, unless you _qualify_ what you're talking 
about. Otherwise some poor saps with a different background
in Pascal may come away with different and incorrect conclusions.

The fact that it was _popular_ means you have to deal with it
when making statements about the language's performance.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 25.03.2010, 14:45 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> The fact that it was _popular_ means you have to deal with it
> when making statements about the language's performance.

It was never as popular as Turbo Pascal. I can think of 2 p-code pascals:  
The original With pascal and USCS Pascal. I can think of five which  
compile native: Kyan Pascal, Oregon Pascal, GNU-Pascal, Free-Pascal and  
last but most important one: Turbo Pascal now Delphi. The sales and use of  
the later probably dwarfing the combined rest.

And that is out of the top of my head without google research. You are  
just plain wrong. Pascal was not designed as an interpreted language, most  
implementations are not interpreted the most popular implementation is not  
interpreted. You can turn in any way you like - the result is always the  
same: Pascal is not an interpreted language.

Regards

Martin
-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in
news:op.u951g6eyz25lew@macpro-eth1.krischik.com: 

> Am 25.03.2010, 14:45 Uhr, schrieb Warren <ve3wwg@gmail.com>:
> 
>> The fact that it was _popular_ means you have to deal with it
>> when making statements about the language's performance.
> 
> It was never as popular as Turbo Pascal. I can think of 2 p-code
> pascals:  The original With pascal and USCS Pascal. I can think of
> five which  compile native...
> 
> Martin

It was never a popularity contest ;-)  The fact that people
see it as "popular" (whether first place or last), means that 
a mention of Pascal needs to be a qualified one.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 26.03.2010, 19:21 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> Martin Krischik expounded in
> news:op.u951g6eyz25lew@macpro-eth1.krischik.com:
>
>> Am 25.03.2010, 14:45 Uhr, schrieb Warren <ve3wwg@gmail.com>:
>>
>>> The fact that it was _popular_ means you have to deal with it
>>> when making statements about the language's performance.
>>
>> It was never as popular as Turbo Pascal. I can think of 2 p-code
>> pascals:  The original With pascal and USCS Pascal. I can think of
>> five which  compile native...
>>
>> Martin
>
> It was never a popularity contest ;-)  The fact that people
> see it as "popular" (whether first place or last), means that
> a mention of Pascal needs to be a qualified one.

That would be "saw" it as popular. UCSD Pascal is dead long ago. You are  
clinging on the very last straw here to keep your argument up!

Martin

-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in
news:op.u996t11wz25lew@macpro-eth1.krischik.com: 

> That would be "saw" it as popular. UCSD Pascal is dead long ago. You
> are  clinging on the very last straw here to keep your argument up!
> 
> Martin

I disagree. ;-)

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 24.03.2010, 21:00 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> Otherwise, I still smell an interpreted
> "language".

As I already pointed out: I only say it is an interpreted *language* if  
the majority of *implementations* are interpreted. There are two different  
overlapping groups but they are not identical.

Martin
-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 24.03.2010, 17:57 Uhr, schrieb Adam Beneschan <adam@irvine.com>:

> So it's executed by an interpreter.  That doesn't make the *language*
> compiled into p-code an INTERPRETED LANGUAGE, which is what we were
> talking about---not any old "interpreter".

My personal definition is that a language is interpreted if the majority  
of implementations use an interpreter. And Pascal would not be among the  
list.

Martin

-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in
news:op.u950lqpyz25lew@macpro-eth1.krischik.com: 

> Am 24.03.2010, 17:57 Uhr, schrieb Adam Beneschan <adam@irvine.com>:
> 
>> So it's executed by an interpreter.  That doesn't make the *language*
>> compiled into p-code an INTERPRETED LANGUAGE, which is what we were
>> talking about---not any old "interpreter".
> 
> My personal definition is that a language is interpreted if the
> majority  of implementations use an interpreter. And Pascal would not
> be among the  list.
> 
> Martin

I still maintain you need to be specific about it. I will 
agree that they all were not interpreted. But at the same 
time it is equally wrong to imply that they were all compiled.

Warren

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Martin Krischik]

Am 26.03.2010, 19:24 Uhr, schrieb Warren <ve3wwg@gmail.com>:

> Martin Krischik expounded in
> news:op.u950lqpyz25lew@macpro-eth1.krischik.com:
>
>> Am 24.03.2010, 17:57 Uhr, schrieb Adam Beneschan <adam@irvine.com>:
>>
>>> So it's executed by an interpreter.  That doesn't make the *language*
>>> compiled into p-code an INTERPRETED LANGUAGE, which is what we were
>>> talking about---not any old "interpreter".
>>
>> My personal definition is that a language is interpreted if the
>> majority  of implementations use an interpreter. And Pascal would not
>> be among the  list.
>>
>> Martin
>
> I still maintain you need to be specific about it. I will
> agree that they all were not interpreted. But at the same
> time it is equally wrong to imply that they were all compiled.

I make it simple for you:

Pascal: language, not interpreted
UCSD-Pascal, language *implementation*, interpreted.

As you say: you have to be specific.

Martin

-- 
Martin Krischik

Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Warren]

Martin Krischik expounded in news:op.u9958tkwz25lew@macpro-
eth1.krischik.com:

>> I still maintain you need to be specific about it. I will
>> agree that they all were not interpreted. But at the same
>> time it is equally wrong to imply that they were all compiled.
> 
> I make it simple for you:
> 
> Pascal: language, not interpreted
> UCSD-Pascal, language *implementation*, interpreted.
> 
> As you say: you have to be specific.
> 
> Martin

The reason it's important here to distinguish, is that one might
assume "interpreted" by its quoted performance level. I recognize 
that p-code went out of fashion a long time ago, but for clarity..

"The prosecution rests."

Warren

Interpreted vs. Compiled

[Ludovic Brenta]

I do not think any language can be said to be "interpreted" or
"compiled".  Instead, any *implementation* of any language can be
"interpreted", "compiled" or something in between.  It is almost a
continuum.

Interpreted, stricto sensu, means that the interpreter reads the sources
of the program as written by the human programmer.

In between: byte-code compilers, P-Code.

Just-in-time compilers usually compile byte-code to native processor
code on the fly.

Compiled means that the hardware processors runs the program directly,
even if, inside the hardware, some additional transformations can take
place for efficiency.

Some implentations of BASIC are interpreted, others are compiled.

Some implementations of Lisp are interpreted (emacs lisp), others are
byte-compiled (also emacs lisp), others still are compiled (GNU Common
Lisp).

Some implementations of Java are byte-compiled (Sun Java compiler),
others still are compiled (GCC).

Even one implementation of Ada, Ada/Ed, was interpreted!

You get the drift.

-- 
Ludovic Brenta.

Re: Interpreted vs. Compiled

[Warren]

Ludovic Brenta expounded in news:87k4sunb9u.fsf_-_@ludovic-brenta.org:

> I do not think any language can be said to be "interpreted" or
> "compiled".  Instead, any *implementation* of any language can be
> "interpreted", "compiled" or something in between.  It is almost a
> continuum.

Under Unix, it is generally accepted that if a 3rd-party
(not o/s and not so-called executable) process is required,
it is known as the "interpreter". 

Linux for example used to (probably still does) have the 
ability to register the "interpreter". This was done with 
the JVM. Once the JVM was registered, you could launch the 
byte-code as if it were a native executable-- which is 
obviously slight-of-hand, since there is the necessary 
invoking of the "interpreter" as well (it is not purely
the o/s being used).

Now I only mention "this" particular view (as before) of an 
interpreter for the very simple utilitarian reason that 
once you realize that an interpreting "middleman" is 
involved, it is very obvious (i.e. not surprising) 
that it runs less efficiently than other native code
options.

Any other concept of "interpreter" in this discussion of
performance is less interesting in this context. 

BTW, emulation leads to the same conclusion as
an interpreter, since it too is "interpreting", even if
one doesn't usually call it that.

> Interpreted, stricto sensu, means that the interpreter reads the 
> sources of the program as written by the human programmer.

I should probably shutup, but you do know that many of
"those" interpreters also use an intermediate code in
memory. So just because they don't store it in a file 
that way, doesn't make them any more special IMO.

> You get the drift.

Yep. Yep. 

Warren