Re: What Lua can do that other programming languages can't do?

[Sean Conner <sean@...>]

It was thus said that the Great Coda Highland once stated:
> On Wed, Mar 6, 2013 at 2:22 PM, José Passes <jose.passes@gmx.com> wrote:
> > On 03/06/2013 09:56 PM, Coda Highland wrote:
> >>
> >> This is a common fallacy. Being Turing-complete only determines what
> >> algorithms you can compute, but there's a lot more to programming than
> >> just algorithms. INTERCAL is Turing-complete, but it can't open any
> >> windows on your screen; Conway's Game of Life is Turing-complete, but
> >> you can't use it as an embedded script interpreter.
> >
> >
> > I'm sure that if you put enough money on the line, someone will be keen to
> > prove you wrong.  Turing-complete is all it is actually required, the rest
> > is just implementation details, and the amount of legwork it would take to
> > prove a point.
> >
> 
> Those implementation details are what define the differences between
> languages, therefore the claim stands. If you did the legwork to
> extend INTERCAL to be able to call C libraries, the resulting language
> would no longer be INTERCAL, but INTERCAL with extensions;
> alternatively, if you wrapped INTERCAL with a shell that parsed the
> output of an INTERCAL algorithm and invoked an outside function based
> on that, you haven't made INTERCAL able to do it but instead you've
> constructed a system that can do it using another language.
> 
> /s/ Adam

  The following video:

http://www.youtube.com/watch?v=xP5-iIeKXE8

shows an implementation of Conway's Game of Life, written in Conways' Game  
of Life.  Granted, the bottom layer of this is written in something else,   
but it's turtles all the way down.                                           
                                                                      
  Let me explain:  Lua (not LuaJIT, but Lua) runs on a virtual byte-machine 
that is interpreted by code written in C.  This C code, in turn, has been   
converted to machine code by a computer.  This machine code, in turn, is
being interpreted by the CPU.  In essence, it's all interpreters, all the   
way down.  

  Further more, if I were to write a CPU emulator in INTERCAL, then load the
C-written library into said emulator so I can "call" routines contained
therein,, do I still have INTERCAL with extensions?  Or just INTERCAL?  And
if someone can "write" Conway's Game of Life, using Conway's Game of Life,
then how difficult could it be to write an embedded script interpreter in
in?

  Turing turtles all the way down ... 

  -spc (Stop all this silliness!  Stop I say! </montypython>)