Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - BrickCaster

Pages1 2
#1
Anything else we might add? /
October 30, 2004, 10:43:51 AM
thanks for your help Lutz.



unfortunately, the more i experiment with NewLISP the more i discover how much i am biased towards the everything-is-a-first-class-value approach.



so i will probably convert my code to some Scheme or Scheme derivative.

that makes sense because animating LEGO scenes also requires some paralellism that can only be implemented using true continuations.



however, be sure i was really pleased to discover NewLISP and how well you maintain and support it.
#2
Anything else we might add? / anonymous context-objects
October 29, 2004, 01:06:30 PM
i experiment with NewLISP and LEGO bricks, using the LDraw library standard.

i use a newlisp BRICK class, here is an excerpt:
Code Select

(constant 'red 4)

(context 'BRICK)

(define color MAIN:red)

(define (BRICK:new ctx col x y z)
  (MAIN:new BRICK ctx)
  (set 'ctx (eval ctx))
  (set 'ctx:color col)
  ctx
)

now what i want is to define LEGO models as a list of BRICKs:
Code Select

(list
  (BRICK:new 'ctx1 ...)
  (BRICK:new 'ctx2 ...)
  (BRICK:new 'ctx3 ...)
  (BRICK:new 'ctx4 ...)
  ...
)

the problem is i want anonymous context-objets, i don't want to name  each brick in my LEGO models, some have 700+ bricks.
#3
newLISP and the O.S. /
October 16, 2004, 06:12:58 PM
are palmOS applications limited to 64ko RAM or not ?



seems to me 64ko is a severe limitation.
#4
newLISP newS /
October 16, 2004, 05:36:32 PM
i think newLISP is good because it is an alternative.



* can you live without closures ?

* can you live without classes (and use prototypes instead) ?

* can you live without continuations ?



if the answer is "yes" then newLISP is a serious candidate.

otherwise one may be happier with Scheme.



anyway, i don't see why newLISP should be bashed.

someone who devotes time and efforts should always be praised.
#5
Anything else we might add? /
August 13, 2004, 03:31:55 PM
(inc 'Lutz:balance 1000000) ;; please ;-)



many prototype languages (such as NewtonScript) even create the "balance" slot if it is read but do not exist. that's too much flexibility, typos become unnotified, additionnal expressiveness is insignificant :(



one great thing with newLISP contexts is context switching :)



many Scheme implementations have a module extension where module is:



(module

   .....

)



that's not realistic because that favors a batch-mode rather than an interactive mode. module-switching would be better, in a batch file the scope can be visually recreated though indentation.
#6
Anything else we might add? /
August 11, 2004, 11:22:14 AM
i mean what you declare is less statically comprehensible because it depends on other dynamic declarations rather than solely on static declarations.

now it's up to you to decide if it's a good thing (more flexible) or a bad thing (less readable).
#7
Anything else we might add? /
August 11, 2004, 11:19:55 AM
"benchmarks" and "unique memory management" are interesting insights :)
#8
Anything else we might add? /
August 10, 2004, 03:15:58 PM
this PDF document describes a minimal Scheme extension for AOP:



http://www.cs.uri.edu/~dbtucker/pubs/aosd2003-tk.pdf">//http://www.cs.uri.edu/~dbtucker/pubs/aosd2003-tk.pdf



thus, dynamic scoping is not necessary to benefit AOP.



the Scheme AOP extension seems more powerful, however i agree it is also far less intuitive because it's based on a continuation-like concept.


QuoteIt is good to see that somebody has a fresh look at dynamic scoping and points out the interesting possibilites it has.


the great thing in functional programming is declarative style.

may be dynamic scoping adds some interesting possibilites but breaking declarative style is too much a cost in my opinion.
#9
newLISP in the real world /
July 07, 2004, 03:24:12 PM
well, i use newLISP for prototyping some useless functions.

only time will say if the functions are actually usefull and how they eventually are.

the functions manipulate LEGO bricks, represent them as cubes, and test if they overlap and if they connect:
Code Select

(constant 'black   0)
(constant 'blue    1)
(constant 'green   2)
(constant 'red     4)
(constant 'brown   6)
(constant 'grey    7)
(constant 'dark    8)
(constant 'yellow 14)
(constant 'white  15)
(constant 'trans  32)


(context 'BRICK)

(set 'num '3001)
(set 'col MAIN:red)

(set 'apos 0)
(set 'xpos 0)
(set 'ypos 0)
(set 'zpos 0)

(set 'xmin -40)
(set 'xmax  40)
(set 'ymin   0)
(set 'ymax  24)
(set 'zmin -20)
(set 'zmax  20)

(define (overlap? b)
  (if
    (>= xmin b:xmax) nil
    (<= xmax b:xmin) nil
    (>= ymin b:ymax) nil
    (<= ymax b:ymin) nil
    (>= zmin b:zmax) nil
    (<= zmax b:zmin) nil
    true
  )
)

(define (connect? b)
  (if
    (>= xmin b:xmax) nil
    (<= xmax b:xmin) nil
    (>= zmin b:zmax) nil
    (<= zmax b:zmin) nil
    (= ymin b:ymax)  true
    (= ymax b:ymin)  true
    nil
  )
)

(define (move dx dz)
  (inc 'xpos dx) (inc 'xmin dx) (inc 'xmax dx)
  (inc 'zpos dz) (inc 'zmin dz) (inc 'zmax dz)
)
(define (elevate dy)
  (inc 'ypos dy) (inc 'ymin dy) (inc 'ymax dy)
)

(define (rotate-0)
  (inc 'apos 90)
  (if (= apos 360) (set 'apos 0))
  (let (xneg (- xpos)) (set 'xpos zpos) (set 'zpos xneg))
  (let (nmin (- xmin) nmax (- xmax))
    (set 'xmin zmin) (set 'xmax zmax)
    (set 'zmin nmax) (set 'zmax nmin)
  )
)

(define (rotate-c x0 z0)
  (move (- x0) (- z0)) (rotate-0) (move x0 z0)
)

(define (display)
  (print 1)    (print " ")
  (print col)  (print " ")
  (print xpos) (print " ")
  (print ypos) (print " ")
  (print zpos) (print " ")
  (if
    (= apos   0) (print "1 0 0 0 1 0 0 0 1")
    (= apos  90) (print "0 0 1 0 1 0 -1 0 0")
    (= apos 180) (print "-1 0 0 0 1 0 0 0 -1")
    (= apos 270) (print "0 0 -1 0 1 0 1 0 0")
  )
  (print " ")
  (print num) (print ".dat")
  (print "rn")
)



the "display" output is valid entry for LEGO-CAD software that can be found here: http://www.ldraw.org/">//http://www.ldraw.org/



"1 0 0 0 1 0 0 0 1" is not binary number but the identity matrix:



1 0 0

0 1 0

0 0 1



newLISP has matrix operations and that is also a welcomed plus :-)



i guess prototyping languages are ideal for such experiments, when you are not sure what you want to do, but you know how to do it.

newLISP is open-minded :-)
#10
newLISP in the real world /
July 06, 2004, 08:09:47 AM
Quote
It would not avoid the problem you ran into and you would have:



(= apos 090) interpreted as (= apos 0 90), which would always evaluate to nil.



But breaking the token where the legal octal string ends would be a more consistent approach when parsing numbers.


the problem is not here in my opinion.

consistency means 090 is a decimal number.

consistency would rather command octals have a syntax similar to hex numbers, something like 0c77.
#11
newLISP in the real world / integer parsing
July 05, 2004, 06:31:40 PM
every language has its pitfalls.

the code is supposed to print a simple rotation matrix:


Code Select
 (if
    (= apos 000) (print "1 0 0 0 1 0 0 0 1")
    (= apos 090) (print "0 0 1 0 1 0 -1 0 0")
    (= apos 180) (print "-1 0 0 0 1 0 0 0 -1")
    (= apos 270) (print "0 0 -1 0 1 0 1 0 0")
  )

pretty code alignment is not always a wise idea.

after carefully reading the doc it turned out that 090 is an octal number!

indeed 090 is the octal number 0.

i found that rather unpleasant.

at least an error message could point the bad number format.
#12
Anything else we might add? /
July 02, 2004, 02:13:26 PM
that's indeed how delegation is implemented in LISP languages: an object is a lexical closure that exports its bindings.

nested lexical closures provide the inheritance effect.



unfortunately, without lexical closures newLISP is not suitable for implementation of new OOP systems. so newLISP is only a language, not the meta-language i expected it to be.



i may still have a usage for newLISP (LEGO models scripting), but i have not decided yet (i have to investigate whether i can live without closures).
#13
Anything else we might add? /
July 01, 2004, 06:00:43 PM
thanks eddier.



the new code may be less efficient, yet it removes the arguments problem.

that also partially solves the "identity" problem, because objects are macros whereas methods are lambdas.
Code Select

(define (handler)
  (define-macro (self msg)
    (define slot (eval (eval msg)))
    (if (lambda? slot)
      (eval (cons slot (map eval (rest (args)))))
      slot
    )
  )
)

(define (interval x1 x2)
  (define xmin x1)
  (define xmax x2)
  (define (glide dx)
    (inc 'xmin dx)
    (inc 'xmax dx)
  )
  (define (rectangle y1 y2)
    (define ymin y1)
    (define ymax y2)
    (define (move dx dy)
      (self 'glide dx)
      (inc 'ymin dy)
      (inc 'ymax dy)
    )
    (handler)
  )
  (handler)
)

(set 'int (interval 0 639))
(set 'rect (int 'rectangle 0 479))
(rect 'move 20 20)
#14
Anything else we might add? /
June 30, 2004, 03:05:59 PM
quite funny :)

programming is so unrewarding: it's hard to believe there are 4 styles
#15
Anything else we might add? /
June 30, 2004, 02:44:52 PM
thanks for your attention.



my understanding of newLISP OOP model is it's much more practical than i thought at first. it even offers multiple inheritance with no hassle.



finally i even have removed my OCAML installation, i can't even read the OCAML documentation, CAML is really nice but in my opinion they have messed things up with the OOP extension. i wish it would have been as neat and simple as newLISP is.  



however when i practice delegation with newLISP (i am like a girl, i want everything) the concepts are all here, yet i face some limitations, well illustrated by the example:



1. (define (self msg a b) means i can't have more than 2 method args

2. incrementality requires a define-swith similar to the context-switch

3. even worse: it's not possible to distinct between a method and an object because both are lambdas



Note the 2 first limitations do not exist in Scheme, because:



1. (lambda (msg . args) allows to access the argument list

2. (eval expr env) allows to switch the evaluation environment



May be i am not adventurous enough, and there is a way to achieve the same effect in newLISP, but i still have not found how (i really bless you because the newLISP doc is so short!).



Have you some hack i have not seen?

It would be really great if delegation programming could be a practical alternative, because delegation programming offers the sharing possibilities that the built-in OOP model misses.

Delegation programming should be more than a toy.

Ideally newLISP should be practical whatever the preferred style.

That's how i see it: newLISP is beyond programming style.



regards,



- damien



(i know i am too severe, newLISP is great)
Pages1 2