newlispfanclub.alh.net

Posted: **Fri Oct 01, 2004 10:54 am**

The name "newLISP" would suggest that it builds on old Lisp experience, but in fact it ignores Lisp history and uses rules which have been tried and rejected as bad ideas, like dynamic scoping by default.

"Excepting symbols and built-in primitives, each object is referenced only once in the system and is always passed by value." - This implies that a recursive function which conses an element on each iteration to a growing list, or even descends a list by iterating 'rest', has O(N^2) complexity, or worse if elements themselves are big.

This also makes impractical to create graphs of mutable objects: you can't refer to a part of it for further modification because it will be implicitly copied. IMHO this very fact makes it not a Lisp at all. Every Lisp, and in fact most modern languages, pass objects by reference and collect unreachable garbage. In every Lisp you can look at the rest/cdr/tail of a list without copying it.

"Many of newLISP's built-in functions are polymorphic in type, accepting a variety - and sometimes all - data types and thereby greatly reducing the total number of different functions and syntactic forms necessary to be learned and implemented." - Except arithmetic, where it would make the most sense. Not just the defaults are limited, but there are no arithmetic operators which do the right thing (return an exact answer when possible).

No wonder why correctly behaving arithmetic is not provided: having only fixed-range integers, without even checking for overflow, and floats, is pathetic. This set of types just can't exactly represent 1/10 nor the size of my hard drive in bytes. Is it Lisp or C?

cons which does a completely different thing depending on whether the second argument is a list is stupid. If there are improper lists, then fine - make it an error if it's not a list. But making a two-element list *except* when the second argument was a list makes absolutely no sense, because if you rely on cons making a two-element list, you will badly surprised if the second argument happens to be a list. There is no context where you really want either this or that, in all cases you statically know which behavior you want, so it makes no sense to put them both in one function. I bet that the two-element behavior of cons is not used in practice, because it's not robust.

A hash table is associated with a global variable. What?! I can't make a list of hash tables without inventing unique names for them? This applies to objects as well. Is it Lisp or Tcl?

The implementation of hash tables is interesting:
> (load "modules/hash.lsp")
true
> (HASH:make 'h)
h
> (h:put "(" 'open)
open
> (h:get ")")
open
...Huh?!

"Unless otherwise specified for a function, an index greater than N-1 returns the last element, and an index less than -N returns the first when in lists, but out of bounds indices in arrays will cause an error message." - long live the consistency. I see no purpose in returning the last element of a list when the index is too large - it will just mask programming errors.

"constant: Works exactly like set but protects the symbol from subsequent modification. A symbol set with constant can only be modified again using constant." - Funny, a constant which is not constant.

"If num is supplied, dec always returns the result as floating point even for integer input arguments." - Why?

"If the expression in exp evaluates to a string, it will be replicated int-n times in a string and returned. For any other type in exp a list of int-n of the evaluation of exp is returned." - How to make a list with N references to the given string (sorry, N copies of the string)? Again an inconsistent behavior which doesn't make sense - if you want to make a list using dup, ensure that the element is *not* a string, because you will get a different thing in this case.

A similar problem is inherent in flat. The documentation says: "To convert a list back to an array apply flat to the list". It will break if the array is supposed to contain lists as some elements. These operations which do a particular thing for almost all values, *except* when values are of a particular type, are just misdesigned.

"get-char: Gets a character from an address specified in int-address." - An address represented in 32 bits? So it will not work on 64-bit machines. What a pity. C used to almost unify pointers with integers about 30 years ago.

File handles represented as ints and I/O operations using system calls directly, with no buffering? I knew that this is C 30 years ago.

In general, I'm disgusted. There is some work in wrapping C library functions, but the core language design, number and list processing is awful. The name newLisp is misleading: it's not a Lisp and it's not modern. It tries hard to have neither garbage collection nor pointers, which implies that pointers must be simulated using unique constants which denote globally accessible structures, as if it was Tcl or ancient Fortran. It throws away the progress made in programming language design in the last 30 years.

Posted: **Fri Oct 01, 2004 12:09 pm**

Hi Qrczak,

It seems that you are arguing with your own pre-occupations.

"Lisp, and in fact most modern languages, pass objects by reference and collect unreachable garbage."

In fact, only C-pointers pass objects by reference and only Java/C++ know a kind of garbage collecting. Almost all interpreted languages pass 'objects' by value.

"get-char: Gets a character from an address specified in int-address." - An address represented in 32 bits? So it will not work on 64-bit machines. What a pity."

Why don't you read better. If you compile newLisp on a 64-bit architecture, guess what happens?

"File handles represented as ints and I/O operations using system calls directly, with no buffering? I knew that this is C 30 years ago."

In fact, there is buffering; read the manual better. I can go on and sum up your unreasonable statements, refuting them one by one - but it's too tiring.

"In general, I'm disgusted. There is some work in wrapping C library functions, but the core language design, number and list processing is awful."

NewLisp is the best interpreted language currently available. It's fast, elegant, multiplatform, stable, and has eveything you need to program a quick solution.

If you do not want to use newLisp, just stay away.

Peter

Posted: **Fri Oct 01, 2004 12:15 pm**

If the water is too salty, dont drink it !

Posted: **Fri Oct 01, 2004 1:14 pm**

Hi Qrczak,

I do not know why the lisp-communtiy has such a problem with newLISP?
Is it only the name?
But it is not named 'newAnsiCommonLisp'!
It is not targeted to compete with this standard in any way.
Is 'ARC' a good name for something new in lisp?
Will it be usable?Will it be big? Will it be for mainstream use? Will it be free?

You say newLISP is a lisp from 30 years ago.
Maybe it has more similaritys with this lisps (as the whole family),
but is that bad at all? Even that lisps had nice features.

On the other side compare newLISP to some other lisps from Graham's site.
Xlisp for example is a dead language. Autolisp helped to make Autocad
what it is today and has thousands of aktiv developers worldwide.
From the language autolisp isn't sophisticated at all and has much less
language-features than newLISP. Maybe there are more autolisp users than common-lisp users.

Size: newLISP is incredible small. This is the field where no common-lisp could compare.
A interpreter with less than 100 KB filesize is really hard to beat.
With load-time it is the same. You can embed it in any popular
development-enviroment on each platform.
Easy embedding in MS Office included.

My motto: Use the right tool to get the job done!
(There are jobs for AnsiCommonLisp, but also a lot for newLISP)

Just my 2 cents. (Euro)

Posted: **Fri Oct 01, 2004 1:59 pm**

pjot wrote:In fact, only C-pointers pass objects by reference and only Java/C++ know a kind of garbage collecting. Almost all interpreted languages pass 'objects' by value.

Which scripting languages? Python, Ruby, Icon pass objects by reference. Perl passes them by reference when calling functions and makes a copy when storing in a data structure (but it has explicit references). Only Tcl passes them by value (AFAIK) and Unix shell which doesn't have any other type than string (and sometimes array).

Besides scripting languages, all funtional languages (e.g. SML, OCaml, Haskell, Clean, Erlang), all Lisp and Scheme dialects including Dylan, also Prolog, Smalltalk, Self, Java - pass objects by reference. For atomic immutable values it doesn't matter how it's passed, the behavior is the same regarding mutation in the presence of aliasing, so Java counts too. They don't make deep copies of structured data, they allow to refer to a part of a graph of objects and mutate it such that the mutation is visible in the original. They all allow to actually create a graph of objects which newLisp doesn't (except by emulating pointers by global variables with unique names, like in Tcl).

If newLisp wants to promote functional programming which doesn't use mutation in place, then fine, but cons and rest would have to be O(1).

Some languages pass some objects by reference, and others (only small objects with bounded size) by value. This includes C, Pascal, Eiffel and C#.

C++ and Tcl are the only languages I know which make implicit copies of whole nested structures. And even in C++ you can use pointers to avoid this.

Regarding GC, almost all languages, especially those designed recently, free objects automatically. Only C, Pascal, C++ and some ancient languages don't have native GC (sometimes it's painfully implemented as a library for C and C++). And some limited languages with no data structures at all, like Unix shells.

Languages with no GC and no pointers are not fun.

pjot wrote:"get-char: Gets a character from an address specified in int-address." - An address represented in 32 bits? So it will not work on 64-bit machines. What a pity."

Why don't you read better. If you compile newLisp on a 64-bit architecture, guess what happens?

The pointer is cast to UINT, which is a typedef for unsigned int, which is half of the size of a pointer.

HPW wrote:I do not know why the lisp-commintiy has such a problem with newLISP?

It's just very badly designed, and the name suggests that the author should have known better.

(I'm not a member of Lisp community.)

Posted: **Fri Oct 01, 2004 2:15 pm**

Icon passes by value. Furthermore, KSH, BASH, Logo, Perl, almost all BASIC dialects, PHP, Prolog (yes Prolog - I used to program GNU Prolog myself), Rebol, ZSH and so on - even CLisp. Some languages need a special command to pass by reference - the default is pass by value.

UINT is defined differently on different platforms, depending on your C-compiler.

Posted: **Fri Oct 01, 2004 3:17 pm**

"First they ignore you, then they ridicule you, then they fight you, then you win."

Posted: **Fri Oct 01, 2004 3:23 pm**

pjot wrote:Icon passes by value.

Not true:

procedure change(l)
l[1] := 10
end

procedure main(args)
local l
l := [1,2,3]
change(l)
write(l[1])
end

Result: 10

pjot wrote:Furthermore, KSH, BASH, (...) ZSH

I said that Unix shells are exceptions. They support no data structures except strings (and sometimes arrays). They aren't suitable for large programs because of this.

pjot wrote:Logo,

I programmed in Logo 15 years ago. I don't remember whether it supported mutable data at all, but BUTFIRST definitely has time complexity of O(1) - it's a descendant of Lisp after all.

pjot wrote:Perl,

Not true:

sub change($) {++$_[0]}
my $x = 5;
change($x);
print "$x\n";

Result: 6

...and similarly when references are used; they are always used with nested data structures.

pjot wrote:almost all BASIC dialects,

I haven't used a BASIC which had procedures, where this question would me meaningful, but I'm sure that Visual Basic has object references and doesn't make implicit copies of arrays.

pjot wrote:PHP,

Not true. I don't have PHP installed here, but I'm sure that you can translate the above Icon sample and obtain the same result.

pjot wrote:Prolog

Not true. When a predicate unifies a type variable with some value, the effect is visible outside the predicate. Unification is the only side effect.

pjot wrote:Rebol,

Not true:

>> test: func [x] [x/foo: 4]
>> obj: make object! [foo: 2]
>> obj/foo
== 2
>> test obj
== 4
>> obj/foo
== 4

pjot wrote:even CLisp.

Of course not, because it's a Common Lisp implementation:

[1]> (defun test (x) (rplaca x 44))
TEST
[2]> (defvar obj (list 2))
OBJ
[3]> (test obj)
(44)
[4]> obj
(44)

pjot wrote:UINT is defined differently on different platforms, depending on your C-compiler.

I can see "#define UINT unsigned int" in newlisp.h, not surrounded by any #ifdefs.

Posted: **Fri Oct 01, 2004 5:59 pm**

(1) 'new' in newLISP
It means, doing things in a 'new', different way. newLISP doesn't 'ignore history', it just tries to do things a different way. In some aspects it is different: scoping rules and variable passing conventions, etc., in other aspects it is not: s-expressions, anonymous functions, lists etc.

(2) Being 'different’
Because newLISP is new and different, you program LISP in it in a new and different way. Don't criticize newLISP because it is not Common Lisp or Scheme.

Don't try to program Common Lisp or Scheme in newLISP. newLISP by design is not Common Lisp or Scheme. I do not imply that Common Lisp and Scheme are bad because they are different from newLISP, they are just different.

(3) Dynamic scoping
Is not a 'bad idea' per se, it is just a different way of doing variable scoping. Millions of Perl programmers feel just fine using dynamic scoping, so do newLISP users. If you are aware how dynamic scoping works and behaves, you program 'with' it not 'against' it. Those who did serious work with newLISP have never complained about it. Where dynamic scoping could get dangerous, contexts in newLISP can separate namespaces to develop bigger programs consisting of independently developed modules.

(4) Integer and Float Arithmetik
You can redefine the integer operators (see manual) and then you get just the same number treatment you have in other scripting languages.

newLISP includes raw integer arithmetic, because it has been used controlling, diagnosing hardware, in this case you want your arithmetic to behave like a hardware register would, rolling over to negative numbers when adding/incrementing, etc.. newLISP adds low level like Integer arithmetic as a feature, if you don't like it turn it of and use +,-,*,/ like in other scripting languages. Then al functions and operators are polymorph if it comes to integers and floats.

I know that Common LISP and Scheme handle arbitrary precision numbers. newLISP is geared toward programming of practical applications. newLISP has not been designed as a tool for Mathematicians, although some think, that is well usable for that, if you know how to use it and import certain libraries (i.e. bignum). Most on this board have never used bignums in their life.

(5) Value passing
It is true that most programming languages pass arrays and lists by reference and not by value like in newLISP. newLISP has the philosophy that only symbols should be used for referencing. Strictly value passing makes newLISP fast and small and it uses less memory overall than any other scripting language (except Ocaml). Goto the 'Scorecard' tab on http://shootout.alioth.debian.org/ and change the 'Memory Score Multiplier' to '1' and recalculate, you will see newLISP coming out on top of all other scripting languages (except Ocaml).

Perhaps he hardest part in developing a programming language is memory management. Speed and memory benchmarks show you that newLISP's memory management works faster and saves resources compared to most other interactive programming languages.

(6) 'Consistency'
Consistency can be a good thing, but not always. I.e. arrays do bounds checking, lists do not. This was a conscious decision. Mostly when using arrays you deal with fixed size arrays and want the benefit of bounds checking. You work with lists because it is easy to change they size and shape. Many list accessing / modifying functions in newLISP can take multiple indices and work on complex nested lists. Many times the consistency goal sacrifices usability. It is typical in Western thinking to over emphasize consistency or orthogonality. Some Japanese assembler languages use a completely different mnemonic for every variant of an address mode; Western assemblers will typically use only one mnemonic with different modifiers for address modes.

Lutz

Posted: **Fri Oct 01, 2004 6:49 pm**

Wel, I am tired of this "yes/no" game, this will be my last posting regarding this issue.

Concerning Perl. Reading the PERL man-page (man perlsub):

"The Perl model for function call and return values is simple: all functions are passed as parameters one single flat list of scalars, and all functions likewise return to their caller one single flat list of scalars. Any arrays or hashes in these call and return lists will collapse, losing their identities--but you may always use pass-by-reference instead to avoid this."

So by default, Perl passes by value.

=========

Concerning Icon, the Unicon manual page 19:

"Procedure parameters are passed by value except for structured data types, which are passed by reference. This means that when you pass in a string, or cset value, the procedure gets a copy of that value; any changes the procedure makes to its copy will not be reflected in the calling procedure."

Passing by value.

============

Read the manuals to convince yourself. I don't want to quote all the manuals for all the langauges. I did not say it is IMPOSSIBLE to pass by reference, I said that passing by value is the default for most interpreted languages, including Icon and Perl.

Posted: **Fri Oct 01, 2004 7:32 pm**

I'm not complaining that the behavior is just different than in Scheme or Common Lisp. I'm complaining that it repeats past mistakes of old Lisps and old Perls which were later fixed, and that it's simply not useful in several cases.

Lutz wrote:(3) Dynamic scoping
Is not a 'bad idea' per se, it is just a different way of doing variable scoping. Millions of Perl programmers feel just fine using dynamic scoping, so do newLISP users.

Dynamic scoping went out of fashion in Perl too, except in rare cases. It's not bad to be available; it is a bad default. Here is what 'man perlsub' says:

WARNING: In general, you should be using "my" instead of
"local", because it's faster and safer. Exceptions to
this include the global punctuation variables, global
filehandles and formats, and direct manipulation of the
Perl symbol table itself. "local" is mostly used when the
current value of a variable must be visible to called sub
routines.

"local" is dynamic scoping, "my" is lexical scoping; "my" is available for 10 years.

Later, in the same manual:

Passing Symbol Table Entries (typeglobs)

WARNING: The mechanism described in this section was orig
inally the only way to simulate pass-by-reference in older
versions of Perl. While it still works fine in modern
versions, the new reference mechanism is generally easier
to work with. See below.

Sometimes you don't want to pass the value of an array to
a subroutine but rather the name of it, so that the sub
routine can modify the global copy of it rather than work
ing with a local copy. In perl you can refer to all
objects of a particular name by prefixing the name with a
star: *foo. This is often known as a "typeglob", because
the star on the front can be thought of as a wildcard
match for all the funny prefix characters on variables and
subroutines and such.

See how it resembles newLisp's implementation of hash tables and OO-style objects? But in Perl it has been obsolete for 10 years.

Posted: **Mon Dec 12, 2005 11:24 am**

That "Qrczak" guy simply does not know where he can dump his frustrations...Hahaha...

He keeps posting about newlisp, what better adverticement can you get ;-)..Hahahaha...

http://www.codecomments.com/archive274- ... 58487.html

Posted: **Mon Dec 12, 2005 5:07 pm**

I wonder whether there would be as much confusion and argument if newLISP had originally been called something else? Perhaps the mixing of 'new' and 'Lisp' is being interpreted as a hubristic claim that newLISP is better than old LISP...

Perhaps if it had been called "miniLISP" or "LLAMA" ("Lisp-Like Automation Macro Acessory"?) or "Thcript" or "Parens" or "SPIL" ("Small Programming in LISP") or "UncommonLisp" or "Listp" or "Lispette" or anything, really, even "Dragonfly" (that nice parenthetical logo...), there would be fewer arguments about its nature and purpose.

Posted: **Tue Dec 13, 2005 2:32 am**

I know, some people are offended by the name of this language and it was not my intend to offend anyone or to take anything away from the important efforts of the people involved in Common Lisp and SCHEME.

On the right side of the newLISP logo on http://newlisp.org you find a link "the new LISP" to http://newlisp.org/index.cgi?page=Diffe ... ther_LISPs . This page explains some of the differences between traditional and newLISP:

Times change, the way programs are written changed and the way we judge programming languages is changing too. Perl, Python and JavaScript started this 'new' thinking and newLISP translates it into LISP.

Lutz

Posted: **Tue Feb 14, 2006 1:33 am**

Proof that people will find anything and everything to complain about.

Posted: **Tue Aug 08, 2006 8:00 pm**

newdep wrote:That "Qrczak" guy simply does not know where he can dump his frustrations...Hahaha...

He keeps posting about newlisp, what better adverticement can you get ;-)..Hahahaha...

http://www.codecomments.com/archive274- ... 58487.html

Got to admire his tenacity too: http://en.wikipedia.org/w/index.php?tit ... on=history.

I'm envious of his copious spare time.. I hardly have enough time to write about the things I like these days.

Posted: **Tue Aug 08, 2006 9:08 pm**

He has one point, though.

That context use a global variable name strikes me as suboptimal, too.
Especially as they are promoted as a way to pass large structures by reference, and to be used to implement objects.

Posted: **Tue Aug 08, 2006 10:09 pm**

... context use a global variable name ...

In the big picture of things this is the right thing to do: it sets limitations but also makes the language easier to understand. Contexts in newLISP are mainly understood as namespaces to organize your code, create isolated modules and do simple object wrapping. On purpose contexts in newLISP are not elements of a potentially multi-level object hierarchy like in a full blown object oriented language. This doesn't mean that you cannot use them as objects in a limited, useful fashion, but most of all newLISP is a functional language.

Inside these constraints contexts allow you to do with them all you need (use them as object- and module wrappers, assign them to variables, pass them as parameters, create and delete them during runtime). Adding anything more would only complicate the usage of the language.

There are always voices who want to build all paradigms known to CS into newLISP, but the language would be less usable and harder to understand.

Lutz

Posted: **Wed Aug 09, 2006 8:06 am**

Lutz wrote:
... context use a global variable name ...
There are always voices who want to build all paradigms known to CS into newLISP, ...

Believe me, I am not proposing this. I like it small and sweet. ;-)

Lutz wrote:In the big picture of things this is the right thing to do: it sets limitations but also makes the language easier to understand.

The thing is, to me, these limitations look artificial (1). And I believe, that artificial limitations make a language harder to understand.

As long as contexts are only meant as namespaces, you are right, your implementation is the right thing to do.

But by now some clever soul has figured out: they can be used for different things (objects, ...), and these are even officially documented.

I believe that from this point onward it actually makes it harder to understand newlisp, because I have certain ideas about how an 'object system' works, and newlisp breaks these assumptions. (In the context of "contexts" being officially blessed for being used as objects.)

Lutz wrote:Adding anything more would only complicate the usage of the language.

I don't want to add anything - to the contrary - I want a limitation removed. ;-) (2)

Ingo

(1) I'm aware that, from an implementation point of view, things may look quite different. For example, the current way of defining default actions would not work with anonymous contexts.

(2) I hope you are aware that I am discussing this in the hopes to either understand the rationale behind these limitations, or to initiate changes that will make a great language even better.

Posted: **Wed Aug 09, 2006 9:13 am**

discussing this in the hopes to either understand the rationale behind these limitations

It is a deliberate design decision to keep a newLISP object system flat and simple, mainly used for handling few big objects like programming modules, dictionaries (see 'sym' , 2nd and 3rd syntax of context), reference wrappers for big lists, strings etc., and this is how most newLISP users use contexts.

The main method of organizing data and functions in LISP should always be the list not a class/object hierarchy. newLISP goes a step further than traditional LISPs by offereing indexing into nested lists and offering implicit indexing on simple and nested lists.

The default functor in newLISP is a nice conceptual bridge between the context/namespaces system and the functional side of the language. newLISP is meant to be mainly a functional language.

I hope that after using newLISP for some time you can see these design decisions and philosphy not as a limitations but as something which makes newLISP a more powerful tool. Less is more ;)

Lutz

Posted: **Thu Aug 10, 2006 6:01 am**

Well... I am a novice newlisp hobbyist but I have lots of time on my hand, so I will tackle some of your points. I love Common LISP but I love newLISP better. Mainly because it is so much smaller and simpler, yet allows me to code fun stuff quicker and easier. But I still do love Common LISP as I do C. Programming languages and fonts are those kinds of things that are very personal, you know...

Qrczak wrote:The name "newLISP" would suggest that it builds on old Lisp experience, but in fact it ignores Lisp history and uses rules which have been tried and rejected as bad ideas, like dynamic scoping by default.

I personally like dynamic scoping by default. I like newlisp allowing me to use contexts when I want to isolate variables. Traditional lexically scoped programming languages can cause problems sometimes. Some C programmers resort to using ridiculous variable names to avoid variable name clashes despite lexical scoping. Here's a stupid example.

int xyz = 1;
int myfunc(int xyz) { ..... ; return xyz;}
int anotherfunc(int num) { ....; xyz = num; return num; }

Bad programming? C language allows something like this. BSD kernel code convention used to be to name globals like g_xyz with g_ prefix. But the language allows you to do many bad things.

Even Common LISP allows dynamic scoping. One could argue that newlisp can entirely be used using lexical scoping via contexts. So newlisp design is no worse than Common LISP in this regard.

Qrczak wrote: "Excepting symbols and built-in primitives, each object is referenced only once in the system and is always passed by value." - This implies that a recursive function which conses an element on each iteration to a growing list, or even descends a list by iterating 'rest', has O(N^2) complexity, or worse if elements themselves are big.

This also makes impractical to create graphs of mutable objects: you can't refer to a part of it for further modification because it will be implicitly copied. IMHO this very fact makes it not a Lisp at all. Every Lisp, and in fact most modern languages, pass objects by reference and collect unreachable garbage. In every Lisp you can look at the rest/cdr/tail of a list without copying it.

Again, I prefer to pass by value rather than reference most of the time. How many times in C have people run into unexpected changes in data pointed by a pointer and passed by pointer references? Large software systems constructed this way can be a nightmare to debug. The overhead of passing small values is just that -- small. I prefer knowing that I will pass something and what I pass won't change until I change it. I don't want some thing changing it for me, unless I want it do, which is not most of the time.

If I want to pass big data by reference I can do so using contexts in newlisp. Besides, if I am extremely concerned about performance, I'd use C and interface to newlisp, which is easily done.

Qrczak wrote: "Many of newLISP's built-in functions are polymorphic in type, accepting a variety - and sometimes all - data types and thereby greatly reducing the total number of different functions and syntactic forms necessary to be learned and implemented." - Except arithmetic, where it would make the most sense. Not just the defaults are limited, but there are no arithmetic operators which do the right thing (return an exact answer when possible).

No wonder why correctly behaving arithmetic is not provided: having only fixed-range integers, without even checking for overflow, and floats, is pathetic. This set of types just can't exactly represent 1/10 nor the size of my hard drive in bytes. Is it Lisp or C?

I wouldn't bother using bignum in newlisp even if it was offered. I'd rather do bignum or heavy number chrunching in C. Newlisp is not intended for that problem solving. There are ways of doing it in other languages already. Why make newlisp into a bloated pig by throwing in all kinds of things most people won't use? Why make it into a Common LISP?

Qrczak wrote:
cons which does a completely different thing depending on whether the second argument is a list is stupid. If there are improper lists, then fine - make it an error if it's not a list. But making a two-element list *except* when the second argument was a list makes absolutely no sense, because if you rely on cons making a two-element list, you will badly surprised if the second argument happens to be a list. There is no context where you really want either this or that, in all cases you statically know which behavior you want, so it makes no sense to put them both in one function. I bet that the two-element behavior of cons is not used in practice, because it's not robust.

in practice, this is really not a problem at all. An example would help to prove your case. It sounds a bit pedantic.

Qrczak wrote: A hash table is associated with a global variable. What?! I can't make a list of hash tables without inventing unique names for them? This applies to objects as well. Is it Lisp or Tcl?

How many times have to had to make use of locally scoped hash or object? That is a bad programming practice to begin with. I wouldn't do that, so I like the way newlisp does things.

Qrczak wrote:
The implementation of hash tables is interesting:
> (load "modules/hash.lsp")
true
> (HASH:make 'h)
h
> (h:put "(" 'open)
open
> (h:get ")")
open
...Huh?!

newLISP v.8.9.3 on Win32 MinGW, execute 'newlisp -h' for more info.

> (context 'HASH "(" 'open)
open
> (context 'HASH "(" )
open
> (context 'HASH ")" )
nil
> (context 'HASH ")" 'close)
close
> (context 'HASH ")" )
close
>

Qrczak wrote: "Unless otherwise specified for a function, an index greater than N-1 returns the last element, and an index less than -N returns the first when in lists, but out of bounds indices in arrays will cause an error message." - long live the consistency. I see no purpose in returning the last element of a list when the index is too large - it will just mask programming errors.

That is why one would use (last some-list) instead. In practice, programming errors don't really happen much because of returning last element when index is too large. In fact, it has helped me a bit when using newlisp interactively to parse XML data. If you can provide an example of when this feature can cause programming logic errors, you might get a better response. If you think about it, the feature does what you expect in real life.

Qrczak wrote:

"constant: Works exactly like set but protects the symbol from subsequent modification. A symbol set with constant can only be modified again using constant." - Funny, a constant which is not constant.

it is constant that can be changed explicitly. A novel feature I think.

Qrczak wrote:
"If num is supplied, dec always returns the result as floating point even for integer input arguments." - Why?

> (setq x 10)
10
> (dec 'x 2)
8
> (dec 'x 2.0)
6
> (dec 'x 0.1)
5.9
>

Qrczak wrote: "If the expression in exp evaluates to a string, it will be replicated int-n times in a string and returned. For any other type in exp a list of int-n of the evaluation of exp is returned." - How to make a list with N references to the given string (sorry, N copies of the string)? Again an inconsistent behavior which doesn't make sense - if you want to make a list using dup, ensure that the element is *not* a string, because you will get a different thing in this case.

dup is not used to make a list with N references of the string. it is used to duplicate string or other things.

> (dup "string" 10)
"stringstringstringstringstringstringstringstringstringstring"
> (dup "string" 10 true)
("string" "string" "string" "string" "string" "string" "string" "string"
"string" "string")
>

A similar problem is inherent in flat. The documentation says: "To convert a list back to an array apply flat to the list". It will break if the array is supposed to contain lists as some elements. These operations which do a particular thing for almost all values, *except* when values are of a particular type, are just misdesigned.

flat returns a flattened form of a list.

"get-char: Gets a character from an address specified in int-address." - An address represented in 32 bits? So it will not work on 64-bit machines. What a pity. C used to almost unify pointers with integers about 30 years ago.

Internal address can be defined to be anything when running inside newlisp which might be hosted on a 64 bit machine. On 64 bit machines one can build a newlisp with 64 bit integers in theory if that is what must be done. You are confusing machine address vs. newlisp address inside interpreter.

File handles represented as ints and I/O operations using system calls directly, with no buffering? I knew that this is C 30 years ago.

There is buffering. write-buffer exists. File handle is something returned by open. It being integer does not make newlisp bad. Most Unix machines use file descriptors that are integers. One can use a 64 bit value, but what would be the point? How many files will you have open? It would be just as easy to refer to files with names associated with a symbol, which is what i think of file handles, as returned by open. In fact i just use (read-file "filename") who cares about file descriptors?

In general, I'm disgusted. There is some work in wrapping C library functions, but the core language design, number and list processing is awful.

Why would one be disgusted by a software development tool like newlisp which is provided for free? You don't have to use it. Different people have different tastes. I love it and many others do. I thank Lutz for providing it for free! If you feel so disgusted, perhaps you can design a better language, implement it to run on most major platforms, and give it away for free like Lutz.

The name newLisp is misleading: it's not a Lisp and it's not modern. It tries hard to have neither garbage collection nor pointers, which implies that pointers must be simulated using unique constants which denote globally accessible structures, as if it was Tcl or ancient Fortran. It throws away the progress made in programming language design in the last 30 years.

In my view, newLISP is closer to original LISP than Common LISP because it is compact, efficiently implemented and attempts to solve only some problems, not all, in contrast to Common LISP which tries to solve many problem domains while keeping everyone happy by keeping all the old compatibility routines. Common LISP has not evolved with the rest of the world and it lacks modern programming features that newlisp has. And newlisp design allows for other languages for other things that they are good for (e.g. C for certain things).

Posted: **Thu Aug 10, 2006 9:46 pm**

pjot wrote: Concerning Perl. Reading the PERL man-page (man perlsub):

"The Perl model for function call and return values is simple: all functions are passed as parameters one single flat list of scalars, and all functions likewise return to their caller one single flat list of scalars. Any arrays or hashes in these call and return lists will collapse, losing their identities--but you may always use pass-by-reference instead to avoid this."

So by default, Perl passes by value.

Wrong. If you read further into persub, you will find this:

Assigning to a list of private variables to name your arguments:
Code: Select all
sub maybeset {
    my($key, $value) = @_;
    $Foo{$key} = $value unless $Foo{$key};
}
Because the assignment copies the values, this also has the effect of turning call-by-reference into call-by-value. Otherwise a function is free to do in-place modifications of @_ and change its caller's values.

Try running Qrczak's snippet - code does not lie.

Posted: **Thu Aug 10, 2006 11:04 pm**

Wel, I am tired of this "yes/no" game, this will be my last posting regarding this issue.

Posted: **Fri Aug 11, 2006 3:23 am**

Many people are confused about the terms "pass by value" vs. "pass by reference".

Qrczak's perl example:

sub change($) {++$_[0]}
my $x = 5;
change($x);
print "$x\n";

Result: 6

Here's a case where $x is passed as a true reference. The subroutine can internally assign a value to $x and the result is reflected after it has returned. The $x is changed. This is similar to the way C++ reference (via &) and C's way of taking address (via &) and passing to a function which expects a pointer. After return from subroutine, the reference value can be changed to a new value.

This is a very questionable programming construct, although I have used it myself. In a large software this kind of programming can cause a lot of problems.

Note, the CLISP example by Qrczak:

[1]> (defun test (x) (rplaca x 44))
TEST
[2]> (defvar obj (list 2))
OBJ
[3]> (test obj)
(44)
[4]> obj
(44)

Here is the case where the contents of the list can be changed by the subroutine. However list (the reference symbol for the list) cannot be changed by the subroutine. This is because LISP passes the reference to something after making a copy of that reference. The list inside function test (called x) is a copied reference. Assigning new value to x will not change the original reference (called obj).

Java works the same way. Do a google search on java and pass by reference. You will see a lot of messages. Including the quote by James Gosling saying something flippant about it. Gosling is used to thinking the lisp way -- he wrote Unipress emacs (ancestor of GNU emacs) which used Mocklisp as extension language (which by the way used dynamic scoping).

The problem with this kind of copied "reference passing" (in contrast to the way perl does it) is that it is unclear from the syntax. The same syntax is used to denote pass by value and pass by reference in these languages. Of course, the advantage is that it is probably safer this way.

C# on the other hand uses "ref" in similar way as C++ (via &). Just to avoid such confusion.

There are different ways : pass by value (CORBA), pass by copied reference (java, common lisp, etc.), pass by reference (perl, C++, C#, and C when used with &), and pass by value + explicit pass by reference copy using contexts (newlisp).

Guess which one I prefer? :-)

By the way, as much as I love Common LISP, I prefer newLISP. I was thinking perhaps a better name for newLISP would be UnCommon LISP. As the lisperati folks seem to hate us so much. But I guess that name is taken by Scheme.

Posted: **Fri Aug 11, 2006 7:13 pm**

afteralll Qrczak me not drop by at this forum anymore, he scores quite some reading
hits on this forum..hahaha... but still its all comes back to this compare "not? apple peer"..

newlispfanclub.alh.net

This is ridiculous

This is ridiculous

Re: This is ridiculous

confused pass by reference definition