Re: Getting Started with Lua

["H. Conrad Cunningham" <hcc@...>]

On Wed, Jul 24, 2013 at 3:16 PM, Jay Carlson <nop@nop.com> wrote:
> To be fair, if your goal *is* to be able to build a SqueakVM- or Prescheme-like restricted Lua dialect which maps to C or machine instructions, getting "typical" bare metal ints into the language might help.

I am still formulating my goals.  I had the following thoughts when
choosing Lua:

* It is a language that most of the students (in both the
undergraduate programming languages class and graduate class) do not
know, but it is simple and familiar enough in syntax that they should
be able learn it quickly. I want to use something different, but not
to have to devote much class time to teaching the language.

* It seems to support programming in multiple paradigms reasonably
well--procedural, functional, modular, "object-oriented" ,
nonpreemptive multitasking, language-oriented (using LPEG), etc.  I
want the students to think about programming in different ways.

* Its "mechanisms not policy" approach and extensibility also allow
implementations on top of the basic language -- OO approaches,
concurrency approaches, etc.

* It seems simple and small enough that its design and implementation
could be an object of study itself.

* It could be a reasonable vehicle to use to implement simplified
languages to learn about design and implementation issues.  For
example, the Kamin book I mentioned presents 8 simple languages to
illustrate different language features -- a simple imperative
interpreter with Lisp-like syntax and integers, a "Lisp" extension
that adds S-expressions as data, "APL" that adds vectors and matrices,
"Scheme" that adds first-class functions with lexical scope, "SASL"
that  uses lazy evaluation, "CLU" that adds data abstraction features,
"SmallTalk" that add classes, inheritance, and objects, and "Prolog"
that implements logic programming features.  These ware all
implemented in Pascal and C, with C++ by Budd done later.  Of course,
ideas from Scheme-based books by Friedman et al and Krishnamurhti
might also be sources of ideas.

There are too many interesting threads to follow in one semester.

Of course a disadvantage of Lua for me is that I normally prefer to
work with strictly and strongly typed languages and tend to be
opinionated about good programming "policy".  :)

Also, I have not yet determined what is the best way to structure a
Lua "software family" as represented by the group of interpreters in
the last bullet above.

- Conrad