On 8/19/2011 4:11 PM, David Barbour wrote:
On Fri, Aug 19, 2011 at 11:05 AM, DeNigris Sean<[email protected]> wrote:
After reading many of the LISP suggestions (thanks), the primary features seem
to me to be:
I'm not sure where, if at all, security comes in
Security was, quite understandably, not a major design constraint of
most earlier languages. It falls near 'nowhere to be found' for both
Lisp and Smalltalk. But languages such as Gilad Bracha's Newspeak,
which heavily inspired from Smalltalk, certainly has a security focus.
yep. most security has been traditionally more focused on things like
preventing the OS from being compromised and keeping users on
time-sharing systems in-line.
things like intra-app security, protection from bad scripts, ... are
somewhat newer concerns.
it can also be noted that modern application scripting languages
(Python, Lua, Ruby, ...) have only really risen to prominence in maybe
the past 10-15 years or so.
The big idea is "messaging"
'Messaging' is a problem child of its own. It forces us to write
highly stateful applications, in order to coordinate or orchestrate
multiple devices. Resulting applications are neither resilient nor
robust: a missed, lost, dropped, or delayed message can cause
applications to behave unexpectedly, with no recovery in sight.
it depends some on what exactly one means by "messaging".
if one means something like RPC, CORBA, or DCOM, yeah, these are not
exactly ideal...
granted... these are probably still (generally) better in this sense
than DSM-style systems.
however, I think in-context, "messaging" was in reference to what would
otherwise be termed "method calls", rather than anything having to do
with a network.
Nah, the key idea was stated just a little later in the same paragraph:
Alan Kay wrote (in 1998):
The key in making great and growable systems is much
more to design how its modules communicate rather than
what their internal properties and behaviors should be.
There are a lot of alternatives to messaging as a basis for
composition of and communication between modules, and I think pursuing
them is necessary if we're to see greater and more scalable systems
than we have today.
about the only things "more decoupled" than function or method calls
that I know of is to basically compose much larger messages as globs of
serialized data, which are then passed along via a "pipe" or "socket".
the issue with the above is that it is generally considerably more effort.
another strategy is to basically send out generalized "events", which
are basically "broadcast" to "listeners" and any which may handle the
message may do so, and potentially re-broadcast new events.
"I would say that a system that allowed other metathings to be done in the ordinary
course of programming... is a bad design."
Is this a problem with LISP, where a macro can e.g. magically change what gets
passed to the evaluator?
Not quite. Macros are typically just a local restructuring of code -
i.e. syntactic sugar for something you could have written anyway. But
code-walking macros, and global-state frameworks, and so on are
generally not things that should be done in the ordinary course of
programming.
yep.
typically a macro is a function which is:
executed at compile time;
is passed its arguments as unevaluated expressions;
will produce an expression as output (return value);
the returned expression is then compiled in-place of the macro call.
this is partly why I had before called them "inherently early binding".
trying to late-bind a macro inherently makes it a different sort of
beast from either an early-bound macro, or from an ordinary function
call (assuming the implementation is not sitting around just directly
interpreting input expressions or similar).
as-is, my language doesn't have macros, but it does have quote and
unquote, which could be used "sort of similar" ("quote" is technically
more like "quasiquote" in Scheme, and "unquote" basically either
indicates expressions to be evaluated and substituted in, like in
"quasiquote", or may be used as a sort of "eval the result of this
expression" operator, except it expects an AST rather than a source string).
however, these are not really the same thing as macros.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
