Re: [stack] How the Interpreter Works

I HAD previously fetched several of that site's pages.
But not this one which seems to contain the guts of the applicable theory.
I've started analysing it, but I fear I might find the same
problem, as indicated by my below pAste of a complaint/suggestion
to Usenet on this same topic.  As a student I remember that ususally
when I completed the course and saw the BIG-picture, I always
thought that the material had not been sequenced properly.

j04alg.html too seems to be just a set of bottom-up constructs,
where I can't see what his final aim is.

If/when I finally DO see the big picture, I'll try to structure the
explanation, in a top-down way, instead of just complaining.

Thanks,

== Chris Glur.
--------- extract of previous post to Usenet-groups:-
So far the best fetched material, suggests that what I'm 'looking for'
does exists.  Eg.
   http://www.mactech.com/articles/mactech/Vol.07/07.05/
   LambdaCalculus/

> "A Calculus for the Algebraic-like Manipulation of Computer Code"
> Some of his [optimistic for me] statements are:

> Wouldn't  it  be nice to be able to manipulate computer code in the
> same sort  of  clean  mathematical  way  that  one does algebra?

His 1'000  line article handles [nicely] sequentially:
Intro   to   l-calculus,   LISP   10,  Currying,  Free  Variables  and
Higher-Order Functions, Intro to Combinators, Programming with
Combinators, Church Numerals, Arithmetic Functions, The Y Combinator,
Aftermath; which are each individually understandable sections.

But I can't see how they form an inference chain to the hoped-for
conclusion.

IMO  the  correct  way  to  explain  a  complex  topic  is by backward
chaining.
Ie. top-down decomposition: the same way as programming is best done.
Eg. we want to acheive X,
 which requires X1, X2...Xn,
  which requires X11, X12....X21, X22...

Ie. the goal must be stated up front and be kept in sight and it must
be always clear that/how each step will lead to the goal.
Which is the principle of "Hello world".  Ie. start with a minimal but
complete [up to the conclusion] explanation/statement.  And proceed
by successive refinement.

His article seems to be suggesting the conclusions which I hope for,
namely eg. :
* any algorithm can be expressed in some minimum/cannonical syntax,
* which can be transformed to equivalent syntax[s]: S;
* which satisfy 'mathemetical' rule-set M;
* and allows manipulations P;
* which can arrive at conclusions C, for the original algorithm/code.


On 4/7/07, Christopher Diggins <[email protected]> wrote:
> >
> > On 4/5/07, Christopher Diggins <[email protected]> wrote:
> > > I've written a short article about how the Cat interpreter works on
> > > the Cat wiki
> > > http://code.google.com/p/cat-language/wiki/HowTheInterpreterWorks.
> > > I am hoping that it will help other people who are interested in
> > > learning how to construct interpreters and compilers.
> > >
> > > Any comments or suggestions would be much appreciated!
> > >
> > > Christopher Diggins
> > > http://www.cdiggins.com
> > >
> >On 4/7/07, chris glur <[email protected]> wrote:
> >
> > From a superficial initial read it seems to be a well structured
> > top-down presentation. I've avoided C#, because I don't want
> > to be screwed by M$, but I was able to understand what I
> > examined of the text.
> >
> > I know a bit about compilers/interpreters and it's not clear
> > why I would want to analyse another one. I was hoping that
> > 'concatinative methods' would lead towards a formal
> > [mathematical like] way of anlysing algorithms and/or
> > proving code correctness. Does it ?
> >
>
> Thanks for compliment Chris.
>
> In general the concatenative approach greatly simplifies reasoning
> about algorithms and code. It also simplifies automated translation,
> analysis, compilation, and optimization. Check out Manfred von Thun's
> writing about algebraic manipulation of concatenative code (
> http://www.latrobe.edu.au/philosophy/phimvt/joy/j04alg.html ).
>
> It is common for most compilers to reduce code to a point-free form
> (e.g. nameless) before conducting further analysis, which I think
> testifies to the usefulness of point-free forms (concatenative or
> otherwise). The fact that call-by-push-value semantics (
> http://citeseer.ist.psu.edu/234600.html ) subsumes call by name and
> call by value semantics may also indicate that stack-based approaches
> are perhaps a more general formalism than either of them.
>
> There are of course some who disagree on the value of concatenative
> approaches ( http://lambda-the-ultimate.org/node/2099 )
>
> By the way, the Mono implementation of C# (
> http://www.mono-project.com/ ) is quite good, and the Cat
> implementation has been reported to compile on implementations of
> Mono. So you aren't completely bound to MS, but I understand the
> reluctance.
>
> Hope this helps,
> Christopher Diggins
>