development version newLISP 8.7.6

Started by Lutz, January 02, 2006, 03:24:16 PM

Previous topic - Next topic

Lutz

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

 

http://newlisp.org/downloads/development">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

Fanda

#1
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

Lutz

#2
For example:



(define foo:foo println)

(foo x y z)


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

Dmi

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

What is the proposed application for this feature?
WBR, Dmi

Dmi

#4
Debian packaging script is ready. (now with readline support)

http://en.feautec.pp.ru/store/newlisp-debian_8.7.6-1.tgz">//http://en.feautec.pp.ru/store/newlisp-debian_8.7.6-1.tgz
WBR, Dmi

Lutz

#5
>>> 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

Dmi

#6
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! ;-)
WBR, Dmi

Lutz

#7
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

nigelbrown

#8
Quote from: "Lutz"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

Lutz

#9
you still would be able to write that macro:



> (define-macro (foo) (args))
(lambda-macro () (args))
> (foo :var x)
(: var x)
>


So the only difference is that the colon and the symbol after it would be parsed as separate tokens.



Lutz

Dmi

#10
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:
(data-list 5) is sometimes less useful than
(data-list #customer-name)
(not meaning will it be # or another char, but the one, which will not gives special meaning in a feature)
WBR, Dmi

Fanda

#11
What about using it this way:


:add equals MAIN:add

or possibly

 
::add equals MAIN:add

Fanda