On 3/14/2012 8:57 AM, Loup Vaillant wrote:
Michael FIG wrote:
Loup Vaillant<l...@loup-vaillant.fr> writes:
You could also play the human compiler: use the better syntax in the
comments, and implement a translation of it in code just below. But
then you have to manually make sure they are synchronized. Comments
are good. Needing them is bad.
Or use a preprocessor that substitutes the translation inline
automatically.
Which is a way of implementing the syntax… How is this different than
my "Then you write the parser"? Sure you can use a preprocessor, but
you still have to write the macros for your new syntax.
in my case, this can be theoretically done already (writing new
customized parsers), and was part of why I added block-strings.
most likely route would be translating code into ASTs, and maybe using
something like "(defmacro)" or similar at the AST level.
another route could be I guess to make use of "quote" and "unquote",
both of which can be used as expression-building features (functionally,
they are vaguely similar to "quasiquote" in Scheme, but they haven't
enjoyed so much use thus far).
a more practical matter though would be getting things "nailed down"
enough so that larger parts of the system can be written in a language
other than C.
yes, there is the FFI (generally seems to work fairly well), and one can
shove script closures into C-side function pointers (provided arguments
and return types are annotated and the types match exactly, but I don't
entirely trust its reliability, ...).
slightly nicer would be if code could be written in various places which
accepts script objects (either via interfaces or ex-nihilo objects).
abstract example (ex-nihilo object):
var obj={render: function() { ... } ... };
lbxModelRegisterScriptObject("models/script/somemodel", obj);
so, if some code elsewhere creates an object using the given model-name,
then the script code is invoked to go about rendering it.
alternatively, using an interface:
public interface IRender3D { ... } //contents omitted for brevity
public class MyObject implements IRender3D { ... }
lbxModelRegisterScriptObject("models/script/somemodel", new MyObject());
granted, there are probably better (and less likely to kill performance)
ways to make use of script objects (as-is, using script code to write
objects for use in the 3D renderer is not likely to turn out well
regarding the framerate and similar, at least until if/when there is a
good solid JIT in place, and it can compete more on equal terms with C
regarding performance).
mostly the script language was intended for use in the game's server
end, where typically raw performance is less critical, but as-is, there
is still a bit of a language-border issue that would need to be worked
on here (I originally intended to write the server end mostly in script,
but at the time the VM was a little less "solid" at the time (poorer
performance, more prone to leak memory and trigger GC, ...), and so the
server end was written more "quick and dirty" in plain C, using a design
fairly similar to a mix of the Quake 1 and 2 server-ends). as-is, it is
not entirely friendly to the script code, so a little more work is needed.
another possible use case is related to world-construction tasks
(procedural world-building and similar).
but, yes, all of this is a bit more of a "mundane" ways of using a
scripting language, but then again, everything tends to be built from
the bottom up (and this just happens to be where I am currently at, at
this point in time).
(maybe at which point in time I am stuck less worrying about which
language is used where and about cross-language interfacing issues, then
allowing things like alternative syntax, ... could be more worth
exploration. but, in many areas, both C and C++ have a bit of a "gravity
well"...).
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
