If you have a language written in itself the advantages are?
1. You can extend it right there on the fly.
2. ?
Is speed increased? Depends perhaps but most languages are written in
C so if the alternative is writing the language in itself, will that
make it faster?
There is some Python-implementationn that claims to be faster than
Python itself, I think because it is written in Python itself. However
the cPython documentation mentions C as a speed advantage.
defn noob <············@yahoo.se> writes:
> If you have a language written in itself the advantages are?
> 1. You can extend it right there on the fly.
Yes and no. Extending it is a bit easier since it is a language that
you are already familiar, since you are presumably already using it.
Whether you can extend it "on the fly" depends on whether the language
has the appropriate dynamic linking abilities. Lisp can be modified
while running because of the dynamic linking. Other language may need
to be re-compiled before any extensions become available.
>
> 2. ?
o You get the benefits of the language it is written in to use when
implementing the language.
o You get portability advantages by having the bulk of the code in a
single, high-level language, namely the language you are
implementing.
> Is speed increased? Depends perhaps but most languages are written in
> C so if the alternative is writing the language in itself, will that
> make it faster?
Speed is not necessarily increased. That all depends on the quality of
the implementation, which is to a lesser or greater degree independent
of the language used to implement the language itself.
Note that languages actually don't execute in C (at least I'm not aware
of any native-C machines), but rather in some machine code. If whatever
compiler you write for your language emits good, optimized machine code,
then it will be fast. This is completely independent of what language
the compiler is actually written in. It is possible to write bad code
in any language.
So, a lisp compiler written in lisp can (and many existing
implementations do) produce very good, efficient machine code.
Certainly Allegro, Lispworks, Clozure/Macintosh, CMUCL and SBCL all
produce very good code. I'm not familiar enough with CLISP to be able
to comment on its compiler output quality.
Now, certain compiler optimizations are easier to write in a higher
level language like lisp, so there are some things that can be exploited
to make generating good machine code easier.
In any case, no matter what the language, there has to be some initial
boot-strapping procedure to get any new programming language (including
C) to run on a new processor architecture. But once a (usually simple)
base is bootstrapped, a fully native implementation can be brought up.
Now, for various reasons, it is sometimes convenient to construct hybrid
systems where more than one language is used in the implementation.
That allows you to use a greater variety of tools, applying each one in
the area where it is most appropriate.
> There is some Python-implementationn that claims to be faster than
> Python itself, I think because it is written in Python itself. However
> the cPython documentation mentions C as a speed advantage.
The implementation language is irrelevant. The important measure is the
quality of the implementation.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Kaz Kylheku
Subject: Re: Speed advantage of language written in itself?
Date:
Message-ID: <20080822170333.535@gmail.com>
On 2008-08-22, defn noob <············@yahoo.se> wrote:
> If you have a language written in itself the advantages are?
The advantages are that you can ooze superiority out of your pores.
>
> 1. You can extend it right there on the fly.
Not necessarily. C compilers are often written in C, yet their technology is
such that you can't extend C on the fly.
Even dynamically loading functions is a chore which requires considerable
infrastructure that doesn't come with the language.
Forget about adding new syntax on the fly.
> 2. ?
>
>
> Is speed increased?
No. Doh?
> Depends perhaps but most languages are written in
> C so if the alternative is writing the language in itself, will that
> make it faster?
Speed is achieved by compiling a language into machine language (and of course
it matters how cleverly this is done). From the perspective of generating code,
it's irrelevant what the translator is written in.
It's the compiling algorithm that matters.
Do yourself and everyone else a favor and Google for ``algorithm''.
> There is some Python-implementationn that claims to be faster than
> Python itself
You can't compare a language to an implementation. We wouldn't say that ``GNU C
is a C implementation which is faster than C itself''.
Python can be said to be exactly as fast (whatever that means) as its best
implementation. Logically speaking, an implementation of Python can't be
faster than Python.
A Python compiler (whether it is written in Python or anything else) would
hopefully transform Python programs into a representation that executes faster
than Python programs that are interpreted by the popular C Python
implementation.
The difference in performance would be due to compiling versus interpreting,
not due to the compiler being written in Python and the interpreter in C.
> the cPython documentation mentions C as a speed advantage.
That would be in the context of interpreting. C is probably not a bad language
for writing a fast /interpreter/ for Python. However, if a programming language
implementation is purely interpreted, there is no point in bragging about its
performance in the user manual, because the designers haven't taken the obvious
optimization step of developing a compiler. It's analogous to touting a
wonderfully hand-tuned assembly language version of bubble sort.
From: Joost Diepenmaat
Subject: Re: Speed advantage of language written in itself?
Date:
Message-ID: <87pro0y8ih.fsf@zeekat.nl>
defn noob <············@yahoo.se> writes:
> If you have a language written in itself the advantages
>
> 1. You can extend it right there on the fly.
You can extend languages that aren't implemented in themselves on the
fly too. Any language that allows you to load a subroutine can do
that. Lots of languages even do that quite easily. Lisp allows for a
lot of freedom to extend the language, but that has nothing to do with
wether or not the particular environment is implemented in lisp or or.
Implementing a language in the language itself (or *mostly* in the
language itself) just means you don't have to learn another language
to mess with the implementation. And you might not be held back by the
limitations of the "lower-level" language, which may or may not mean
you can optimize better. It all depends.
> 2. ?
>
>
> Is speed increased? Depends perhaps but most languages are written in
> C so if the alternative is writing the language in itself, will that
> make it faster?
Lots of languages aren't implemented in C. C is just a convenient
gateway to the API of many operating systems. And C is pretty fast, if
written to be fast.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
defn noob wrote:
> If you have a language written in itself the advantages are?
>
> 1. You can extend it right there on the fly.
>
> 2. ?
>
>
> Is speed increased? Depends perhaps but most languages are written in
> C so if the alternative is writing the language in itself, will that
> make it faster?
>
> There is some Python-implementationn that claims to be faster than
> Python itself, I think because it is written in Python itself. However
> the cPython documentation mentions C as a speed advantage.
Whether a language is implemented in itself or not is completely
independent from whether the implementation is efficient or not.
The cPython documentation mentions C as a speed advantage because the
authors of that documentation don't know what they are talking about.
cPython is implemented as a naive interpreter, and naive interpreters
are always slow. Yes, a naive interpreter in C is probably more
efficient than a naive interpreter in, say, Python.
However, you are probably referring to the PyPy project, a Python
virtual machine implemented in Python. In that approach, they use a
partial evaluator to generate a JIT compiler for Python. Yes, PyPy is
implemented in Python itself, but the efficiency comes from the JIT
compilation, not from the choice of implementation language.
So what matters here is (a) choose the right implementation approach and
then (b) choose the right language for that implementation approach
(usually Common Lisp ;).
Lisp is traditionally described using a metacircular interpreter. The
classic metacircular interpreter is a naive interpreter, and is
therefore quite slow. The metacircularity is primarily interesting from
an educational and from a theoretical perspective. [1]
Pascal
[1] It is also interesting because it is a starting point for adding
reflection to a language, but that's a different story...
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Aug 22, 6:54 pm, Pascal Costanza <····@p-cos.net> wrote:
> defn noob wrote:
> > If you have a language written in itself the advantages are?
>
> > 1. You can extend it right there on the fly.
>
> > 2. ?
>
> > Is speed increased? Depends perhaps but most languages are written in
> > C so if the alternative is writing the language in itself, will that
> > make it faster?
>
There are good software engineering reasons to build a language
processor in itself. The biggest is that you will discover problems
with your implementation (aka interesting bugs) that only show up in a
complex application. Other reasons are human-based. It's a big
milestone that the team can be proud of. It also fires up the team
when they see the language processor executing a complex problem. The
CLforJava project got to that point last semester, and a couple of
students will be working on a new compiler written in CLforJava over
the next couple of semesters. And yes, it is easier to write a
compiler in Lisp than in Java!
In article <··············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> defn noob wrote:
> > If you have a language written in itself the advantages are?
> >
> > 1. You can extend it right there on the fly.
> >
> > 2. ?
> >
> >
> > Is speed increased? Depends perhaps but most languages are written in
> > C so if the alternative is writing the language in itself, will that
> > make it faster?
> >
> > There is some Python-implementationn that claims to be faster than
> > Python itself, I think because it is written in Python itself. However
> > the cPython documentation mentions C as a speed advantage.
>
> Whether a language is implemented in itself or not is completely
> independent from whether the implementation is efficient or not.
>
> The cPython documentation mentions C as a speed advantage because the
> authors of that documentation don't know what they are talking about.
> cPython is implemented as a naive interpreter, and naive interpreters
> are always slow. Yes, a naive interpreter in C is probably more
> efficient than a naive interpreter in, say, Python.
Is the CPython implementation really a naive interpreter? From the little
I read it kind of compiles Python code to bytecode which
then is executed by a VM? I would not say this is naive interpretation.
> However, you are probably referring to the PyPy project, a Python
> virtual machine implemented in Python. In that approach, they use a
> partial evaluator to generate a JIT compiler for Python. Yes, PyPy is
> implemented in Python itself, but the efficiency comes from the JIT
> compilation, not from the choice of implementation language.
>
> So what matters here is (a) choose the right implementation approach and
> then (b) choose the right language for that implementation approach
> (usually Common Lisp ;).
>
> Lisp is traditionally described using a metacircular interpreter. The
> classic metacircular interpreter is a naive interpreter, and is
> therefore quite slow. The metacircularity is primarily interesting from
> an educational and from a theoretical perspective. [1]
>
> Pascal
>
> [1] It is also interesting because it is a starting point for adding
> reflection to a language, but that's a different story...
--
http://lispm.dyndns.org/
On Sat, 23 Aug 2008 09:37:57 +0200, Rainer Joswig wrote:
> Is the CPython implementation really a naive interpreter? From the
> little I read it kind of compiles Python code to bytecode which then is
> executed by a VM? I would not say this is naive interpretation.
After one has used, for example, SBCL, what you describe above does sound
like a naive implementation.
Tamas
In article <··············@mid.individual.net>,
Tamas K Papp <······@gmail.com> wrote:
> On Sat, 23 Aug 2008 09:37:57 +0200, Rainer Joswig wrote:
>
> > Is the CPython implementation really a naive interpreter? From the
> > little I read it kind of compiles Python code to bytecode which then is
> > executed by a VM? I would not say this is naive interpretation.
>
> After one has used, for example, SBCL, what you describe above does sound
> like a naive implementation.
>
> Tamas
I usually associate the term 'naive interpreter'
with an interpreter that does little or no
pre-compilation, caching or other implementation tricks.
It is like Lisp interpreters that were
interpreting the source forms and were for example macro
expanding the same form over and over (in recursive
calls for example).
I don't think a compilation to byte code and
execution of that bytecode is necessarily 'naive'.
It's already a huge step up from a simple
source based interpreter.
The bytecode interpreter implementation (the VM) can be naive.
But is it in this case?
--
http://lispm.dyndns.org/
Rainer Joswig wrote:
> In article <··············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> defn noob wrote:
>>> If you have a language written in itself the advantages are?
>>>
>>> 1. You can extend it right there on the fly.
>>>
>>> 2. ?
>>>
>>>
>>> Is speed increased? Depends perhaps but most languages are written in
>>> C so if the alternative is writing the language in itself, will that
>>> make it faster?
>>>
>>> There is some Python-implementationn that claims to be faster than
>>> Python itself, I think because it is written in Python itself. However
>>> the cPython documentation mentions C as a speed advantage.
>> Whether a language is implemented in itself or not is completely
>> independent from whether the implementation is efficient or not.
>>
>> The cPython documentation mentions C as a speed advantage because the
>> authors of that documentation don't know what they are talking about.
>> cPython is implemented as a naive interpreter, and naive interpreters
>> are always slow. Yes, a naive interpreter in C is probably more
>> efficient than a naive interpreter in, say, Python.
>
> Is the CPython implementation really a naive interpreter? From the little
> I read it kind of compiles Python code to bytecode which
> then is executed by a VM? I would not say this is naive interpretation.
The bytecode interpreter is naive.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
defn noob wrote:
> If you have a language written in itself the advantages are?
>
> 1. You can extend it right there on the fly.
>
> 2. ?
You get to use the language when working on the language.
kt
Kenny <·········@gmail.com> writes:
> defn noob wrote:
>> If you have a language written in itself the advantages are?
>> 1. You can extend it right there on the fly.
>> 2. ?
>
> You get to use the language when working on the language.
Which is the main reason you're writing a new language implementation
in the first place, to stop having to use the previous blub language
as soon as possible.
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
On Aug 22, 6:08 pm, defn noob <············@yahoo.se> wrote:
> If you have a language written in itself the advantages are?
1. Bug source reduction: Once the implementation runs or compiles
itself, you don't need to worry about bugs in a separate compiler
causing problems in yours.
2. Testing efficiency: The implementation itself effectively becomes a
component of its own test suite. There's also a simple probabilistic
argument that when applied to a given test suite, a bug is more likely
to be found in a system that runs or compiles itself than in one that
doesn't.
3. Positive reinforcement: There is immediate reward as you implement
optimizations: your own build/test cycles go faster!
Gene wrote:
> On Aug 22, 6:08 pm, defn noob <············@yahoo.se> wrote:
>> If you have a language written in itself the advantages are?
>
> 1. Bug source reduction: Once the implementation runs or compiles
> itself, you don't need to worry about bugs in a separate compiler
> causing problems in yours.
> 2. Testing efficiency: The implementation itself effectively becomes a
> component of its own test suite. There's also a simple probabilistic
> argument that when applied to a given test suite, a bug is more likely
> to be found in a system that runs or compiles itself than in one that
> doesn't.
> 3. Positive reinforcement: There is immediate reward as you implement
> optimizations: your own build/test cycles go faster!
There are also disadvantages. For example, there is a danger that the
programming language becomes a domain-specific language for implementing
itself, while for actual applications, a different feature set with
different semantics may be more useful.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/