KazimirMajorinc

Apparently, it is some kind of sexual fetish. I flagged many of these videos as Violent and repulsive content > animal abuse, but without any reaction from Youtube. Some (but very few) of these videos are empty snail shells or imitations of snails.

If you feel empathy with snails please, flag these.

Newlisp is my favorite Lisp dialect. Before that I used Scheme and before that, CL. I prefer Newlisp because combination of dynamic scope and fexprs is conceptually simpler and more expressive than combination of lexical scope and macros. If reader doesn't believe me, he can check what Thomas Lord wrote on Lambda the Ultimate site, http://lambda-the-ultimate.org/node/3640

He really understood fexprs well. Or John Shutt's disertation. Or, this part of Alan Kay's interview: http://kazimirmajorinc.blogspot.com/2010/02/alan-kay-on-fexp...

Criticism of Newlisp? Well, yes and no - but, the point of every Lisp is, and particularly NL is - if something is missing, add it for yourself.

Picolisp is similar to Newlips, it is really minimal, very fast interpreter, written in assembler.

Other dialects have other advantages. But I'll stop here.

You can check my blog. There is a lot of code=data manipulation there. For example, this one:

http://kazimirmajorinc.blogspot.com/2009/12/symbols-as-sexpr...

This post describes implementation of hygienic (even recursive hygienic) fexprs in Newlisp.

Yes, it's fun. PLT Scheme editor supports similar "block style" parentheses highlighting, and it is useful for reading large data sets or machine generated code.

http://plt-scheme.org/screenshots/french-profiler.jpg

Very interesting work.

Good luck, Bard.

I think Wand's result is straw man if used against fexprs - and Wand really didn't used it that way. Essentially, he says, with fexprs, there is no source => source transformation that can work in all contexts. Ok - but I am not interested in such transformations. Very few programmers are. Whole practical point of these transformations are that they can help to implementers to implement optimizing compilers.

But - if one wants source -> source transformation that works in ALL contexts, whatever the reason, he can limit his own use of fexprs - and hence, allow various degrees of such source transformations. For example, he can use fexprs under same limitation macros are used, and in that case, fexprs can be "compiled away" just like macros can. But - he can do it on his own, in some or all of his projects, or even only in some parts of the projects. There is no need to make collective decisions of that kind. Again, it is consistent with idea of Lisp, in which borderline between language designer and programmer is blurred, or at least, it was imagined that way initially.

Shutt has interesting and novel approach, and his approach is independent of the severity of overshadowing of the variables problem he addressed. And how severe is that problem? Not really. It is actually the same problem that exists with macros, and techniques used in CL or Scheme (gensyms, hygiene) for macros can work as well with fexprs.

If you use eval in your program, the program will macroexpand each time it evaluates code containing macros. As even standard operators like setf are macros in CL, it will practically macroexpand each time it uses eval.

So, macros really slow down all or practically all programs containing eval. One can avoid evals, but from my point of view that means avoiding the most powerful, the most fun code=data feature in Lisp. It doesn't look good to me. So, why should one avoid eval?

"Eval is to be avoided because most of the time there are are a lot of more structured ways to do exactly the same thing." I miss the point here.

* Fexprs are easier to write and more expressive than macros. They can be mapped, applied, wrapped around other functions, fexprs and built in primitives, in the case of Newlisp, even mutated during runtime. Fexprs are lot of fun. And the price is - dynamic scope. More about dynamic scope later.

* ORO is something in between "manual" memory management like in assembler in C and real GC. It is "more automatized" than former, and less automatized than later. Basically, i agree with you, GC has some important advantages, but ORO is - adequate - and I'd say, not completely without advantages in practice as well. (Theoretically, GC is not excluded in the form of libraries. In past there was little interest for that, but Greg's recent "Objective Newlisp" library provides simple, reference counting-based GC algorithm.)

* Dynamic scope - it gives more expressive power: the functions in dynamic scope are about equally expressive as macros, and they are the first class values. The problem with dynamic scope is - accidental name clashes, or "overshadowing." That is where static scope helps and I understand it is reasonable choice for languages like Ada, Eiffel and many others: safety over expressiveness. However, it was not original design goal of Lisp, supposed to be very adventurous language - and it is still visible: CL, Scheme and Clojure programmers have to face exactly the same problem if they write macros. The solutions: namespaces, gensyms and "hygiene" work on the same or similar way for Newlisp dynamic scope. So, it is not really consistent to complain against dynamic scope as unsafe, and to believe that macros are (or can be) "safe enough."

Closures are the functions with "private" data preserving values between two calls of the same function. It is not impossible with dynamic scope - but problem is again accidental name clash. As it is the same problem as with macros - I guess it can be solved on similar way - using functions with generated unusual and unique names of variables.

On the other side, with dynamic scope, functions are as expressive (or almost) as macros and they are the first class values. For example, one can implement "if" as a function. http://kazimirmajorinc.blogspot.com/2009/01/two-definitions-...

There are few ways out of that:

1. use of "contexts" i.e. Newlisp namespaces

2. use of same approach as in CL or Scheme macros. In CL it is automatic generation of unusual names, gensyms, in Scheme it is even more automatic "hygiene". Both of these approaches are available in Newlisp as well. One can check my blog post at: http://kazimirmajorinc.blogspot.com/2009/12/symbols-as-sexpr... It is not simple reading if one didn't used dynamic scope, but essentially it is how one can write hygienic fexprs (Newlisp macros are actually fexprs).

3. use of some "OO" additions. I am bit of OO sceptic, but for those who are not, there are at least two OO systems for Newlisp.

3.1. Official FOOP system, still in development http://newlispfanclub.alh.net/forum/viewtopic.php?f=2&t=...

3.2. Greg's OO system http://www.taoeffect.com/blog/2009/12/introducing-objective-...

This problem exists, but it is equivalent to problems Common Lisp programmer has to face if he writes macros, and solutions are similar. In CL it is solved with gensyms, and Scheme hygienic macros automatised that. Similar approaches are possible - and practiced - in Newlisp.

In my opinion, dynamic scope is adequate solution for Lisp approach, i.e. expressive power on the first place. Newlisp is very simple and expressive dialect, and it is pleasure using it. Dynamic scope allow some things statical scope doesn't. Sure, the price for that expressive power is that one has to be more careful, but this is not really that hard, and it shouldn't be the problem to anyone who really accept basic Lisp ideas.

I can see how dynamic scope - just like dynamic typing, eval or macros - could be seen as problem for people who want language like, say, Ada that puts safety on the first place. It is legitimate position. But it is not design goal or tradition of Lisp. Lisp is designed for AI, exploratory programming, hacking, expressive power, adventure. Owner of this site, Paul Graham, frequently wrote in that vein. It is simply not consistent to brag about expressive power of Lisp, and then turn into safety freak when one mentions dynamic scope.

OK safety freak is maybe too strong, but you get the point.

It is true, Lisp means any Lisp, and it is specifically noted on the advertised poll that all Lisp dialects are included.

It is also specifically noted that Lisp programmers who use Lisp part time have right to write why they do not use Lisp - when they do not use it.

There is a huge variety of reasons and ways people think.