[cad-linux-dev] Re: a few more attempts
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- To: <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Mon, 8 Dec 2003 13:58:02 -0800
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.
Other related posts:
