Yes. And now add to that semantic editing support for such extensions automatically inherited. Things like syntax highlighting, intellisense, find references. Also interoperabilty with libs/modules in other languages is important.
BR, John Sent from my phone Den 15 jun 2011 01:08 skrev "BGB" <[email protected]>: > 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 [email protected] http://vpri.org/mailman/listinfo/fonc
