newLISP now on Graham's list

[mrd]

People who do bignum application perhaps shouldn't use a scripting language like newLISP. Those bignum applications would probably involve heavy number-crunching which is more suited to do in a compiled language.

The best CL for bignums is actually CLISP, surprisingly.  It is a byte-code interpreter, but it uses extremely fast algorithms.  CMUCL does better with FP, though.  But CLISP has arbitrary-precision floats, which is unusual (you have to toggle something to get them though).

Perhaps a nice compromise would be to have bignum library written in 'C' and import it into newLISP which is more or less what David is suggesting. This library then could have other math stuff too, used by people dealing with bignums.

Then it won't automatically switch between fixnums and bignums.  This is extremely convenient.  Most other languages are moving towards this feature, not away.

[Lutz]

I will put bignums on my todo list, but not for the near future. The code-size impact would probably not be big, but I have to explore if it is possible to do it without impacting current functionality speed performance wise. I agree that a fully transparent implementation would be the best, so integer arithmetik would always be bignum if it has too.



Lutz

[HPW]

Still more laughing:

Von:Raffael Cavallaro (raffaelcavallaro@junk.mail.me.not.mac.com)

Betrifft:Re: Strange LISP: [ http://www.newlisp.org">http://www.newlisp.org ]

 

View this article only

Newsgroups:comp.lang.lisp

Datum:2004-09-25 20:51:29 PST



In article <41532A5B.BA6A7707@freenet.de>, lin8080 <lin8080@freenet.de>

wrote:



> Didn't I type ... lots of fun?

>

> stefan



Well, to explain a joke is always to kill it (not that this one had much

life left in it anyway...)



You wrote, "Well, I love it," and "NewLisp is funny and givs me back a

special kind of lispy element." The two, in combination suggest that you

find it funny in the sense of liking and enjoying it.



I wrote "I find it amusing 'cause it's good for WTF! style yucks," which

suggests that I find it funny in the sense of laughing at it because it

is so grotesquely bad. Given the legions of high quality common lisp and

scheme implementations out there, not to mention Dylan and goo, newlisp

is a giant step backwards for the lisp family of languages. If I could,

I would euthanize newlisp for the good of programmers the world over.



Summary: You're laughing *with* newlisp. Most of us are lauging *at* it.

Von:Matthew Danish (mrd+nospam@cmu.edu)

Betrifft:Re: Strange LISP: [ http://www.newlisp.org">http://www.newlisp.org ]

 

View this article only

Newsgroups:comp.lang.lisp

Datum:2004-09-27 14:30:06 PST



Mike <mikee@mikee.ath.cx> writes:

> I'm new to LISP. Please explain why newLISP is a farse? For what I'm

> considering it seems to do everything that I want.



A Turing machine can do everything you want, too.  That doesn't mean

you want to program that way.



``newLISP'' makes design decisions which Lisp programmers out-grew

long ago.  I'm not talking about availability of libraries here, I'm

talking about fundamental concepts in the language.  ``newLISP'' does

not have proper lexically scoped variables, it does not have

polymorphic arithmetic functions with a numeric tower, it has an

extremely primitive, and in some cases downright poor, treatment of

objects.  In short, ``newLISP'' is an anachronism; it belongs to the

1960s, before most people started to get a clue about language design.



Of course, one can point out flaws in any language; but what is

particularly ironic about ``newLISP'' is that despite its name, it

does not indicate that there was any knowledge of current Lisps in the

minds of the authors.  How could they create a truly ``new'' Lisp if

they don't know anything about existing Lisps?



--

;; Matthew Danish -- user: mrd domain: cmu.edu

;; OpenPGP public key: C24B6010 on keyring.debian.org

Keep care that they do not euthanize us!

;-)

[jsmall]

If newLisp is such a dog and dead (in the grave long ago)

why kick it?



Several things the detractors miss about newLisp.



1. It's small foot print and convenience.  Perhaps they

didn't miss this at all.  Perhaps it is admitting "common folk"

to the exclusive Lisp country club that gets their goat

as if we are going to polute the language space.  The

open market of ideas will insure the drift wood is carried

out to sea and forgotten.



2. It goes against the Ionian and Pathagorean rationalists

concept of the pure and beautiful, anything practical or

empirical is pedestrian and to be rejected out of hand

including heaven forbid those nasty irrational numbers

like the square root of 2.



3. Lutz is taking an entirely new approach to programming

in Lisp - something I call VO (Value Oriented) in which

he transforms "shapes" into new shapes.  A program

becomes literally a sequence of shape transform layers.

This is done with primitives like "ref" and "index" and I

think the detractors totally miss this.  This mindset is

what produced the smaller libraries etc.  This is what is

"new" in newLisp.  This is what gets their goat the most,

i.e. calling it new which in turn is calling them old. I

remember my first encounter with Lisp 20 years ago.

I discounted the language as antiquated with all those

parentheses and lack of strong typing.  After all I was

a sophistocated strong type checking Pascaler.  That

quick jump to judgment made me waste the best

years of my programming life. It wasn't until about

5 years ago I started my journey through the functional

languages and realized that Lisp had something to offer.

Maybe if these folk look past their distain for dynamic

scoping they can see what is new in newLisp and not

have to wait until the revolution has passed them by.

And as far as the comments go about documentation

well I'd rather Lutz keeps pushing the envelop then

become too distracted with documentation perfection.

Those bring up the rear can worry about that.



Damn the torpedos - full speed ahead!

[Lutz]

Thanks John and Hans-Peter for defending newLISP. Most on this forum know what newLISP is about and are not worried about the kind of posts you sometimes see on comp.lang.lisp.



Users on this forum use newLISP to make programs, solving real world problems. We are not interested in having a language where every concept known in Computer Science is implemented.



That does not mean that these problems are not interesting, but they are not the primary focus of newLISP. From this point of view the simplicity of newLISP is a virtue not a disadvantage.



Many users on this forums have used standard Common Lisp or Scheme but have decided to use newLISP because they want to concentrate on the programming problem at hand and not on the theory of certain language features.



newLISP's simplified and streamlined LISP model make it easier to learn and understand and make it easier to understand code written in it.



I recommend going to http://shootout.alioth.debian.org/">http://shootout.alioth.debian.org/ and compare different LISPs and other languages, how they solve certain computing problems and how they use computing resources like CPU cycles or memory. A copy of all the speed benchmarks for Perl, Python, Guile and newLISP is on the newlisp.org site at: http://newlisp.org/benchmarks/">http://newlisp.org/benchmarks/ .



Lutz

[BrickCaster]

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.

[Lutz]

* can you live without closures ?



A context in newLISP is a lexical closure



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



Absolutely, and so do many others in 'Python' or in research languages like 'Self'. In fact it seems that newer languages seem to prefer the prototype based approach and see it as the better soution of OO programming.



* can you live without continuations ?



newLISP has everything to program a type of continuation, if you want to, i.e. 'catch' and 'throw'



But those three questions are all not relevant, they are the wrong questions. The real question is:



Can newLISP be used to write your program or application or script? Most users on this board proove they can, and they produce shorter and faster solutions than with other tools.



Just let your mind come out of the box, fire up newLISP and do some creative work, solve real problems.



Lutz

[Jeremy Dunn]

I find the complaint about the factorial function a little ridiculous. For most normal situations it is probably more efficient to have the function look up a precalculated value from a table rather than brute force it every time. How high do we need to go, factorial 200? Use Sterling's formula for an approximate value or code your problem in Mathematica if you are trying to some weird number theory thing. Yes it would be fun to have bignums integrated but give Lutz some time, Perl didn't start out perfect either.

[nigelbrown]

Automatically throwing a system into bignum mode seems to be giving a false sense of security to those who haven't thought about the numerical side of their programming. It can be of value in number theory etc to have bignum but a more thorough approach to planning your calculations is probably a better step most times.

Nigel

[Qrczak]

Automatically throwing a system into bignum mode seems to be giving a false sense of security to those who haven't thought about the numerical side of their programming.

Oh, really? I have a file of size of 10GB. newLisp's file-info function returns nil for it. Could this be fixed? For example Python has no problem with delivering the correct result.



So you are saying that letting it "just work" in the language would be bad, and it's the fault of the script writer who hasn't thought that files may be that big. Ok, let's assume that he is aware of that. What can he do?

[Lutz]

10 Gbyte file, that is pretty uncommon. That file is probably a database and gets accessed with a database manager or other tools.



A 10 Gbyte file is an excotic requirement not worth discussing until it gets mainstream and then we will have 64Bit computers on the desktop and a 64bit newLISP, but the time simply hasn't come.



The requirement of newLISP to handle bigger than 32bit integer size files has *never* come up or asked for by *anybody*. You are the first one talking about this. Even the C libraries on current 32 bit computers treat these with special functions like fopen64() etc.. Why would I burden a language with this kind of stuff so one in 10,000 programmers will use it?



Lutz

[Lutz]

If you need bignum handling so much, why don't you create a 'C' library for newLISP with bignum.lsp interface file to import it and use it. The same could be done for open64, seek64 etc..?



This kind of approach is always good for features not needed as much, but it can be delivered in an additional module. There are exampled in the manual and on the newlisp.org site whoe to import and write 'C' libraries for newLISP.



There is also the GMP http://www.swox.com/gmp/">http://www.swox.com/gmp/ GNU Bignum library, which seems to be very extensive and you could write an interface gmp.lsp for it.



Lutz

[HPW]

>There is also the GMP http://www.swox.com/gmp/">http://www.swox.com/gmp/ GNU Bignum library, which seems to be very extensive and you could write an interface gmp.lsp for it.



I have not test it, but ffidl comes with demos for GMP.



http://elf.org/ffidl/#demos">http://elf.org/ffidl/#demos

[Qrczak]

If you need bignum handling so much, why don't you create a 'C' library for newLISP with bignum.lsp interface file to import it and use it.

It will not be returned by file-info, nor accepted by print, <, + etc. They are not extensible for user types; they have hardwired knowledge about builtin types and that's all.



Actually I don't see how it can work at all, because copyCell() can't be extended either. Do you mean that the programmer would have to free bignums explicitly?! If yes, then "automatic memory management" from the home page is misleading.



Anyway, I will not write it because I don't use newLisp, because of too many silly design decisions (like lack of garbage collection, implicit copying of large objects by value, dynamic scoping - context are no substitute for lexical scoping because they have to be managed explicitly, lack of user-defined types, and silly semantics of various functions).

There is also the GMP http://www.swox.com/gmp/">http://www.swox.com/gmp/

Yeah, it's good. I used it in the implementation of my language Kogut.

[newdep]

As I say......"A programming language is a mirror of the creator"...



The source code is included...bring me the ultimate or bring me Kogut!