Re: thought: C, dynamic types, and closures

Adding closures, dynamic typing, and garbage collection to C _and_
keeping it decently backwards compatible seems like a useless
endeavor. You could probably do it, but you'd wind up with something
incredibly ugly and unintuitive. Things that far reaching need to be
integrated with essentially everything else to be properly supported.

I was idly thinking of something here, which is this question:
what is the simplest, easiest, and least intrusive way to bolt things like
dynamic types and closures onto C?...

could be used as an extension in my compiler to make it more suited to
things like scripting.

thinking, well, niceness isn't a primary concern, but it should be at least
tolerable.

I am thinking, the whole thing would be controlled be a special header
('variant.h'), which would add all this stuff to the language (actually,
these would exist before, but as compiler builtins, which would be renamed
via macros...).

so, the added type/keyword will be this:
'variant' (or maybe just 'var').

which has the following properies:
it holds dynamically typed values;
it is garbage collected;
it is possible to be closed over.

yes, I am thinking, it will not be possible to close over non-variants.
this leads to a generally simpler implementation (very likely, variants
would not be stored on the main stack, but rather on the heap and on a
seperate dynamic-typed stack).

potentially, a seperate stack would be used for variants as well, which
would simplify garbage collection.

basically, when used, they will operate primarily by generating hidden code.
performance will be a lower concern (after all, if one wants speed, they
always have 'clean' code...).

variants will also be 'seperate' from static types, so many operations (such
as expecting to directly convert between pointers and variants, get a
pointer to a variant object, ...) will not be possible.

of course, I may add an ability to convert between variant and 'elem' (aka:
raw tagged values).

additionally, there could be few new syntactic forms:
list {...}
dict {...}
fun <decl> <body>
...

list {2, 3, 4};
fun int(int x, int y) x*x+y*y;
...

and have many of the same operations as my last script language, including
possible access to the prototype object system, and many other features
(likely enabled via a pragma):

var pyth(var x, var y)x*x+y*y;

var l0={2, 3}, l1={4, 5}, l2;

l2=l0&l1;
println(l2 " " pyth(l2[1], l2[2])); //prints: {2, 3, 4, 5} 25

or, in short, a magical header that would partly dump my scripting language
on top of C...

of course, some of the syntax would need to be fudged a little to remain
unambiguous...

then again, the other (less messy) possibility is to regard this as a
technically seperate language, however reusing the existing compiler
internals (much like C++ or Objective-C in other compilers).

actually, this may be a better option (this would consist of merging my
existing BGBScript language into my C compiler...).

the main new feature it would have (over how it is already) would be the
ability to directly interface with C, use the C preprocessor and typesystem,
...

all this shouldn't be too hard (given for the most part, my C parser and
upper compiler were largely just derived from the BGBScript parser and
compiler anyways, so the general code structure and internals are very
similar...).

could be nicer anyways:
I leave C as C, and everything extra goes into BGBScript...
the former gains some, but limited, dynamic abilities (such as being
compiled at runtime, ...), and the latter gets a lot more...

as a result, it is possible that for most pure-dynamic facilities (such as
'eval', ...) I will use BS as opposed to C...

or something...


.

Relevant Pages

  • thought: C, dynamic types, and closures
    ... these would exist before, but as compiler builtins, which would be renamed ... this leads to a generally simpler implementation (very likely, variants ... seperate dynamic-typed stack). ... and have many of the same operations as my last script language, ...
    (comp.lang.misc)
  • Re: C garbage collection -crazy idea
    ... If a compiler is designed such that it automatically adds a free ... matching every malloc() ... Garbage collection itself is a good idea. ... Whether it is a good idea to extend the C language this way is a moot point. ...
    (comp.lang.c)
  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
Loading