Kaz Kylheku
5/20/2015 2:29:00 PM
On 2015-05-20, luserdroog <mijoryx@yahoo.com> wrote:
> On Monday, May 18, 2015 at 9:26:56 AM UTC-5, Mirko Vukovic wrote:
>> I looked on cliki, but nothing jumped out.
>>
>> I need to manipulate points and paths:
>>
>> Points are 2D or 3D. I want to scale them with respect to a reference point, translate them, etc.
>>
>> Paths consist of straight line segments and which are ordered collections of points. I will want to apply affine transformations to them.
>>
>> (I am not thinking of Bezier curves).
>>
>> I already have written bits that I need, but why continue, if there is a tested library?
>>
>> Oh, and one more thing: it has to be in Common Lisp.
>>
>
> This may not fit your bill (probably not, as you
> explicitly say CL), but I am the prophet of PostScript.
> A language designed specifically for all the things
> you say (and Beziers too).
>
> Most Lispers surely know that Postscript shares many
> delightful properties like (mostly) transparent
> syntax -> data structure encoding == program.
> You can manipulate (mutilate) procedure bodies
> to your heart's content because all the pieces
> are concatenative -- iff you mind what you're doing
> to the stack.
The pieces being catenative has little to with the pieces being
a structured, nested tree, as it is in Lisp.
In Lisp, we do not manipulate procedure bodies once they are compiled.
They become native machine code, or byte code for a virtual machine.
Code isn't data; rather, *source* code is data.
> and many Lisp-like powers
Chopping up sausages of instructions that implicitly refer to arguments
by stack position is a far cry from "Lisp-like powers".
That is not even safe to do, because it can result in stack underflows;
the pieces cannot be arbitrarily rearranged.
It may look like the syntax is just a clump of words ("there is no syntax"),
but that is a lie. What looks like a linear sequence
a b c d e f g
could in fact have the structure (for example)
(a b c d) (e f) g
that is to say, g is binary, and its operands are produced by the two
chains a b c d and e f .
We don't know any of this by just looking at it. We don't know g is binary. We
don't know how the chain breaks up to produce arguments for g. We don't know
how many arguments the whole thing takes, and what it puts on the stack.
These considerations amount to syntax, just like taking a seven word
sentence and identifying the subject, object, verb and finer structures.
The above structure, if it is true, tells me that, for instance,
I shouldn't be transforming the code by moving around (d e).
Words d and e belong to separate logical structures; they do not
constitute a unit.