Wish list
Wish list
Hi! After learning newLISP for some times, here is my wish list ;-)
1. block/multi-line (nestable) comment; its syntax might be #{...}#
2. .0 is not removed when printing floats (e.g. 1.0 should be printed 1.0, not 1)
3. regex-option parameters should accept nil to mean not using regular expression (e.g. (find "x" "axbxc" nil 2))
4. inc (and dec, sequence, for) should correctly use either integer or floating-point arithmetic based on the type of current value (or of its additional argument) (e.g. (inc 1.2) should be 2.2, not 2; (inc 1 2) should be 3, not 3.0)
5. parameter names can be prefixed (or suffixed) with a marker (says &), and the corresponding arguments would be passed by reference (e.g. (define (my-pop &l (n 0)) (pop &l n)))
6. always return by reference (see http://newlispfanclub.alh.net/forum/vie ... =16&t=3433)
I'm not sure whether they will have any impact (backward compatibility, performance, integrity, etc.). What's your opinion?
1. block/multi-line (nestable) comment; its syntax might be #{...}#
2. .0 is not removed when printing floats (e.g. 1.0 should be printed 1.0, not 1)
3. regex-option parameters should accept nil to mean not using regular expression (e.g. (find "x" "axbxc" nil 2))
4. inc (and dec, sequence, for) should correctly use either integer or floating-point arithmetic based on the type of current value (or of its additional argument) (e.g. (inc 1.2) should be 2.2, not 2; (inc 1 2) should be 3, not 3.0)
5. parameter names can be prefixed (or suffixed) with a marker (says &), and the corresponding arguments would be passed by reference (e.g. (define (my-pop &l (n 0)) (pop &l n)))
6. always return by reference (see http://newlispfanclub.alh.net/forum/vie ... =16&t=3433)
I'm not sure whether they will have any impact (backward compatibility, performance, integrity, etc.). What's your opinion?
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Re: Wish list
Hi! Yes, I think everyone who uses newLISP wants to modify it... :)
I too have wondered about another multi-line text/comment tag f. Perhaps [comment] [/comment], consistent with [text] and [cmd]. Of course, you can usually use [text] [/text] for comments anyway...
Can't see the need for nil in find...
Personally I'm OK with the existing float/integer conversions in newLISP, although I can see that they might cause problems if you haven't found out about them - and some people find out the hard way that + and - do integer arithmetic... Perhaps inc and dec could be smarter without hardship though...
As for backwards compatibility - I have my own opinions! :) I'm ok with incompatible changes if there are substantial benefits in return, but it's less satisfactory when they're just minor compatibility issues or things that could easily be customized locally with a function or two. And maintaining two parallel bits of code for two or more releases is a bit of a chore. I prefer new powerful functions or extended functionality from existing functions!
I think that some of the goals of newLISP are to be as simple as possible, as small as possible, as powerful as possible, and as fast as possible. If you can argue that a change you're proposing can help move towards all of those goals, Lutz may not be able to resist implementing it!
I too have wondered about another multi-line text/comment tag f. Perhaps [comment] [/comment], consistent with [text] and [cmd]. Of course, you can usually use [text] [/text] for comments anyway...
Can't see the need for nil in find...
Personally I'm OK with the existing float/integer conversions in newLISP, although I can see that they might cause problems if you haven't found out about them - and some people find out the hard way that + and - do integer arithmetic... Perhaps inc and dec could be smarter without hardship though...
As for backwards compatibility - I have my own opinions! :) I'm ok with incompatible changes if there are substantial benefits in return, but it's less satisfactory when they're just minor compatibility issues or things that could easily be customized locally with a function or two. And maintaining two parallel bits of code for two or more releases is a bit of a chore. I prefer new powerful functions or extended functionality from existing functions!
I think that some of the goals of newLISP are to be as simple as possible, as small as possible, as powerful as possible, and as fast as possible. If you can argue that a change you're proposing can help move towards all of those goals, Lutz may not be able to resist implementing it!
Re: Wish list
Thank cormullion for your feedback.
As for block comment, a string cannot be used as an alternative for a comment in all places. For example, to "comment-out" an item (2) in a list, compare:
And for the syntax, frankly, I don't like [text]...[/text], [cmd]...[/cmd], [comment]...[/comment]. I think its too verbose.
As for nil in 'find' function, if I want to find a (non-regex) substring p in a string s starting at an index position i:
And for inc/dec:
I know that some changes can be implemented by defining my own functions (e.g. my-print, my-inc), but I think they are "normal" and should be "built-in".
As for block comment, a string cannot be used as an alternative for a comment in all places. For example, to "comment-out" an item (2) in a list, compare:
Code: Select all
(list 1 "2" 3) # use string, not valid
(list 1
# 2 # use single-line comment, ok but need to reformat code
3 )
(list 1 #{2}# 3) # if block comment is supported
As for nil in 'find' function, if I want to find a (non-regex) substring p in a string s starting at an index position i:
Code: Select all
(find p (slice s i)) # work, but isn't slice will allocate memory; what if s is a very large string
(find (regex-quote p) s 0 i) # work, if we have defined 'regex-quote' ourselves, it's not built-in
(find p s nil i) # error, nil is not a number!
Code: Select all
(inc 1.2) # => 2, is this expected in most cases?
(float? (inc 1 1)) # => true!
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Re: Wish list
Hi again! We can chat all day about this... :)
I know what you mean about verbosity in the language. However, I think that one of the characteristic of Lutz' newLISP approach is a preference for avoiding puntuation-heavy syntax, so the more verbose versions of things like [text] seem to win out over more compact and possibly ugly character combos. I like that, but I can see your point - an inline comment could be useful.
As for inc - well, you could argue that its main purpose is for incrementing symbols or list elements, and if you're relying on it to do your arithmetic you might be better off using + or add... That's not to say that it's not got it's surprises, though. Luckily the Introduction to newLISP has covered this area... :)
While we're talking about wish lists, how about a built-in version of this:
which is defined to fill the gap between set ...append and push:
And a duplicates function to go with intersect and difference... But I can define my own versions, for now...
I know what you mean about verbosity in the language. However, I think that one of the characteristic of Lutz' newLISP approach is a preference for avoiding puntuation-heavy syntax, so the more verbose versions of things like [text] seem to win out over more compact and possibly ugly character combos. I like that, but I can see your point - an inline comment could be useful.
I'm still struggling with this one. I would have this thought this would work:if I want to find a (non-regex) substring p in a string s starting at an index position i
Code: Select all
(find p (i s))
(find p (i s) 0) ; regex
While we're talking about wish lists, how about a built-in version of this:
Code: Select all
(define-macro (extend)
(setf (eval (args 0)) (append (eval (args 0)) (eval (args 1)))))
Code: Select all
(set 'lst (sequence 0 10))
(push (sequence 11 20) lst -1)
;-> (0 1 2 3 4 5 6 7 8 9 10 (11 12 13 14 15 16 17 18 19 20))
(set 'lst (sequence 0 10))
(set 'lst (list lst (sequence 11 20)))
;-> ((0 1 2 3 4 5 6 7 8 9 10) (11 12 13 14 15 16 17 18 19 20))
(set 'lst (sequence 0 10))
(set 'lst (append lst (sequence 11 20)))
;-> (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
(set 'lst (sequence 0 10))
(extend lst (sequence 11 20))
;-> (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
Re: Wish list
take a slice of s:if I want to find a (non-regex) substring p in a string s starting at an index position
Code: Select all
> (set 's "abcdefg")
"abcdefg"
> (find "de" (2 s))
1
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: Wish list
For the inc/dec request, I must concur. The int/float conversion rules are confusing.
Could we have ++ and -- for integer operations, and inc/dec for floating operations? This would be consistent with the difference between + and add.
Ted
Could we have ++ and -- for integer operations, and inc/dec for floating operations? This would be consistent with the difference between + and add.
Ted
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: Wish list
For the multiline comment, couldn't you just make "comment" macro? For instance,
(comment
blah blah blah
...
)
(comment
blah blah blah
...
)
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
Re: Wish list
I would support the addition of the following two Scheme comment forms:
#;(s-expression)
#| block comment |#
Since the newLISP parser already checks for # comments, this would have the least impact when implementing. (And the Schemers have already fought out the "correct and proper" syntax for us, so text editors hopefully will suport it too ;p)
http://en.wikipedia.org/wiki/Scheme_(pr ... )#Comments
#;(s-expression)
#| block comment |#
Since the newLISP parser already checks for # comments, this would have the least impact when implementing. (And the Schemers have already fought out the "correct and proper" syntax for us, so text editors hopefully will suport it too ;p)
http://en.wikipedia.org/wiki/Scheme_(pr ... )#Comments
-- xytroxonComments
Up to the R5RS standard, the standard comment in Scheme was a semicolon, which makes the rest of the line invisible to Scheme. Numerous implementations have supported alternative conventions permitting comments to extend for more than a single line, and the R6RS standard permits two of them: an entire s-expression may be turned into a comment (or "commented out") by preceding it with #; (introduced in SRFI 62 [17]) and a multiline comment or "block comment" may be produced by surrounding text by #| and |#.
"Many computers can print only capital letters, so we shall not use lowercase letters."
-- Let's Talk Lisp (c) 1976
-- Let's Talk Lisp (c) 1976
Re: Wish list
Lutz,
Yes `slice` works, but in this case it will unnecessary allocate memory, right? It's not good if (find p (i s)) is used in a loop, when s is very large.
TedWalther,
comment macro does not work.
xytroxon,
In my opinion, I think #{...}# is better than #|...|#, because it's easier to match the end of comment by using `%` in vim.
Yes `slice` works, but in this case it will unnecessary allocate memory, right? It's not good if (find p (i s)) is used in a loop, when s is very large.
TedWalther,
comment macro does not work.
Code: Select all
(define-macro (comment))
(list 1 (comment 2) 3) # => (1 nil 3), not (1 3)
In my opinion, I think #{...}# is better than #|...|#, because it's easier to match the end of comment by using `%` in vim.
Re: Wish list
Thanks for all the suggestions. Some of them are covered in the next release.
-
- Posts: 388
- Joined: Thu May 08, 2008 1:24 am
- Location: Croatia
- Contact:
Re: Wish list
Maybe some more general solution
(modify 'x + y) <=> (set 'x (+ x y))
(modify 'x append y) <=> (set 'x (append x y))
(modifyf x append y z) <=> (setf x (append x y z))
(modifyf x + y) <=> (setf x (+ x y))
This allows for slightly shorter, flatter but also slightly faster code, and weight is only one or two extra symbols.
For inc, I agree with Ted, ++ is constent here.
(I'd repeat my old proposal for +., *. etc for floating point +, * etc.)
(modify 'x + y) <=> (set 'x (+ x y))
(modify 'x append y) <=> (set 'x (append x y))
(modifyf x append y z) <=> (setf x (append x y z))
(modifyf x + y) <=> (setf x (+ x y))
This allows for slightly shorter, flatter but also slightly faster code, and weight is only one or two extra symbols.
For inc, I agree with Ted, ++ is constent here.
(I'd repeat my old proposal for +., *. etc for floating point +, * etc.)
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Re: Wish list
Look forward with interest, Lutz - and slight trepidation... :)
Just thinking out loud - is there any use for a function that doesn't return anything at all? This could have various uses - Ted's comment idea - and other people have asked about the silent function. Yes, it would be inconsistent and a bit odd, but possibly useful in a number of different contexts...
Just thinking out loud - is there any use for a function that doesn't return anything at all? This could have various uses - Ted's comment idea - and other people have asked about the silent function. Yes, it would be inconsistent and a bit odd, but possibly useful in a number of different contexts...
Re: Wish list
Thanks a lot, Lutz! Curious about which wishes will come true ;-)
Kazimir, I like your floating-point operators (+., *., etc), first found it in your library, and hope they will be built-in too, so they will be standard names. Currently I do:
As for, `modify`, I think using `$it` with `set` is OK
Kazimir, I like your floating-point operators (+., *., etc), first found it in your library, and hope they will be built-in too, so they will be standard names. Currently I do:
Code: Select all
(setq +. add -. sub *. mul /. div %. mod)
Code: Select all
(setq x (+ $it y))
(setq x (append $it y z))
-
- Posts: 394
- Joined: Wed Apr 26, 2006 3:37 am
- Location: Oregon, USA
- Contact:
Re: Wish list
Well, here comes my two cents ;-)
Block comments would be nice, but I've been getting along without them. I can see where they would save a lot of work without editor support, though.
I like the symmetry of ++/inc and +/and, but I also like Kazimir's Caml-like +., -., etc., for the floating point versions of these operators, which contradicts the first option. ++. and --. perhaps? :-)
cormullion's suggestion sounds like a void function:
I do find it distracting sometimes to see the output and the result from the print functions together. Since silent even silences the prompt, I often type (print "> ") at the end of my calls to silent so I'm not confused by the missing prompt.
Thanks for reminding me about the use of $it within the set functions, kks. I had forgotten about that.
Let's see, that looks to add up to about 1-3/4 cents. Close enough!
m i c h a e l
Block comments would be nice, but I've been getting along without them. I can see where they would save a lot of work without editor support, though.
I like the symmetry of ++/inc and +/and, but I also like Kazimir's Caml-like +., -., etc., for the floating point versions of these operators, which contradicts the first option. ++. and --. perhaps? :-)
cormullion's suggestion sounds like a void function:
Code: Select all
> (println "a" "b" "c")
abc
"c"
> ;; simulating a void function:
> (define (void) (silent) (print "> "))
(lambda () (silent) (print "> "))
> (void)
> (begin (println "a" "b" "c") (void))
abc
> _
Thanks for reminding me about the use of $it within the set functions, kks. I had forgotten about that.
Let's see, that looks to add up to about 1-3/4 cents. Close enough!
m i c h a e l
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Re: Wish list
hi m i c h a e l! Nice to see you again. A nice void you've gotten us into, although yours is a cheshire-cat of a function, leaving a grin behind:
- it's whimsical, but I'm not sure it makes for readable inline comments anyway...
Code: Select all
(list "a" "b" (void) "d")
-> ("a" "b" nil "d")
Re: Wish list
I'ld like to see something like (== for the equality test and (= for (set (setq and (:= for (setf, but precedent tends to limit what you can do now and would be confusing to those coming from other Lisps.kks wrote: xytroxon,
In my opinion, I think #{...}# is better than #|...|#, because it's easier to match the end of comment by using `%` in vim.
Likewise, #|...|# is the block comment form for Common Lisp, hence is more likely to be recognized/expected by Lispers and Schemers, and be recognized by editors highlighting parser...
The Schemer's in-line comment is useful when experimentally trying out two forms of a function, especially if they have long argument lists.
(s-exp1 #;(s-exp2a ...) (s-exp2b ...) ...)
But editors are less likely to properly terminate the highlighted inline comment...
-- xytroxon
"Many computers can print only capital letters, so we shall not use lowercase letters."
-- Let's Talk Lisp (c) 1976
-- Let's Talk Lisp (c) 1976
Re: Wish list
like ocaml, right?Kazimir Majorinc wrote: (I'd repeat my old proposal for +., *. etc for floating point +, * etc.)
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: Wish list
I like the proposed #; and #| comment forms, because of their compatibility with existing syntax hilighters. #; particularly has me excited.
As for Kazimirs +. ++. forms, those can be done as constants, right? I sort of liked the FORTRAN feel of add, sub, mul, etc.
For the == instead of =, I must disagree. Personally I have started using unicode characters in my code; for setf I use the unicode left-arrow character. For "and" and "or" and "find" I use some of the operators from set logic. UTF8 support is GREAT!
When I am doing trig, it is SOOO nice to be able to name variables "phi" and "theta", and be able to use the actual Greek letter instead of having to spell it out!
Yes, I had to configure vi a tiny bit to make it do auto-substitutions of some key sequences into their UTF8 form, but it leads to beautiful looking code.
Ted
As for Kazimirs +. ++. forms, those can be done as constants, right? I sort of liked the FORTRAN feel of add, sub, mul, etc.
For the == instead of =, I must disagree. Personally I have started using unicode characters in my code; for setf I use the unicode left-arrow character. For "and" and "or" and "find" I use some of the operators from set logic. UTF8 support is GREAT!
When I am doing trig, it is SOOO nice to be able to name variables "phi" and "theta", and be able to use the actual Greek letter instead of having to spell it out!
Yes, I had to configure vi a tiny bit to make it do auto-substitutions of some key sequences into their UTF8 form, but it leads to beautiful looking code.
Ted
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: Wish list
For any who may be interested, here is my init.lsp. It shows the beautiful things you can do now that we have UTF8 support!
Code: Select all
; Standard C/Unix filehandles that are open on startup
(constant
(global 'stdin) 0
(global 'stdout) 1
(global 'stderr) 2)
(define (dirname path) (join (chop (parse path "/|\\\\" 0)) "/"))
(define (basename path) (last (parse path "/|\\\\" 0)))
; Some arithmetic functions
(constant
(global 'negative?) <
(global 'positive?) >)
(define (divisible? i j) (= (mod i j) 0))
(constant
(global 'pi) (mul 4 (atan 1))
(global 'radians/degree) (div pi 180)
(global 'degrees/radian) (div 180 pi))
(define (radians deg) (mul deg radians/degree))
(define (degrees rad) (mul rad degrees/radian))
(constant (global 'do) begin)
; union 222a intersection 2229
(constant '≠ !=) # 2260 not equal
(constant '≡ =) # 2261 identical to
(constant '∈ find) # 2208 element of
(constant '≤ <=) # 2264 less than or equal
(constant '≥ >=) # 2265 greater than or equal
(constant '∀ dolist) # 2200 for all
(constant '× mul) # 00D7 multiply
(constant '÷ div) # 00F7 divide
(constant '√ sqrt) # 221A square root
(constant '⌈ ceil) # 2308 integer ceiling
(constant '⌊ floor) # 230A integer floor
(constant '⋀ and) # 22C0 n-ary logical and
(constant '⋁ or) # 22C1 n-ary logical or
(constant '⟵ setq) # 27F5 assignment
(constant '¬ not) # FFE2,00AC logical not
(constant '⋂ intersect) # 22C2 set intersection
(constant '⋃ append) # 22C3 set union
(define (∑ lst) # 2211 n-ary summation
(apply add lst))
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
-
- Posts: 394
- Joined: Wed Apr 26, 2006 3:37 am
- Location: Oregon, USA
- Contact:
Re: Wish list
Hi cormullion!
The operative word in my example is "simulating" ;-) Lutz would have to implement it properly to have the correct effect.
I've been quietly working on exploring FOOP (especially the new mutability!) and putting together another video. Hope to have something to share in the near future.
m i c h a e l
The operative word in my example is "simulating" ;-) Lutz would have to implement it properly to have the correct effect.
I've been quietly working on exploring FOOP (especially the new mutability!) and putting together another video. Hope to have something to share in the near future.
m i c h a e l
Re: Wish list
thanks Michael, for taking care of this! I hope the last fixes for 'self' work for all situations one might encounter. The test routines you emailed me have been appended the modified qa-foop file (v10.1.9).… and putting together another video
FOOP is ready for primetime now!
… and still functional enough to call it FOOP :)
ps: several suggestions in this thread have been implemented and we will have another development release before 10.2.
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Re: Wish list
Lutz - I'm currently using both FOOP version 0 and FOOP version 1. v0 works for current stable releases, v1 works for curent development releases. Eg http://unbalanced-parentheses.nfshost.c ... ly_twitter is using v0 because NFS is on v0 (ie 10.1).
Is there a way to add compatibility to v1 to work with v0? Or a way to define things so that allow the newLISP installation can be upgraded without me having to write separate versions of the FOOP file?
Is there a way to add compatibility to v1 to work with v0? Or a way to define things so that allow the newLISP installation can be upgraded without me having to write separate versions of the FOOP file?
-
- Posts: 394
- Joined: Wed Apr 26, 2006 3:37 am
- Location: Oregon, USA
- Contact:
Re: Wish list
You're welcome! I'm very happy to help in my small way.Lutz wrote:thanks Michael, for taking care of this!
I've been really exercising self quite a bit lately. It's performing brilliantly. Feels very natural for both newLISP and programming with objects.Lutz wrote:I hope the last fixes for 'self' work for all situations one might encounter.
I keep meaning to ask you something, Lutz. When you say:Lutz wrote:and still functional enough to call it FOOP :)
It makes me wonder if having constructors with default arguments breaks with this:Lutz wrote:The fact that each object in FOOP is the functional expression which generates itself - its own constructor expression - still justifies the 'F' in FOOP.
Code: Select all
> (new Class 'Point)
Point
> (define (Point:Point (x 0) (y 0)) (list (context) x y))
(lambda ((x 0) (y 0)) (list (context) x y))
> (Point)
(Point 0 0)
> _
What I do know is that coding in FOOP has been more fun than programming in traditional object-oriented languages. So FOOP may as well stand for Fun Object-Oriented Programming! Or another F-word when I can't get the damn code to work ;-)
m i c h a e l
Re: Wish list
Yes, when you modify the default constructor functional analogy of object<->construtor is somewhat different, but not broken. Then there is also the new (self) a Function to reference the target object of the message.
Regarding old/new FOOP compatibility. I don't see an easy automated way, but at least it is easy to port from old to new by simply renaming the object parameter in old FOOP code to 'self':
Of course this doesn't take advantage of object mutability, which enables shorter and faster code for modifying objects. But at least old code can quickly be prepared and made work for the switch-over to a newer newLISP version.
I would probably just code two sections (or even files): one for old, one for new FOOP and then decide by the version number in 'sys-info'.
We also could invent some sort of tag-line including both the word Fun and Functional and leaving the interpretation open to the public?Fun Object-Oriented Programming
Regarding old/new FOOP compatibility. I don't see an easy automated way, but at least it is easy to port from old to new by simply renaming the object parameter in old FOOP code to 'self':
Code: Select all
; old FOOP code original
(define (method obj p1 p2)
…
(… (obj 1) …)
)
; old FOOP code prepared for upgrade
(define (method self p1 p2)
…
(… (self 1) …)
)
; new FOOP code after taking ode self from the parameter list
(define (method p1 p2)
…
(… (self 1) …)
)
I would probably just code two sections (or even files): one for old, one for new FOOP and then decide by the version number in 'sys-info'.
-
- Posts: 394
- Joined: Wed Apr 26, 2006 3:37 am
- Location: Oregon, USA
- Contact:
Re: Wish list
I think FOOP is as much about fun as it is about fitting gracefully into a functional language. I'm delighted by how well FOOP blends with newLISP. And besides, functional has another meaning that might be the most appropriate yet:Lutz wrote:We also could invent some sort of tag-line including both the word Fun and Functional and leaving the interpretation open to the public?
Of course, I find FOOP attractive, too, but it's definitely practical and useful. The complexity of the object models I've done in newLISP blows away anything I've managed to accomplish in other languages.designed to be practical and useful, rather than attractive.
Leaving it open to interpretation is fine by me. A rose by any other name . . .
This is ingenious, Lutz.Lutz wrote:but at least it is easy to port from old to new by simply renaming the object parameter in old FOOP code to 'self'
Back to FOOPin',
m i c h a e l