newlispfanclub.alh.net

Several improvements and bugfixes, for files and change notes see:

http://newlisp.org/downloads/development

Note that there is an extension to the build system: by just typing 'make' a script called 'build' will try to figure out the platform it is running on and choose the right makefile. 'make help' will bring up all the old choices.

At the moment MacOS X with and without readliune support, Linux, FreeBSD, OpenBSD, NetBSD, Solaris and Windows XP are all discovered automatically, but I need still need put in discovery support for libreadline on Linux (next time).

Lutz

I forgot to ask about 8.7.5.
It says that you can "allow default functions to be defined as primitives".

Could give me an example?

Thank you, Fanda

For example:
and you could have some other stuff supporting that function lexically separated in the same context 'foo'. i.e. in OO programming. I don't have a real world example at the moment, but ran into needing it some time ago.

Lutz

: (colon) now will be returned as token even if attached to other following chars

What is the proposed application for this feature?

Debian packaging script is ready. (now with readline support)
http://en.feautec.pp.ru/store/newlisp-d ... .7.6-1.tgz

>>> What is the proposed application for this feature?

don't know yet, its up to the user. One could define it as an operator or function and use it as some sort of prefix.

Lutz

Just an opinion...

There was already a way to define an operator or another symbol for ':, or for ':something. Like for '+ and '+something etc.
Now complex forms such as ':something became unavaliable.

Also this makes some difficulties for introducing lisp-like keywords.

...and also this crunches a clear lisp syntax, where two separate words are _always_ separated by a space. (except only for brackets and a quote).

There must be a cause! ;-)

In newLISP the colon is also a syntax element for separating the context name from the variable-symbol name, so now the colon is represents a parseing border to the left and right just like a a parenthesis or a comma.

As long as one leave thes ':' alone nothing has changed except for makeing symbol-names like ':something' unavailable, which may be a good thing, because it would have been confusing for the reader of the program. On the other side it opens the possibility to define the ':' to something related to contexts. I did not have any specific plans or intentions doing this, but perhaps somebody comes up with something interesting ;)

The whole change came about while reviewing the getToken() parser code fixing another issue, and I thought the ':' should be treated by the parser similar to the comma ','.

Lutz

Lutz wrote:makeing symbol-names like ':something' unavailable, which may be a good thing
Lutz

On the other hand it probably stops one doing a macro that could accept the standard keyword style - I've not thought this through but I gather that
(my-keyword-driven-fn :x 2 :y 3 :b 2 :a 4) can't be done now?

Nigel

you still would be able to write that macro:
So the only difference is that the colon and the symbol after it would be parsed as separate tokens.

Lutz

Virtually yes, but really this encounter many restrictions and complexity.
But, probably, the usage of one symbol in two senses isn't a good idea anyway.

Btw, there is a place for conformation about some reommended (not hard-coded) prefixes meaning: either we need one for keywords...
...also I like an idea about one for list's indexes: is sometimes less useful than (not meaning will it be # or another char, but the one, which will not gives special meaning in a feature)

What about using it this way:
or possibly
Fanda