To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.dev.lcdOpen lugnet.cad.dev.lcd in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / LDraw Connection Database / 15
14  |  16
Subject: 
I have read the article about LCD
Newsgroups: 
lugnet.cad.dev.lcd
Date: 
Sun, 24 Feb 2002 20:19:08 GMT
Viewed: 
2200 times
  
I have read the article about LCD.

The primary usage of an LCad library is to provide many quality virtual parts.
So the future of LDraw library is more and better parts.
The primary usage of an LCad tool is to select and position virtual parts.
So the future of LDraw tools is faster and easier part selection and
positioning.

What is the current state of LDraw organization?
The current state is fairly simple: LDraw library is already far beyond
LDraw tools.
The new Parts Tracker delivers more and more action-oriented parts at a
nearly monthly rate.
We now have the trap door, the motorcycle, many decorated parts, many
minifigs, minifig accessories and weapons. And much more is coming soon
(including horse, monorail, bike and bicycle).
So we have, or will soon have, needed parts for comics and animation, for
interactivity and games.
With all these play-oriented parts we do not want to restrict creativity to
building instructions only, as is still the case today. LDraw will surely
parrallel the LEGO group evolution: more build-oriented at first and then
more play-oriented.

I have read the article about LCD.

Here is my main objection :
Whe should not develop multiple syntax levels.

There is already LDraw so we specify parts. There will be LCD so we specify
connections. Then there will LMPL so we specify submodel movements. Then,
without doubts,  there will be additionnal syntax for, say, minifig
scripting, minifig dialog, model scripting, collision detection and user
control by joystick and mouse.
You should have only one specification language that encompasses all present
and future needs.
Also the specification should be the same for the datas (as LCD) and the
treatments (as LMPL).
LCD should not be scattered arbitrary syntax, but structured data that is
manipulable by user.

Instead of (3001  Brick 2 x 4 example in LCD draft document) :

Stud at x = 0, y = 0, z = 1; Size x = 2, y = 4
Inlet at x = 0, y = 0, z = 0; Size x = 2, y = 4

We should write :

Stud(-1,1,-2,2,1) // I use LDraw origin and the shape
Stud(xmin,xmax,ymin,ymax,z)
Inlet(-1,1,-2,2,0) // I use LDraw origin and the shape
Inlet(xmin,xmax,ymin,ymax,z)

Then, this structured data is easily manipulated.
Here is a simple Prolog-style function that tests the Stud-Inlet connectivity :

Connect( Stud(x1,x2,y1,y2,z1), Inlet(x3,x4,y3,y4,z3) ) :=
if z1 # z3 then False
else if x1 >= x4 then False
else if x2 <= x3 then False
else if y1 >= y4 then False
else if y2 <= y3 then False
else True

Actually, using such a structured language, we can formally specify LCD.
Which greatly helps understanding LCD purpose and implementation.
For illustration, the Clutch function filters a List of Studs using a single
Inlet.
The result List is the list of Studs that connect the Inlet.

// if the List of Studs is empty then result is an empty List
Clutch( inlet, List ) := List

// else the List of Studs contains one "stud" plus ".."
Clutch( inlet, List(stud,..) ) :=
let rest = Clutch( inlet, List(..) ) in
if Connect(stud, inlet) then Cons( stud, rest )
else rest

Some comments:
* the List elision is .. and represents all (0 or more) non-designated elements
*  Cons is the standard function to extend a List at left
Cons( stud, List(..) ) := List(stud,..)
* the "let - in" line is just a local definition

The language has no other construct.
And yet it has unlimited specification power.
May be I will use it to develop a concurrent LCD proposal.

Damien
http://brickcaster.multimania.com



Message has 1 Reply:
  Re: I have read the article about LCD
 
(...) What are you meaning by multiple syntax levels, Damien? (...) Let me report that LMPL is almost ready. It is going to be published soon. (...) LMPL contains these in theory. (...) Of course we should. (...) Well, this seems to be usable. In (...) (22 years ago, 25-Feb-02, to lugnet.cad.dev.lcd)

6 Messages in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR