didn't mean to click send when I did... it seems stupid copy-paste messed it up a bit, I will try again. yes, now it looks a little better... I hope anyone has any comments, or notices any major things I missed (the actual "geometry" part will come eventually, for now I am still deciding how it will work). it is now looking a little more like a more common programming language now, and should be within my implementation capabilities... all for now. --- BGB Geometry Generation Language 0 goals: focus on generation of simplistic geometries, eg, those that would be found in games or similar; define the evaluation model for possibly recursive construction; if possible allow extra info to be transferred in the construction not directly related to the desired properties of the objects (eg: mass, material, load capabilities, or similar...). I will define that there be a few primitive types: sets (unordered collections of objects); entities (globs of properties, with semantics similar to ast's); vectors; matrices (nested vectors); scalars; symbols (used as names, will be case-sensitive). core syntax will be similar to that of lisp (eg: s-expressions). the language will primarily work in terms of properties, which will be named when passed to functions (thus, the conceptual arguments to a function will be all the properties passed to it bound into variables). similarly, there will also be fixed arguments (required to come first). scoping: this will use dynamic scoping. there will be no seperation of the function and variable namespaces. the binding environment may be incomplete, evaluation will stop at the point where it is not possible to proceed with the current data, or at an entity boundary. evaluation: there will be no imperative operations, all execution will be declarative/functional. there will be no io or order sensitive operations, and the evaluation model will quite likely be lazy. as a result, some forms will be able to use others as input, or perform special tasks for the interpreter (these forms are viewed as "special", namely in that they are only called with child forms unevaluated). special forms will also be able to accept positional arguments (as opposed to just properties). it will also be possible to "undue" evaluation, eg: looking at the source for a given argument. a possibility is that the data be computed incrementally on an "as needed" basis. the first arg in a list is the function. general forms: (lambda (<args*> [. <rest>]) <body>) where each arg will be: <name>, a fixed argument; (<name>), a required property. (<name> <default>), an optional property. if rest is present rest will represent all remaining arguments as a list. this will not allowed to be prefixed by properties. within body whether each arg is evaluated or not is undefined. (let (<opts*>) <body>) each opt is of the form (<name> <value>). (union <args...>) create a union of the arguments. (entity (<properties*>) <body>) creates an entity. an entity will be a point in which to logically break evaluation. the properties each have the form (<name> <declared-value>). properties may be asked of an entity and an entity may be treated as disjoint from the parent. within an entity evaluation may be allowed to progress, but the entity will retain it's identity. within an entity properties may be allowed to be changed, in which case body will be re-evaluated. all properties will also be visible as dynamic bindings within body. it may be allowed post-evaluation for an entity to be replaced by body. math: math operations will be extended to vectors and matrices (nested vectors) as well. not all math operators will be the same between all types though. some aritmatic operators will be recursive, eg, they will evaluate by applying the leftmost argument to the remainder of the body. an implicit "accumulator" may exist, and an argument is required to be compatible with the accumulator. for scalars the arithmatic operations are the same as lisp. I will save describing all behaviors for now, though: (dot <vector> <vector>) dot-product. (X <vector> <vector>) cross-product. (inv <matrix>) invert a matrix.