newlispfanclub.alh.net

Small syntax goodies can really make a big difference in writing code. In my opinion the implied indexing is an excellent example of this. Thinking of these kinds of things I considered how often I write

(list a b c ...)

One instinctively wants to simplify it to just (a b c ...) but this might conflict with implied indexing if a or a and b are integers. But what if we made this simple change ( a b c ...) where we require a single space between the left parenthesis and the first argument? This would only require that we be space sensitive when writing a list but nowhere else and enable us to eliminate having to type "list".

A second idea along these lines returns me to a previous idea I had initially suggested for nested functions wherein something like
(fn3 (fn2 (fn1 x))) could be written as (fn3 fn2 fn1 | x). It occured to me that this could simply be written as the briefer (fn3 fn2 fn1 x). Couldn't the NewLISP translator recognize several function names in a row and assume nesting for the expression?

Of course there may be other issues I am not aware of but I am a minimalist at heart and am always looking for somewhere to trim something down. I think all LISPers are in search of some minimal purity of expression. In any case, I thought these two ideas would be something that could be added without disrupting any previous syntax. The coder could do it the old way or new at their discretion.

LISP syntax and evaluation relies on one simple rule: that the first element in a list is an operator or function applied to the rest of the elements in the list, which constitute the arguments: (func arg1 arg2 ...). Anything changing this would only complicate the syntax and workings of LISP and create ambiguities when reading the language.

The term '(a b c) already constitutes a list. Writing (list a b c) is only necessary when you want the contents of the variables a, b and c be the elements of the list. I.e. if 'a is 1 and 'b is 2 and 'c is 3, then writing: (list a b c) is the same as writing (1 2 3).

There is probably no syntax more minimalistic and flexible than the LISP syntax, which is a mayor attraction to use LISP as a programming language and data modelling language at the same time ;)

Lutz

I repeatedly returns to an idea, that newlisp can get another piece from traditional lisp way:
Now newlisp features are mostly implemented as binary compiled code.
Many really nice fetures, but there is a place for important ones only - this makes newlisp small.

I think, it would be cool to have newlisp standard library, written in newlisp itself.
More precisely, three libraries:

Standard lib: maintained by Lutz, consists of features, that _Lutz_ will found useful but not for c-hardcoding, and included in distribution.

Feature lib: half-official library, maintained by the community by electing functions from "candidate pool". Probably, also available from official site.
Some functions from Feature lib can also be selected by Lutz for including into Standard lib.

Candidate pool: some list of distinct functions, available for search, download, testing and voting for including to Feature lib.

...something like this ;-)

Dmi: I like your idea very much!

- we could learn from somebody else's functions and also use them in our code
- some functions from Code Snippets could be merged with the Standard lib

Fanda

I also like the idea, specially if it is community driven and maintained, perhaps even with an HTML documentation file?

Feel free to take anything published from newlisp.org and other contributers. Peter (pjot) and Norman (newdep) have both code collections with some useful functions in it as well. I don't think anybody is opposed of letting his/her stuff beeing included in such a stdlib.lsp library. If there are questions about copying stuff just ask these people here on the board.

Lutz

May need some agreed naming convention for std library so including it does not break user code too often - either stay away from generic sounding names, or have a standard prefix eg lib-xxxxxxxxx, or keep them in their own contex STDLIB: , or some other way?

Nigel

Good idea. Some additional thoughts:

1) Maybe we also should follow some coding standard in order to have a readable code layout?

2) Who will be the maintainer of the contributed functions...? The original author or the newLisp community?

As with many of us, I re-use many functions, and get many ideas by reading other people's code. So a standard lib would really be great!

Peter

Some proposal around:
1. naming convention.
- imho the prefixes such as lib- will broke readability as well as the pleasure from their using. If we really want a separate namespace - context will be better.
- general language, '-' - delimited names as in regular lisps will offer a good readability, lexical-destinctivity and usage autodocumentation.
- three-stage way to form a 'final' standard library will support the soft way for name conformation.

2. syntax rules.
- I found some fine notes at http://www.notam02.no/internt/cm-sys/cm ... style.html.
- we can recommend a common indenting and commenting rules.
- now, frequently using dynamic variable passing, I think, that it is useful to mark them (probably with standard *...*) but not check it in practice yet ;-)

3. packaging.
Yes, anybody can publish it's own library. Occasionally this is a way to name conflicts... And will make browsing difficult: realise, that you want one function from one package and other - from another one...
Better, if anybody who wants to contribute will do it in a three ways:
- a separate context
- a single function
- a bundle of a few functions that are the unbreakable composition.
So anyone can collect any functions from this pool in it's own _single_ 'contrib' package.
Moreover, we may have a voting engine with positive and negative votes, that will offer a (probably) objective way for including in second-stage official community library (I mention it 'feature' in previous post).

4. documenting.
- contributed code must be able to be freely commented by author/maintainer with standard ';' - way.
- also there must be a documentation on fuctions/functionality. Imho, because of difeerent syntax, this must be a separate file: one documentation file by one source file.
- documentation rules:
It must be formalized to something like Lutz's manual. But it will be cool to strictly recommend separate sections such as "return value" or "exception cases". Like it is in UNIX man. Now it is sometimes hard to found such information from function description. (nevertheless, whole newlisp documentation is GREAT ;-)
- documentation syntax:
HTML is nice, but overloaded by visualisation tricks. Better (imho) we can have an easy-writable and parseable syntax, that we will easy transform to html when needed (with small newlisp script of course ;-)
Bsaically, all we need is '(function header itallic bold underline bold-itallic) - markers and marker for code/terminal output style.
something like //itallic// **bold** /*bold-itallic*/ %%code%% ==header==
... or something other easy-writable.

5. versioning.
We will need in it. But I don't realize yet. Probably simple rcs/cvs access will be sufficient.

6. Search/download/control access to repository directly from newlisp (by some library) will not be obligate, but will be nice thing. Or, by inverse, can be preferred way for interacting...

7. So many proposals here... really I think we must forgot most of them and start from someting small :-)

P.S. You'll find above many hidden references to unix, debian apt tool, man, lisp and other well-known ways... I simply trying to compile them right for us.

P.P.S. It's all now. Sorry for my english (in such ugly volume... ;-)

I am proposing to set up one of these:

1) Wiki - everybody can add/delete functions

2) Shared FTP account - everybody can upload his/her functions in files => fanda.lsp, dmi.lsp, ...
Only administrator can delete.
(Would it be possible to overwrite files? I guess not - somebody could overwrite with an empty file => fanda01.lsp, fanda02.lsp, .....)

3) Add new category into our forum: "Community library" (or something like this).
Every person could have his/her own thread (or multiple of them) and keep editing one/several message(s) with each new version.

When this is up and running, there needs to be somebody to vote and pick a "good ones" => they could be placed into a special HTML file.

Fanda

We could add a wiki to this site, if there is enough interest. And adding more discussion threads is easy. But unfortunately, there are no FTP privileges with this hosting plan.

FTP mode would not be so important as all of the files are in text mode. If somebody contributes binary stuff it can be distributed elsewhere (like the RPMs, TRUE64 versions etc.).

Lutz