On 6/14/2011 2:31 PM, John Nilsson wrote:
On both questions the answer is basically that Java was an example. I
was looking for a general solution. Something that would work withoug
prior assumptions about the languages involved.
The problem I was thinking about was how to provide an infrastructure
where in anyone could be a language designer and almost for free get
all the tooling support required for the language to gain traction. It
seems to me that the effort required to go from an itch to a fully
mainstream language is waaaaay to high. And partly to blame why we are
still introducing inventions from the sixties in current mainstream
languages.
possibly, "opening up" the implementation more...
namely:
the parser produces an AST, in a form that user-written code can work
with (one possibility being a List/S-Expression based form, or an
XML-based format);
allowing code to create its own ASTs and feed them into the compiler/VM;
also allowing easy access to the ByteCode / IL (the JVM does this fairly
well, for example, it is possible to produce class-objects and feed them
into the JVM);
access to low-level facilities;
reflection, ...
as well as possibly the ability to register "plug in" features at most
levels, such that applications can "extend" layers without necessarily
needing to replace them outright.
as noted before, in my VM:
user-defined syntax and AST nodes are presently possible via plug-ins;
an additional level of plug-ins could be plug-ins at the bytecode level
(for example, handlers are added which extend the bytecoded ISA,
although this "may" be limited to 3-byte opcodes, with 1 and 2 byte
opcode ranges being generally reserved for the implementation).
actually, the 1-byte space is pretty much full anyways, and my own
efforts are using up the 2-byte space (but, the 2-byte space is much
bigger than the 1-byte space).
the 3-byte space allows around 768k opcodes.
also relevant is also having a pluggable type-system, where most basic
operations and operators can also be registered for new/custom types.
currently this is possible, but has the slight drawback at the moment of
only dealing with only exact type-matches, whereas predicate-based
matching could be possibly more useful (as opposed to matching exact
types, like say, "_myapp_foo_t" + "_fixint_t", one can match generic
types, like say, "_foo_t"+dyrealp(), such that a single handler
registration would cover all real types, or similar...).
at least, it is a possible option...
granted, yes, a plug-in system still has drawbacks, but could still be
better than the present situation with many more mainstream languages,
where apart from extensive work (often having to largely re-implement
the thing, or result to nasty kludges) one has little or no
customization ability...
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
