Re: Zoom out

["Russell Y. Webb" <rw20@...>]

Good description, John.  I've been thinking along the same lines.

Would it be too limiting to assume a POSIX compliant system?  Dynamically
loaded modules in C are the only thing I can think of that are not in POSIX.
Maybe external POSIX modules could be implemented as separate programs that
provide services though some IPC mechanism (think BeOS messages) and then
just an IPC layer needs to be ported to different platforms.

Russ

> From: John Belmonte <jvb@prairienet.org>
> Reply-To: lua-l@tecgraf.puc-rio.br
> Date: Sat, 2 Feb 2002 15:21:10 +0900
> To: Multiple recipients of list <lua-l@tecgraf.puc-rio.br>
> Subject: Zoom out
> 
> Even though I'm in Lua's "embedded camp", and am already satisfied
> with Python for system programming tasks, I can certainly understand
> the view of people like Philippe.  Indeed, if a system programming
> environment with Lua's simple style and Python or Perl's reach
> existed, I would be eager to use it also.
> 
> However, Lua has the ANSI C constraint.  More limiting, the authors
> are careful that the language be useful even if a file system is not
> available.  These two constraints make Lua wonderful for embedded
> programming.  Being limited to ANSI C has another advantage, as it
> forms a well-defined boundary on the Lua distribution's realm.  I
> think it keeps the Lua authors focused on the language, not on making
> system programming libraries such as those included with other
> scripting languages.  This in turn avoids having to impose an
> implementation of classes and other higher-level constructs which would
> be required to support big libraries.
> 
> What we have are the ingredients to make something new-- an efficient
> scripting core with a simple style and well-defined C interface, and a
> growing group of people who would like to see a system programming
> environment based on that core.  You can image that inside Perl and
> Python are cores similar to Lua-- not well defined because they never
> existed independent of their high-level scripting language-- but cores
> nonetheless.  (The fact that the functionality of Lua is equivalent to
> the core of these heavier languages, together with the focus given by
> the Lua authors, is the reason it runs so much faster.)  So here is an
> opportunity to make a high-level system scripting language from the
> bottom up, instead of top-down.  Not only that, but you have an
> experienced team working on the core.
> 
> So what I'm suggesting is that someone, or some group, take charge of
> this new thing.  Give it a mailing list and development site.  But
> most importantly, take a new perspective-- don't call it Lua, even if
> by license you can.