Mark Wooding wrote: > Majorinc Kazimir <fa...@email.address> writes:
>> (1) Unrestricted eval, i.e. eval can access to local variables. CL and >> Scheme evals cannot do that.
> Indeed. It's a tradeoff between efficient compilation and EVAL: if the > compiler is given the necessary freedom to arrange a function's > environment in the most efficient manner, then either EVAL will be > horrifically complicated or just won't be able to `see' lexically bound > variables.
So, CL chose an option that leads to speed, and Newlisp chose the option that leads to expressive power. That is exactly what I said.
> Emacs Lisp does this, by the way.
>> Eval is, in my opinion, single most important feature for >> code=data.
> Ahh. I think I'd put efficient and comprehensible macros and ready > availability of COMPILE rather higher.
So, you value speed more than expressive power. OK. I do not.
>> (2) Fexprs, i.e. "the first class" macros.
> The `F' stands for `funny'. Interestingly, fexprs were the cause of > many of the problems that macros were introduced to fix, most notably > the fact that very existence of fexprs the compiler doesn't have > built-in knowledge about makes it nearly impossible to compile correct > code.
So, CL chose the path that leads to speed, Newlisp chose the path that leads to expressive power.
>> (3) Newlisp has support for dynamic and static scope. Local variables >> are dynamically scoped. The namespaces, called "contexts" are >> statically scoped. That allows significantly more expressive >> functions than in dialects with statically scoped local variables.
> Of course, CL has both anyway, with lexical scoping as the (correct) > default. Proper lexical scoping is, of course, the right solution to > the famous historical `funargs' problem.
So, CL chose the path that leads to what? Safety? Newlisp chose the path that leads to expressive power.
The funarg is however, not the problem is Newlisp practice.
There are few reasons for that. One reason is that people simply use support for lexical scope existing in language.
Other reason is that funarg problem is not really that hard - even if one decide to use only dynamic scope.
>> (4) The Functions are lambda-expressions, not results of the >> evaluation of lambda expressions. That means, program can analyze >> and modify functions during runtime. And the same is the case for >> macros.
> Oh, heavens. Look, if you want Emacs Lisp, you know where to find it. > But it really isn't very new.
So, where are we now? You gave up from CL and you are trying to compare Newlisp with Emacs Lisp. Then go back to fexprs vs macros, Newlisp has fexprs, Emacs has macros.
>> (5) Newlisp is an intepreter. That means, if you want speed, you are >> in the same league as Python or Perl. But, if your code contains >> lot of evals - Newlisp is faster than many other Lisps.
> You don't have to be mad to write programs which make heavy use of EVAL > but, no, wait, you do.
Mad? Yeah right pal, I have to go, good luck to you ... :)
On Mon, 19 Jan 2009 14:21:33 +0100, Matthias Buelow wrote: > Andrew Reilly wrote:
>> Sure, but outside of demonstrations of fibbonaci sequences, and perhaps >> some crypto libraries (that know deterministically that they'll be >> using large numbers, and can be coded accordingly), who realistically >> gets milage from the smooth transition to bignums
> It doesn't matter; if only fixnums are available, then that's a > (somewhat arbitrarily defined) restriction that doesn't have to be > there, that's enough reason to hate it.
That's a good answer. Thanks. In fact, it was pretty much exactly my own reaction, during my first encounter with lisp and scheme, and my first year of coding in scheme. More recently, though, I've been thinking about implementation issues (I guess I'm not alone in wanting to write my own, having read "the art of the interpreter"...) and it just seems that the cost of that capability is quite high. Perhaps not in the grand scheme of things, and not when coding at a high level on file or GUI-related things, but it's got to hurt when you try to write tight computational kernels or low-level "bit-bashing" controller code. Maybe having a switch to force the issue when you know you want to, and having a fully flexible and abstract default is the right answer after all...
On Tue, 20 Jan 2009 01:33:55 +0100, Majorinc Kazimir wrote: > Mark Wooding wrote:
> So, CL chose an option that leads to speed, and Newlisp chose the option > that leads to expressive power. That is exactly what I said.
>> Ahh. I think I'd put efficient and comprehensible macros and ready >> availability of COMPILE rather higher.
> So, you value speed more than expressive power. OK. I do not.
>> The `F' stands for `funny'. Interestingly, fexprs were the cause of >> many of the problems that macros were introduced to fix, most notably >> the fact that very existence of fexprs the compiler doesn't have >> built-in knowledge about makes it nearly impossible to compile correct >> code.
> So, CL chose the path that leads to speed, Newlisp chose the path that > leads to expressive power.
>> Of course, CL has both anyway, with lexical scoping as the (correct) >> default. Proper lexical scoping is, of course, the right solution to >> the famous historical `funargs' problem.
> So, CL chose the path that leads to what? Safety? Newlisp chose the path > that leads to expressive power.
You keep repeating "expressive power", but that doesn't make it true. Examples, please? I would like to see that enormous amount of expressive power that the modifications buy you.
Expressive power. Expressive power. Expressive power. Wow man, just saying it makes me feel super-powerful. Ok, back to work, let's see those examples of extreme expressive expressive expressive power.
> On Mon, 19 Jan 2009 14:21:33 +0100, Matthias Buelow wrote:
>> Andrew Reilly wrote:
>>> Sure, but outside of demonstrations of fibbonaci sequences, and perhaps >>> some crypto libraries (that know deterministically that they'll be >>> using large numbers, and can be coded accordingly), who realistically >>> gets milage from the smooth transition to bignums
>> It doesn't matter; if only fixnums are available, then that's a >> (somewhat arbitrarily defined) restriction that doesn't have to be >> there, that's enough reason to hate it.
> That's a good answer. Thanks. In fact, it was pretty much exactly my > own reaction, during my first encounter with lisp and scheme, and my > first year of coding in scheme. More recently, though, I've been > thinking about implementation issues (I guess I'm not alone in wanting to > write my own, having read "the art of the interpreter"...) and it just > seems that the cost of that capability is quite high.
The cost of that capbility is buried in dynamic typing. A value coming into your function can already be anything whatsoever: string, symbol, vector, struct, fixnum, real, etc.
So unless you have the assurance of a declaration, and safety is set to zero, you /have/ to look at the type.
You /have/ to handle overflow, unless you're designing some unreliable programming language that allows overflows situations to silently proceed with wrong answers.
In terms of efficiency, what does it matter that your integer overflow handler takes the extra step of producing a bignum?
Even you don't make the bignum, you still have to check the type, to make sure the operands to the arithmetic operation are numbers, still have to handle overflow, still have to handle combinations of operands that are mixtures of floating point numbers, etc.
> Perhaps not in the > grand scheme of things, and not when coding at a high level on file or > GUI-related things, but it's got to hurt when you try to write tight > computational kernels or low-level "bit-bashing" controller code.
The question is, what spectacular thing could you do by removing bignums from the dynamic language, which would eliminate this alleged hurt?
The right tool is not removing the support for the bignum type, but dropping down to manifest typing over well-defined sections of code.
On 2009-01-20, Majorinc Kazimir <fa...@email.address> wrote:
> Mark Wooding wrote: >> Majorinc Kazimir <fa...@email.address> writes:
>>> (1) Unrestricted eval, i.e. eval can access to local variables. CL and >>> Scheme evals cannot do that.
>> Indeed. It's a tradeoff between efficient compilation and EVAL: if the >> compiler is given the necessary freedom to arrange a function's >> environment in the most efficient manner, then either EVAL will be >> horrifically complicated or just won't be able to `see' lexically bound >> variables.
> So, CL chose an option that leads to speed, and Newlisp > chose the option that leads to expressive power.
s/expressive/excrement/
99% of the time when you think you need eval with lexical access, it's because you're a Lisp newbie who hasn't figured out APPLY, macros, local functions, etc.
Recently I used eval-with-access-to-locals in a Bash script. I did that because Bash doesn't have macros. Actually no, the problem could have been solved with a local function. Not having local functions, or macros, I had to fall back on eval. Take the code that should have been put into a local function body, as a character string, and evaluate it.
Yeah, bash has excrement power too!
newLISP isn't even a language, just an implementation.
There are Common Lisps that have access to lexical environment as an extension. E.g. look at environments in Allegro CL.
It's just not specified in the ANSI standard.
newLISP doesn't have an ANSI standard. Its behavior is whatever the current release of the code does.
Comparing the newLISP to the language described in an ANSI standard is idiotic. Why don't you compare newLISP to various CL implementations, in turn?
Compare language to language, implementation to implementation.
Man, Lisp /must/ be getting popular now. Two Kazimirs in the newsgroup. Too bad one of them is drooling dummy, pushing newLISP.
> The interesting thing is whether Newlisp makes > it easier to solve real-world problems. Just > saying "it's good for code=data" is too abstract > a claim without real examples to back it up. > > They need to be examples of problems that would > be hard to solve in Common Lisp but are easier > to solve in Newlisp.
> In short, what problem is it that Newlisp > was created to solve? > > Thank you!
Author, Lutz Mueller wanted simpler Lisp, useful for "small programming", i.e. what is today called scripting. He does not market Newlisp as especially powerful language, quite contrary, he presents it as a language simple and fun to use and learn, with good "built in" support for different "real world" needs like web protocols. Majority of discussions on forum are about such issues - how to use Newlisp for webserver, creating some graphics etc.
But, although it was not the main intention of the author, Newlisp has the features I mentioned, partly because modern computers are much better, so there was far less pressure for various optimizations.
> I would be interested to see some examples of what > problems you'd want to solve that work out better > in Newlisp than they do in, say, Common Lisp.
Example for functions identical to their definitions: ----------------------------------------------- Once I wanted to "infect" SOME functions with extra code during runtime, and later to clean that extra code from functions. Wraping around function was not enough, code had to be inserted in function definitions.
It had to be done WITHOUT knowledge and cooperation of infected function, these had to be ordinary, user defined functions, not purposely prepared to be infected.
It turned to be easy in Newlisp, because functions are just lambda-expressions, they can be processed like any list.
Example for unrestricted eval: -----------------------------
What macros actually do? They behave *like* functions that produce code and - evaluate that code in the caller environment once again.
Sure, macros have other specificities, they are not functions, they are not evaluated but expanded, etc, but those two things interest me now: code generation and evaluation in the caller environment.
Now, what if one wants code transformation, but macros are not suitable (1) because they are not the first class, (2) code transformation is not known in macro expansion time, or especially interesting (3) because they are just too big to be used for every small code transformation one can imagine? People do not define functions for every expression they evaluate, why should they define macros for every code transformation they do?!
OK, in that case, code transformations can be done without macros, using normal Lisp expressions, possibly functions - but resulting code has to be EVALUATED ONCE MORE in the caller environment, explicitly. And Newlisp has exactly such eval, eval able to access to local variables.
More specifically, lets say one need macro m which has to be determined during runtime. In CL, such macro cannot be defined (without eval). But it can be replaced with function f that does exactly the same code transformation. So, instead of impossible
(m expr1 ... exprn)
it is possible to write
(eval (f 'expr1 ... 'exprn))
Functional version works, because functions are the first class citizens. Macro version doesn't. But, eval able to access to local variables needs to be inserted.
If one takes a look on Newlisp code, it is full of evals. Some of these evals could be replaced with macros - but many of those would be ultrasmall "define once - use once" macros, it is just more trouble defining macros than applying eval directly on the result of some expression. Some evals couldn't be replaced with macros at all.
Example for dynamic scope: -------------------------- Define IF as function.
(let ((x 2)(y 3)) (IF '(< x y) '(println x " is less than " y) '(println x " is not less than " y))
(IF '(> x y) '(println x " is greater than " y) '(println x " is not greater than " y)))
It works in Newlisp.
This particular definition of IF is complicated, because I did it as game - IF is not only function, but it is defined without built in operators like IF and COND, and also, without using any variable.
Many other - less extravagant definitions are possible.
More generally, whenever one can define macro, he can define equivalent function as well.
Example for first-class macros -------------------------------------------- Experienced Lisper probably noted that he sometimes write macros only because it is impossible to write equivalent function. Also, that he sometimes write functions although macros would be syntactically better, but he needs the first class citizens.
In Newlisp, macros are fexprs, whenever one can write the function, he can write macro that does the same and vice versa. Both have the advantages and disadvantages resulting from its syntax and semantics. Because of that, it is possible to define two functions:
jos...@corporate-world.lisp.de wrote: > * CLOS should be wider used (conditions, pathnames, streams, i/o, > readtables, ...) > * get rid of structures, provide a simple DEFCLASS* macro, > make SLOT-VALUE as fast as structure access > * all built-in function (minus primitive type specialized functions) > functions > should be generic functions
Sounds very C++-ish.. I don't think it's a good idea to OO-ize the basic language. That's a too low abstraction layer.
Majorinc Kazimir wrote: > Experienced Lisper probably noted that he sometimes > write macros only because it is impossible to write > equivalent function.
I thought that was the only reason to use macros.
> Also, that he sometimes write > functions although macros would be syntactically better,
When would that be the case?
> In Newlisp, macros are fexprs, whenever one can write > the function, he can write macro that does the same > and vice versa.
On 20 Jan., 13:51, Matthias Buelow <m...@incubus.de> wrote:
> jos...@corporate-world.lisp.de wrote: > > * CLOS should be wider used (conditions, pathnames, streams, i/o, > > readtables, ...) > > * get rid of structures, provide a simple DEFCLASS* macro, > > make SLOT-VALUE as fast as structure access > > * all built-in function (minus primitive type specialized functions) > > functions > > should be generic functions
> Sounds very C++-ish.. I don't think it's a good idea to OO-ize the basic > language. That's a too low abstraction layer.
No, it's more like the language ZetaLisp from which CL was mostly derived by simplifying. ZetaLisp and the software written in it was heavy object-oriented using Flavors. Common Lisp got designed in version 1 without an object system - just because there was not a single one that was agreed on at that time and there were several different ones researched/ implemented. Some were using Flavors. Xerox was using LOOPS. LMI was using Object Lisp. HP was proposing Common Objects, Intellicorp used Units, Coral was using Object Lisp, Germans had some other proposals, there were systems in France, ...
So we got CLtL1 without an object system, though almost everyone was already using some quite heavily.
Then CLOS got developed and added to CL. CLOS was designed in such a way that many projects could move their code to CLOS by extending CLOS with the necessary facilities.
But unfortunately Common Lisp the language got not redesigned to a state that would represent 'the reality' - meaning all major implementations of CL and the languages that CL was mostly based on, were using objects (Flavors, LOOPS, Object Lisp, Common Objects, Units, New Flavors, CommonLOOPS, ...). CLtL1 was mostly an accident. CLtL1 is a dent in time and space. Unfortunately it shaped ANSI CL too much.
Dylan then simplified CL by usind a CLOS derivative everywhere possible. Most CL implementations have CLOS-based implementations of important parts - unfortunately ANSI CL only specifies a non CLOS interface. So I can't subclass stream in ANSI CL. Most CL implementations use something like gray streams. Why should I use READ-CHAR when it calls a generic function anyway? I could either get rid of READ-CHAR and use the generic function STREAM-READ-CHAR directly
There is a layer of interface that can be removed without any loss of functionality. It would make the language more extensible - in a way that most implementations provide anyway. Implementations provide extensible streams and applications are using them. Today.
DESCRIBE calls DESCRIBE-OBJECT. Just get rid of DESCRIBE and replace it with the generic function DESCRIBE-OBJECT renamed.
We have efficient maths in CL so it should possibly not use CLOS, but we don't have efficient streams anyway, since they are implemented using CLOS (or with CLOS tacked on some internal implementation strategy).
The design needs to be understood based on its history. There are opportunities to simplify CL AND adding flexibility and power. Many applications already are developed with some kind of extended CL (non-portable, or via portability libs).
>> Experienced Lisper probably noted that he sometimes >> write macros only because it is impossible to write >> equivalent function.
> I thought that was the only reason to use macros.
Sometimes there are other reasons, because of prettier syntax OR some speed up due to macroexpansion. For example, if you note that you use function calls only with constant arguments, (f 3), (f 7), but never (f x) it *could* be useful to rewrite f as macro. Or (g '(+ x 1)), (g '(- x 1)) but never (g (+ x 2)). Not always, but typically yes.
OK?
>> Also, that he sometimes write >> functions although macros would be syntactically better,
> When would that be the case?
Macros are typically syntactically better, because there are no extra apostrophes. Typically, macros cannot be used instead of functions in CL. Sometimes they can, g from previous example.
Majorinc Kazimir <fa...@email.address> writes: > So, CL chose an option that leads to speed, and Newlisp chose the > option that leads to expressive power. That is exactly what I said.
Err..., no, MACLISP chose speed and Common Lisp followed.
I've got an Interlisp manual from 1973 in front of me, and it looks as if Interlisp would happily compile functions which called fexprs, though you had to warn it in advance which symbols denoted fexprs. Since many fexprs actually want only some of their arguments unevaluated, they'll call EVAL on the others, and drop back into the interpreter. Fortunately the compiler had macros as well, so you could write a macro version of your fexpr for the compiler to chew on. A 1985 manual for Interlisp-D explains that the interpreter also honours macros, though the behaviour differs if a symbol has both function and macro definitions: the interpreter prefers the symbol's function cell while the compiler prefers the macro.
I think this demonstrates that the move from fexprs to macros wasn't just limited to the MACLISP community, and that Common Lisp's loss of fexprs was probably viewed as leaving behind a historical misstep rather than sacrificing critical expressiveness. I stand ready to be corrected on this by people who were actually there, though.
Besides, briefly comparing the lengths of the trivial programs from your `benchmark' -- discussion of which you have avoided, I note -- tells me everything I need to know about the comparative expressive power of Common Lisp (or even Emacs Lisp) and newLISP.
Besides, you brought up the issue of speed yourself, with your bogus benchmark. If you're not interested in speed, why did you bring the question up in the first place? Note also that the newLISP website claims `fast' as an important feature: `Friendly --- fast --- small' is the entire first bullet point. `Slower than Emacs Lisp' doesn't sound quite so good, does it?
(Note the correct capitalization of `newLISP', by the way. It's strange that you advocate it, but type its name incorrectly throughout.)
[scoping]
> So, CL chose the path that leads to what? Safety? Newlisp > chose the path that leads to expressive power.
CL followed Scheme down the path to comprehensible programs which can be built out of modules understood in isolation (lexical scope allows the reader to prove to himself that various kinds of side effects are impossible -- even, by CL rules, if the code invokes EVAL), and which make use of closures.
> The funarg is however, not the problem is Newlisp practice.
Presumably because newLISP has, for some reason, shied away from the expressive power of proper functional abstraction.
> So, where are we now? You gave up from CL and you are trying to > compare Newlisp with Emacs Lisp. Then go back to fexprs vs macros, > Newlisp has fexprs, Emacs has macros.
I prefer Common Lisp to Emacs Lisp, because CL has proper closures, lexical scoping, bignums, keyword arguments, CLOS, and many other good things. Emacs Lisp is stuck in a timewarp, because it follows the traditional MACLISP interpreter semantics (rather than the compiler), but it's tolerable. If you like those traditional semantics, then I've shown that Emacs Lisp is quite considerably faster than newLISP -- at running your own benchmark! -- leaving newLISP without an obvious niche. After all, it doesn't even have a built-in text editor.
Hmmm. Extensive use of eval. Dynamic scoping. Code as data. Non-sharing of lists. Don't care too much about performance. I've got the very thing! comp.lang.tcl is right over there.
Majorinc Kazimir wrote: > For > example, if you note that you use function calls only > with constant arguments, (f 3), (f 7), but never > (f x) it *could* be useful to rewrite f as macro.
Sorry, I don't understand this example.
> Or > (g '(+ x 1)), (g '(- x 1)) but never (g (+ x 2)). Not > always, but typically yes.
> OK?
Nope.
> Macros are typically syntactically better, because > there are no extra apostrophes.
What's "syntactically better"? Generally, if I see something like (g (+ x 2)) I expect that g is called with the result of evaluating (+ x 2) and not getting the unevaluated list. Macros should be used sparingly because of considerations like these.
> Typically, macros cannot > be used instead of functions in CL. Sometimes they can, g > from previous example.
Majorinc Kazimir <fa...@email.address> writes: > Now, what if one wants code transformation, but macros are not > suitable (1) because they are not the first class, (2) code > transformation is not known in macro expansion time, or especially > interesting (3) because they are just too big to be used for every > small code transformation one can imagine?
In what possible sense is can a macro be `too big'?
> People do not define functions for every expression they evaluate, why > should they define macros for every code transformation they do?!
Err... Is there some problem I don't understand with MACROLET?
> More specifically, lets say one need macro m which has to be > determined during runtime.
[etc.]
Your `examples' presume that one is in the situation where one needs the feature in question: it's a circular argument. I'd like some actual /examples/ -- practical, and concrete -- which demonstrate /why/ one might find oneself in this situation in the first place.
> If one takes a look on Newlisp code, it is full of evals. Some of > these evals could be replaced with macros - but many of those would be > ultrasmall "define once - use once" macros, it is just more trouble > defining macros than applying eval directly on the result of some > expression.
Common Lisp gives you two choices here. Either MACROLET, which is ideal for one-shot macros (which replace boring repetitive code), or #.(...) to hack the right code together at read-time.
> Some evals couldn't be replaced with macros at all.
Again, examples please, not circular arguments or hand-wavy abstract nonsense.
> The arguments used in this thread are not new. They were used over > 2000 years ago when ancient Egyptian scribes were improving their > hieroglyphic alphabet. Some of the hieroglyphs represented consonants, > so they could be used the same way as phonetic letters. The idea of > using phonetic hieroglyphs ONLY was a total insanity according to the > scribes, because hieroglyphs representing words were much more terse; > they saved time and parchment. A professional scribe knew over 5000 > hieroglyphs. From his point of view, someone who knew only the > phonetic hieroglyphs was an illiterate idiot wasting parchment.
> The ancient Greeks also used fairly complex hieroglyphic script > (called Linear B) before Dorian invasion destroyed their civilization. > After the invasion there were no professional scribes left, so a new > script "for illiterate idiots" had to be invented. The new script was > entirely phonetic, and so simple that anyone could learn it in a few > days. All modern Europeans use a modified version of this script.
> In my opinion the Common Lisp resembles the ancient hieroglyphs, as > well as cars with manual transmission (for professional drivers), and > obsolete Unix computers (for computer professionals)... Common Lisp > can do the work efficiently, but is too complex for part-time > programmers. Most programmers alive today are part-time programmers. > Many of them spend as much time writing AutoLISP programs as driving a > car, but they do not consider themselves professional programmers or > professional drivers. Computer programming is just one of many skills > they need in everyday life. It seems that the newLISP is simple enough > and terse enough for billions of part-time programmers. It is more > terse (clean) than Scheme and more mature than Pico Lisp.
>> On 2009-01-18 18:14:08 -0500, andrew.nowicki...@gmail.com said:
>>> The largest positive integer you can have in newLISP is 9 223 372 036 >>> 854 775 807, and the largest negative integer is -9 223 372 036 854 >>> 775 808.
>> An no one *ever* needs integers larger than that so common lisp's >> automatic overflow detection and bignums are pointless, right? For >> example, the thousandth fibonacci number is much smaller than newlisps >> integers, right?
> Who needs a number that big? Even the Zimbabwe needs only 15 digits.
For instance people who need to do very, very precise calculations? Finance is not the only candidate for that. And I've seen enough people using float for that *shudder*
Regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison
sly> obsolete Unix computers (for computer professionals)... Common Lisp sly> can do the work efficiently, but is too complex for part-time sly> programmers.
what is complex about Common Lisp and how exactly does newLISP fix this? i find CL being quite simple in it's core. there are lots of functions in standard library, some of them being weird, but you do not need to learn them all.
on the other hand, newLISP is quite complicated due to ORO restrictions, as one needs workarounds like symbols and contexts to implement even basic stuff. and this stuff is actually pretty complex and not good for "part-time" programmers you worry about.
here's an example from newLISP documentation
----- To avoid passing data objects by value copy, they can be enclosed in context objects and passed by reference. The following code snippet shows reference passing using a namespace default functor:
(define (modify data value) (push value data))
(set 'reflist:reflist '(b c d e f g))
(modify reflist 'a)
reflist:reflist => (a b c d e f g) ----- wtf is "namespace default functor" and why one has to use them to implement a relatively simple function?
it looks like newLISP features were structured around its interpreter implementation -- whatever was easier to implement was included. this might be simplier for ones who write interpreters, but it is not good for ones who are trying to learn it.
you should be ashamed for supporting this shit, i suggest you doing a sepukku to defend your reputation.
> sly> obsolete Unix computers (for computer professionals)... Common Lisp > sly> can do the work efficiently, but is too complex for part-time > sly> programmers.
> what is complex about Common Lisp and how exactly does newLISP fix this? > i find CL being quite simple in it's core. there are lots of functions in > standard > library, some of them being weird, but you do not need to learn them all.
> on the other hand, newLISP is quite complicated due to ORO restrictions, > as one needs workarounds like symbols and contexts to implement even > basic stuff. and this stuff is actually pretty complex and not good for > "part-time" > programmers you worry about.
> here's an example from newLISP documentation
> ----- > To avoid passing data objects by value copy, they can be enclosed in context > objects and passed by reference. The following code snippet shows reference > passing using a namespace default functor:
> (define (modify data value) > (push value data))
> (set 'reflist:reflist '(b c d e f g))
> (modify reflist 'a)
> reflist:reflist => (a b c d e f g) > ----- > wtf is "namespace default functor" and why one has to use them to implement > a relatively simple function?
> it looks like newLISP features were structured around its interpreter > implementation -- whatever > was easier to implement was included. this might be simplier for ones who > write interpreters, > but it is not good for ones who are trying to learn it.
> you should be ashamed for supporting this shit, i suggest you doing a > sepukku > to defend your reputation.
> what is complex about Common Lisp and how exactly does newLISP fix this? > i find CL being quite simple in it's core. there are lots of functions in > standard > library, some of them being weird, but you do not need to learn them all.
It is code=data, eval and macros. CL/Scheme macros are complex. Some CL users repeat all the time "if you use eval, that means that you're n00b that didn't l3arn3d h0w to use macros!"
Newlisp users use eval if it solves their problem. Their eval understands local variables, so it is far more frequently used.
And what if one WANTS macros? Newlisp macros are easier to understand, more powerful (CL-ers claim no use of additional power) and easier to write in practice.
> it looks like newLISP features were structured around
> its interpreter > implementation -- whatever
> was easier to implement was included. this might be
> simplier for ones who write interpreters,
> but it is not good for ones who are trying to learn it.
Method might be true, but not the result. This is why:
CL tries to serve two masters, to give programmers almost as much power as interpreted Lisps, at almost as much speed as Pascal (if he does not use eval.) It is complicated - complicated to design, implement, use.
Newlisp is designed to be simple. Like Perl, Python, Ruby, Basic, it doesn't try to compete with C. It allowed significant simplifications, and some of these also increase expressive power. But Newlisp is primarily advertised as simple to learn and use and good enough for many 'scripting' purposes."
> you should be ashamed for supporting this shit, i suggest you doing a > sepukku > to defend your reputation.
Yeah right ...
In many areas CL and Scheme standards and implementations are equal or better than Newlisp. In many areas, they are just different. But, if one puts *easy to learn and use* and powerful *code=data* on top of his priorities, Newlisp is excelent choice.
On Jan 22, 4:01 am, Majorinc Kazimir <fa...@email.address> wrote:
> Alex Mizrahi wrote:
> > what is complex about Common Lisp and how exactly does newLISP fix this? > > i find CL being quite simple in it's core. there are lots of functions in > > standard > > library, some of them being weird, but you do not need to learn them all.
> It is code=data, eval and macros. CL/Scheme macros are > complex. Some CL users repeat all the time "if you use > eval, that means that you're n00b that didn't l3arn3d > h0w to use macros!"
One says that EVAL is often just not needed and that it makes the code slower than it needs to be. In many cases it is better to generate code at compile-time and have it compiled than generate code at runtime. Using EVAL where not needed is like driving and not shifting into a higher gear.
> Newlisp users use eval if it solves their problem.
Which problem? Any practical problem? What kind of problems are solved by Newlisp users this way?
> Their > eval understands local variables, so it is far more > frequently used.
Stuff like that has been removed earlier in the history of Lisp, because it makes the understanding of code harder - for the human and the compiler.
Reason:
In a lexical Lisp I can see what code uses (reads/writes/binds) the variables. In a Lisp that provides unrestricted EVAL with access to local variables, many pieces of code can set the local variables and it is not obvious when and where it happens. It provides more flexibility at the cost of rendering any non-trivial amount of code to be much harder to understand.
> And what if one WANTS macros? Newlisp macros are easier to > understand, more powerful (CL-ers claim no use > of additional power) and easier to write in practice.
Because they are easier to use? Do you have a more specific reason?
For example I can take a piece of code in Common Lisp and have it macro expanded and look at it. I can trace/debug the macro expansion in isolation. Sounds easier than a FEXPR which at runtime does code generation, where code generation is mixed with execution.
> > it looks like newLISP features were structured around
> > its interpreter > implementation -- whatever> was easier to implement was included. this might be
> > simplier for ones who write interpreters,
> > but it is not good for ones who are trying to learn it.
> Method might be true, but not the result. This is why:
> CL tries to serve two masters, to give programmers almost > as much power as interpreted Lisps, at almost as much > speed as Pascal (if he does not use eval.) It is complicated > - complicated to design, implement, use.
Common Lisp provides support for interpretation and compilation. What it did was removing the semantic differences between those. For example before Common Lisp it was often the case that the Lisp implementation was using dynamic binding in the interpreter and lexical binding for compiled code. Common Lisp demands that the interpreter also uses lexical binding. It makes Lisp follow a simpler execution model (more in line with lambda calculus).
> Newlisp is designed to be simple.
I was using some Lisps like early Scheme implementations that look quite a bit simpler to me.
> Like Perl, Python, Ruby, > Basic, it doesn't try to compete with C. It allowed > significant simplifications, and some of these also increase > expressive power. But Newlisp is primarily advertised as > simple to learn and use and good enough for many > 'scripting' purposes."
I think a simple Lisp in the Scheme tradition is just as easy to use for scripting and better understandable. Actually a former co-worker used scsh (the scheme shell) for a while and then moved on to use GNU CLISP for scripting purposes and liked CLISP a lot.
> > you should be ashamed for supporting this shit, i suggest you doing a > > sepukku > > to defend your reputation.
> Yeah right ...
> In many areas CL and Scheme standards and implementations > are equal or better than Newlisp. In many areas, they are > just different. But, if one puts *easy to learn and use* > and powerful *code=data* on top of his priorities, Newlisp > is excelent choice.
I would think that real newbies are much better starting with Scheme (R5RS), since it has clearer semantics and is more powerful at the same time.
On 2009-01-22, Majorinc Kazimir <fa...@email.address> wrote:
> Alex Mizrahi wrote:
>> what is complex about Common Lisp and how exactly does newLISP fix this? >> i find CL being quite simple in it's core. there are lots of functions in >> standard >> library, some of them being weird, but you do not need to learn them all.
> It is code=data, eval and macros. CL/Scheme macros are > complex. Some CL users repeat all the time "if you use > eval, that means that you're n00b that didn't l3arn3d > h0w to use macros!"
You've evidently chosen to suffer a language just because in it, eval behaves in a particular way. No matter what anyone says, you just keep harping about ``code=data'' and ``eval that understands locals''.
You don't seem to realize, that you can write an interpreter in Common Lisp for a dialect which has the eval that you want. Writing a Lisp interpreter in Lisp is a student exercise. You have things like reading, printing, representation of symbols and memory management taken care of already.
Bad technology like some crummy evaluator can easily be hacked with the good technology in a few evenings. In a week, you could cob together something that blows newLISP out of the water.
And, lastly, note that Lisp has dynamic variables. If you want eval to understand local variables, use those!
We could say that just like Common Lisp, newLISP has an eval which doesn't give you access to lexical variables. But Common Lisp /has/ lexical variables.
newLISP's access to local variables is easy to implement because they are dynamic.
If newLISP had real lexical variables, the author of newLISP would probably work out some excuse why his eval cannot access them. Put a newbie perspective on it, like it's for ease of use or something. Or he'd point to real Lisps and claim that they don't do it either.
