[cad-linux-dev] format as a mini-language

  • From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
  • To: cad-linux-dev@xxxxxxxxxxxxx
  • Date: Sat, 6 Dec 2003 22:19:28 -0600

> The following was supposedly scribed by
> cr88192
> on Saturday 06 December 2003 08:35 pm:

>I had more imagined "piecewise" and "functional" modeling, eg:
>it would be cool, eventually, to be able to define geometry in terms of
>functions that take some arguments and evaluate to geometry.

This is a cool idea, but it is essentially the basis of a parametric / 
relational modeling system.  Think "transparency" before you go too far down 
this road.  I think it is important for the internal of those functions to be 
visible in a way that does not involve reading code.  

For some types of repetitive processing, black-box (from the standpoint of the 
rest of the running code) functions may be a good choice.  However, for most 
models, the format should allow the information to be stored in a 
"constructable" way.

>hmm, what if the geometric language were something like a forth dialect
>(like postscript or such). ok, some kind of primitives would be needed for
>geometric objects. the intent would be more to focus on construction of
>geometry than rendering.
>hmm, a specialized lisp dialect might work better (or at least be more
>striaghtforward to code in).
>something like shell scripts could also work, and has the advantage as that
>there is less expectation as to how the evaluation semantics would work
>(like, eg, a forth or lisp dialect...).
>
>I am not sure, the line as to how close it should be to a general
>programming language is unclear...
>
>or, even simpler for me, I could just define a subset of lang/bgb for
>geometric construction, but this is not very general...

See the chapter in the Raymond book about mini-languages.  He's got some good 
thoughts and examples in there.

I think that is really what the requirements are leading us toward.  I'm not 
too keen on lisp, since I have always found it to be counter-intuitive when 
it comes to mathematical operations.  

I don't think it should be a fully-formed (Turing complete) language.  Though, 
maybe it does need flow-control.  However, I'm more inclined to let formulas 
be formulas and algorithms algorithms.  

Example:  linear-feature placement.    For this you need flow-control, but all 
you really need is for something to output a list.  I'm more inclined to 
allow embedded interpreters (like Perl/Bash/Lisp) for these things.

Simpler example:  placement of a point some distance along a line.  For this, 
you simply need algebra.  I think the format should encapsulate an existing 
C.A.S. format for simple formulas.  In this way, you could simply use the 
properties of other objects as your variables and standard mathematical 
notation.  This allows the user and the system to more easily back-calculate 
the relationships, where a Turing-complete programming language would not 
(since anything with flow-control is capable of giving the same output for 
many inputs.)

I think the meat of the format would be mostly a "constructive" or declarative 
mini-language.

--Eric

-- 
"...our schools have been scientifically designed to 
prevent overeducation from happening."
                                        --William Troy Harris


Other related posts: