[cad-linux-dev] Re: format as a mini-language
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- To: <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Sun, 7 Dec 2003 00:04:33 -0800
----- Original Message -----
From: "Eric Wilhelm" <ewilhelm@xxxxxxxxxxxxx>
To: <cad-linux-dev@xxxxxxxxxxxxx>
Sent: Saturday, December 06, 2003 8:19 PM
Subject: [cad-linux-dev] format as a mini-language
> > 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.
>
ok.
I am not sure how far one could go avoiding code though.
actually, quark had some kinds of features that allowed duplication and
modification of objects, eg:
take this piece of geometry and make some-odd number of copies, each time
offsetting and rotating by some amount...
> 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.
>
ok.
> >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.
>
link?
> 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.
>
ok.
> 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.
>
not sure.
yes, turing completeness in models could be a risk.
I am not sure what is so "counter intuitive" about math in lisp though,
unless maybe you are referring to the fact that it does not like thinking in
terms of mathmatical expressions (instead viewing it as function
application)?...
> 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.
>
ok.
> 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.)
>
ok.
> I think the meat of the format would be mostly a "constructive" or
declarative
> mini-language.
>
yes. I have little idea how such a language would be structured though, and
not much idea on what good semantics would be either.
it could focus on the concept of a "set", eg, many operations are either:
accumulated into sets;
performing operations on the sets (eg: csg operations or such);
constructing a piece of geometry based on arguments;
..
assertions:
many "common" features (eg: destructive operations, quite likely io, a
general type system, ...) would not be necessary;
hopefully geometric primitives and collections of primitives (eg: unions and
such) would be builtin;
evaluation semantics may be very much like macros (primarily consisting of
replacing function calls with expanded geometry);
..
the language would hopefully be readily understandable by users as well.
it need not be directly usable from a cad program, I was expecting something
along the line of a tool you feed scripts into and it spits out models...
I am feeling like the only way to get a good idea of how it might work might
be to try to design it, but quite possibly others have done similar
allready...
the question is how should it work. personally I think it would save work if
I were at least to use some aspects of a lisp (eg: the parser and type
system). but, if I were starting from scratch, I would probably use
something more like shell scripts (though with very much different implied
evaluation...).
actually, once I used my parser and type system to write a kind of
forth-like language as well;
and, I had also used it for a few linguistics related projects;
and not to mention my current model format (breaking from s-exps would
require me to write a new parser/printer for that format);
..
mostly the question is if one could put up with a lispy syntax...
I don't know.
Other related posts:
