Just out of curriosity

Started by newdep, May 13, 2007, 01:42:01 AM

Previous topic - Next topic

What could enhance newLisp

'real' threading
1 (9.1%)
'nested' contexts
2 (18.2%)
'integrated' Gui
5 (45.5%)
'newlisp-like' regular expressions (not the cryptic PCRE)
1 (9.1%)
'call-backs' in i.e. get-url functions
0 (0%)
Comments/help inside lambda
0 (0%)
Other (please provide feedback below)
2 (18.2%)

Total Members Voted: 11

Voting closed: May 13, 2007, 01:42:01 AM

newdep

This poll is just out of curriosity, not to pressure Lutz at all,

Im just currious from what extentions newLIsp could benefit.

(The list provided is something I ran into over the years,)
-- (define? (Cornflakes))

HPW

#1
My vote was for 'intergrated GUI', but I am not sure what this would be in fact.

Is newLISP-TK not an integrated GUI?



Would a integrated GUI multiplatform?

Would a integrated GUI be a single process on each platform?

Would a integrated GUI a lispy GUI definition?



Is such a wish realistic?

Wouldn't it be better to spend the resources into the language itself?
Hans-Peter

cormullion

#2
Interesting idea. What is 'real threading' and 'comments/help inside lambda'? Is 'integrated GUI' something like newlisp-Tcl?



I can't see anything in your list that I'm pining for, but it would be useful to be able to generate PNG images, and handle Apple Events (Mac-only, that would be... :-)). So I think I'm hoping for more libraries, than for changes to newlisp itself...

newdep

#3
Owwww what did I start ;-)



Actualy 'real' threadnig is ment like 'threads' not fork.



'integrated' GUI is not realy fare to say, as anything that can talk

with a GUI is integrated, perhpas thisone is far out of range.



The integrated help inside a lambda.. this is like every lambda define

has a help / note inside it.. There is a discussion on this topic already

on the forum...





I realy love the way Rebol does parsing, thats so fantasticly build,

it uses it own syntax which is not cryptic at all and very good to

debug afterwards, because its readble. I dont say newlisp should copy

this but what would be nice is to have a 'smart' linguistic-like Parse library,

that replaces all the ()!@#$%^&*()}{":.,<>..etc.. so the result could be

functions like: (parse {something....} (println (remove quotes | tags )))



Mmmm perhpas i shall not post these thoughts again ;-)



Norman.
-- (define? (Cornflakes))

Jeff

#4
Traditionally, anonymous functions are used for short expressions that should not require an elaborate amount of explanation.  If you need something complex, it should be a defined function.



As far as newlisp-like regex... what else is there?  PCRE *is* regex.  There are other pattern matching systems out there, but PCRE is the most well-known, and pretty good for many uses.  The language would die a fast death if it didn't have pcre.  What would you suggest to replace it?



As far as callbacks... well, I'm not sure whether I would want newLisp to become an asynchronous language.  Things like that can be done with threading and macros; being asynchronous by default would change the nature of the language.
Jeff

=====

Old programmers don\'t die. They just parse on...



http://artfulcode.net\">Artful code

newdep

#5
Yes the regex is a difficult part but would beautofy the language more, but that

more a personal opinion i guess. For the call back.. well  the functions of get-

are static C and do not profide raw-data callback during the execution. A Get-url

finishes when its done reading but its impossible to analize the data stream during

a get-url action.. thats actualy what i had in mind with callbacks.. the same goes

for a some file actions.. data analize takes place after the read not during...that

sometimes not handly..and the result is rebuilding the function, which is a pitty

because its already there...



Norman.
-- (define? (Cornflakes))

Dmi

#6
I miss some capabilities in an embedded parsers:



- I think (humbly ;-) that parsers (parse, xml-parse...) should supply the positioning information about parsed data in the input buffer. Otherwise we must each time to introduce the own pseudo-parser that will pre-split the input stream into a syntactically finished pieces. In fact, we can't effectively deal with non-http network protocols without that.



- It will be very cool to have a version of parse (with regexps) which will not eat a delimiters, but will leave them as regular elements of a result list.



Probably I do something wrong, but theese I encounter (and miss) in pretty each parser-oriented task :-)
WBR, Dmi

Lutz

#7
Some comments to the feature discussion and an announcement.



- Threading

We have UNIX forks they are a good substitute for threads because of newISP's small process size. Most appplication where threads would be used are easily done with forks.



- Nested contexts

The context/namespace system in newLISP comes from an earlier language project called RuleTalk (a Prolog like language). This had nested contexts with inheritance from the ancestor levels. The experience building programs with these made be abandon the idea and implement a flat context system for newLISP. Initially with inheritance for symbols in MAIN, which was later abandoned too.



Nested namespaces are well suited for langguages like Java or JavaScript but not well suited for a Lisp functional programming language, where the main organizing paradigm is the list.



Use a combination of contexts, symbols, lists and association lists to configure complex data structures. When data structures are defined this way they are much easier to handle in a functional way with newLISP's repertoir of built-ins for function application, mapping, lookups in association lists and iteration through lists. On the highest data level and for building dictionaries/hashes use contexts.



- GUI/graphics

I am working on this as we speak :-), it is completely platform independent, with modern features like antialiased graphics and fonts, transparent colors (alpha channels) and handling of images. It is implemented as a graphics/GUI server talked to via a newLISP written module implementing the Lisp API and documented using newLISPdoc.



The GUI/graphics server can run together with older versions of newLISP. Different from the current TK interface app. the GUI/graphics server will be used similar to a library for building GUIs and draw/animate graphics using a Lisp API. A complete development environment with editors browsers etc. as delivered with newLISP-tk will initially not be available, but could be well written using the GUI/graphics server.



Some first small GUI demo apps are running right now. I hope to have the first development version of this ready by the end of this month. The GUI server runs out of the box on Win32 and MacOS X and Ubuntu Linux v.7.04 (it would be trivial to install required software on other distros and UNIXs).

 

- newLISP like regex

we had 'match' for strings (still have it for lists), but I threw it out. As Jeff pointed out, PCRE regex today is the string-match standard in any programming language, and well worth to invest time learning it. They should teach it in kindergarden ;-)



- call-backs

they are already in newLISP since 9.1, see:

http://newlisp.org/downloads/newlisp_manual.html#callback">http://newlisp.org/downloads/newlisp_ma ... l#callback">http://newlisp.org/downloads/newlisp_manual.html#callback

see also the opengl-demo.lsp file in the distribution, which uses call-backs together with the GLUT libraries.newLISP 9.1 brought a new internal implementation for higher order functions and the trend to put more of these into the existing API will continue. Version 9.1 added function arguments in 'find', 'ref', 'ref-all' and 'replace'. 'xml-parse' is the next candidate. 'curry' will get more flexible too.



- comments/help inside lambda

There are already ways to do this, e.g.:
(define (double x)
"This function takes a number and doubles it"
(+ x x))


But we have something better: http://newlisp.org/newLISPdoc.html">http://newlisp.org/newLISPdoc.html and used here: http://newlisp.org/code/modules/">http://newlisp.org/code/modules/ . This system creates syntax patterns and has a formal way to describe parameters and working of a function. The program is very small and easy to modify for your own purposes, in the latest version (delivered with 9.1) is also integrates syntax highlighting of the source in the same program.



Lutz

HPW

#8
Quote- GUI/graphics

I am working on this as we speak :-), it is completely platform independent, with modern features like antialiased graphics and fonts, transparent colors (alpha channels) and handling of images. It is implemented as a graphics/GUI server talked to via a newLISP written module implementing the Lisp API and documented using newLISPdoc.



The GUI/graphics server can run together with older versions of newLISP. Different from the current TK interface app. the GUI/graphics server will be used similar to a library for building GUIs and draw/animate graphics using a Lisp API. A complete development environment with editors browsers etc. as delivered with newLISP-tk will initially not be available, but could be well written using the GUI/graphics server.



Some first small GUI demo apps are running right now. I hope to have the first development version of this ready by the end of this month. The GUI server runs out of the box on Win32 and MacOS X and Ubuntu Linux v.7.04 (it would be trivial to install required software on other distros and UNIXs).


Whow!



That sounds hot!



So will newLISP.exe import the GUI-lib?

What has to be delivered?

Can you make a download of one of the small GUI demo apps?
Hans-Peter

HPW

#9
Another question:



Will the new GUI also callable from newLISP.dll?
Hans-Peter

newdep

#10
I just lost my socks!... that sound rocks ;-)
-- (define? (Cornflakes))

Lutz

#11
QuoteSo will newLISP.exe import the GUI-lib?


newLISP will do a (load "guiserver.lsp") as the first statement in your GUI application and then use (gs:xxxx ...) statements to build and control the GUI and draw graphics.


QuoteWill the new GUI also callable from newLISP.dll?


Yes


QuoteWhat has to be delivered?


(1) the newLISP executable

(2) guiserver.lsp - module file

(3) GUI server executable (probably less than 200K)



(4) yourApplication.lsp

(5) You applications *.gif, *.jpg, *.png fils for images and icons



(1) to (3) are all installed by the newLISP binary installers on all platforms Win32, MacOS X, Linux/UNIX.



(4) and (5) are packed and delivered by yourself in an installer.



On Win32, MacOS X and UBUNTU Linux (latest 7.04) nothing else needs to be installed. On other Liunx/UNIX something (guess what? ;-)) else needs to be installed, but is trivial.



On Win32 you start your program from a batch file, which has an icon. You deliver the application pakaged with any installer, e.g: NullSoft free installer used in newISP-tk.



On MacOS X you start your program either from a .command file or from and AppleScript .app file, both can have an Icon. You deliver the applicaton as an .dmg installer diskimage which will install the icon and (4) and (5) in the Applications folder.



On Linux there are different methods how to deliver program packages with clickable icons.




QuoteCan you make a download of one of the small GUI demo apps?


Together with the first development version later this month. I have a little button app already running:



http://nuevatec.com/Button-1.png">

http://nuevatec.com/Button-2.png">

http://nuevatec.com/Button-3.png">





Lutz

newdep

#12
Now my socks completly left the room!



There arn't many multi platform gui packages that have antialiased graphics and fonts, transparent colors (alpha channels)..  I think i have a clue... ;-)
-- (define? (Cornflakes))

HPW

#13
Whow again!

Very promising news!
Hans-Peter

newdep

#14
I like to peek at that code ;-) actualy...
-- (define? (Cornflakes))