On 6/14/2011 4:24 PM, John Nilsson wrote:
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
yeah.
I don't have special editor support for extensions, mostly because I
don't have a special dedicated editor (as-is, I do most text-editing
with Notepad2... mostly as it is fairly lightweight and does enough for
my uses...).
in my case, I generally just tell it that my language is JavaScript, and
it does well enough.
granted, a fancy editor which supported both a base language, and syntax
extensions, could probably handle all this as well, more so if the
editor was able to make use of the VM's facilities. granted, this would
mean plug-ins also registering interfaces for things like autocomplete
and similar.
as for cross-language interfacing...
actually, if the other language is C, my VM already does fairly well at
this, since it was designed with a "fancy" C FFI.
in terms of the implementation, the C FFI is generally handled by
special object, and in particular an object I call "CTop" (for "C
Toplevel", but it also supports scoped-lookups as well).
basically, the VM is set up to delegate to this special object (via a
delegation-based lookup). when a request for something reaches this
object, it will then call off into a C-side API to basically look up
whatever is being asked for (involves a database, and
GetProcAddress/dlsym, ...). variables will be marshaled into dynamically
typed values. functions will be auto-wrapped as special "function
objects" (which basically implements the Apply handler, so it can be
called like a function... other special handlers have names like
GetSlot, SetSlot, MethodCall, ...).
(how the lookup system works would be difficult to explain here, but
IIRC some of the basic ideas/mechanism came from Self, and some stuff I
ran into online describing some of the internals of Squeak IIRC, so this
should be somewhere in the right direction...).
when called, the function object will take the arguments (generally
passed to it as a list), and basically coerce this into the format
expected by the native function and the relevant ABI, and then will then
call the native function. on return, it will go the other way, and
coerce the native return value back into a dynamically-typed reference.
this step currently involves some amount of ASM, but I have recently
considered the possibility of an optional "pure C" solution (likely
involving a big-ass switch block, probably using autogenerated code).
there is a little nastiness in the details, but in general it manages to
work fairly well...
it also has some basic support for C macros and similar as well (may
involve "eval", and so doesn't always work, and doesn't currently
support function-like macros, ...).
eventually, I may work on extending the mechanism to support interfacing
with C++ APIs, but this is likely to be big and nasty...
interfacing with other VM-based languages shouldn't be too difficult.
one would mostly just have to implement an object type which can perform
the relevant lookup operations, and returns function objects (objects
which support being called/"applied").
oh yeah, and one can create new objects to exhibit generally whatever
other behaviors are needed as well (recently, I also added handlers/...
related to value-type objects, which can support pass-by-value semantics
rather than necessarily follow pass-by-reference, ...).
or such...
Sent from my phone
Den 15 jun 2011 01:08 skrev "BGB" <[email protected]
<mailto:[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
