Thank you Arthur. Indeed Lisp in Small Pieces cites this paper in the
chapter about fast interpreters among two others but sadly in French :)
On Thursday, 30 July 2020 15:45:01 UTC+1, Arthur Nunes-Harwitt wrote:
>
> Hi,
>
>While you're enumerating these possibilities, I think it's
Hi,
While you're enumerating these possibilities, I think it's worthwhile to
mention a technique related to the FORTH implementation technique: Marc
Feeley style compilation (see "Using Closures For Code Generation" in
Computer Language Vol 12 No 1 pages 47-66). This idea is also mentioned
>
> -- hendrik
>
> I hope this set of answers clarifies the distinction between an
> interpeter and compiler, how the distinction gets blurred in practice,
> and what the criteria are for choosng between them.
>
This was both detailed, insightful and truly helpful. I can't thank you
enough
On Wed, Jul 29, 2020 at 01:56:05AM -0700, zeRusski wrote:
> This is a really cool piece of history! Thank you.
>
> I'll admit I'm somewhat fuzzy here - it maybe a bit too meta for me or
> perhaps I don't quite understand what you're trying to say. Isn't
> interpreting n levels deep also linear
This is a really cool piece of history! Thank you.
I'll admit I'm somewhat fuzzy here - it maybe a bit too meta for me or
perhaps I don't quite understand what you're trying to say. Isn't
interpreting n levels deep also linear in n? Only difference between the
two approaches I see is that
On Mon, Jul 27, 2020 at 11:07:43AM -0700, zeRusski wrote:
>
> >
> > The best way to distinguish compilers from interpreters is that a
> > compiler takes a program and produces another program, whereas an
> > interpreter takes a program (along with some input) and produces an
> > answer.
> >
>
>
> The best way to distinguish compilers from interpreters is that a
> compiler takes a program and produces another program, whereas an
> interpreter takes a program (along with some input) and produces an
> answer.
>
Doesn't this trivialize the difference a bit too much? Does it really
A few thoughts on interpreters vs compilers:
- somewhere, there has to be an interpreter -- the x86 chip in my
laptop is interpreting the x86 code that Racket generates.
- there could certainly be a more direct AST-based interpreter for
(fully-expanded) Racket. My work on Pycket involved writing
Thank you for this fantastic reply Sam! I now think I had a very naive
model of "interpreter" when I asked the question. My CS degree from the
nowhere university has it that language interpreters walk the tree and you
know "execute" be it in the host language or generating native code. I feel
Hi,
Racket BC (the non-Chez version) does use an interpreter. The pipeline
in Racket BC is
source code => expanded code => compiled bytecode => interpreter
or
source code => expanded code => compiled bytecode => JIT compiler
=> machine code
You can turn off the JIT compiler with the
Hi all. I wonder if such a thing exist or even possible? Question triggered
by the trade off between "compile slowly now to run fast later" vs "start
fast". Racket like other modern(ish) Scheme derivatives appear to have
settled on being in the former camp. Is there anything in the language
11 matches
Mail list logo
