newlispfanclub.alh.net

Hi Lutz,

When I look at newLisp i see a powerful and damm good intepreted language.
It realy is and i love to use it and its fun!
.......And with that in mind... Im having some real nasty problems to get newlisp into the blue........

I mean implementing newlisp Into all the programming I like to do and thats
a hard thing to do currently...

Now what im Missing is a damm good way to to extend newlisp or embed newlisp.
(Im talking here as a Lazy programmer who wants to create tools and programs the quick he can with fun and not nozing down to lowlevel programming details like C or C++..)

So How to extend Newlisp with another Library or Toolbox or VM?
Well I tried hard and looked in many corners to get it right but there are
only 3 things how to do this as we know ->

(1) communicate with newlisp through CGI
(2) communicate with newlisp through IO (tcp..stdin...)
(3) communicate with newlisp through Library's

Im realy stuck and I mean realy stuck! ;-)
I want newlisp to be used in everything I make and that means Library porting from C/C++ to newlisp..
Well on itself it seems easy but its not always sunshine proting 1000 of lines header files.. So quiting a project is very quick very nearby everytime...

Actualy what Im seeking in newlisp is a procedure that uses a smart way
to import Header-files directly into newlisp. Well we all know that Phyton and Perl are very good at that and also TCL can do that (with some help from SWIG)...

Now when I look at LUA or SCHEME or CL-Lisp they all are able to migrate C or C++ code smarter into their language. Its quicker and directer.
(recompiling newlisp afterwards could be an option but intepreted use is prefered)

There must be a way to extend newlisp (and now im putting my EndUser hat on) to be able to do so ....

So how difficult is it to extend newLisp with a way that would make extentions to newlisp for the ordinary user
(not the C programmers but the newlisp users) more easier then importing Libray's?


Another way to think about the above it the other way around..
Implementing newLisp into other languages or toolkits! Like "extention"-languages..
And im talking about newLisp itself as a language. Look i.e at LUA and JAVA..
LUA is nice very nice in this and especialy developed for it.. and JAVA..well yes
it uses a VM..not quiet fair play... But scheme and Perl do it.. and i guess Python too..


So what about all my Fuzz?? ;-)
Well currently its frustration...Im fedup with porting Library's from C++ to C,
recompiling , rewriting header files into newlisp..Thats all the positive of not wanting to program in C ;-)..
I made a choice and it clearly is Lisp and in this case newLisp. But im stuck right in the middle.


Hope you have an idea on the above?...

Regards, Norman

Now actualy it seems im not the only person that has this problem. There
are loads of others who have the same problem with other languages too.

And after reading some articles and blogs on the internet the gerneral idea seems that somehow for the core programming people will choose their language that fits the best for their purpose and build around it with toolkits and extentions.. i.e. GUI extentions or Sound.

But it all comes back to C programming, and That is what i need to avoid..

Somehow it would be nice to say in a newlisp script something like ->
(include "header.h") which converts all the data from the header directly
into some newLisp code.. Or at least defines the functions, structs, constants in that header right into newlisp.

I dont have a view on the amount of work on this or tools that can do this (Looking at SWIG i.e.)

Whats is your though about this lutz?

Regards, Norman

Probably some newLISP code could be written to parse header files and convert function specifications to newLISP import statements and funtion stubs containing supporting code.

The advantage of this approach would be that it creates no new overhead in the newLISP executable. You would run this import conversion once and then have your import file for you specific purpose.

On the other side nothing is as efficient, small and fast as an import interface crafted by a good 'C' programmer.

Lutz

Sorry...
It's all sounds like wrapper around (import) which will automatically construct newlisp functions based on C-headers?
Or I miss something?

Yes thats right but on the otherhand Im seeking for a wider use of newlisp.
Use newlisp as the main language for binding to C++ and C library's but also
making newlisp part of other languages.. A kind of LUA idea..(extention languages)..

The whole world has only a a few good langauges , Isnt that odd??
Even more strange is the fact that in 20 years time we only have a handful of GOOD (but only accesible by C or C++) GUI toolkits, where only 3 of them have there integrated intepreted language, that im frustrated to the bone about not to be able to use those without a good middle-layer to communictate to it...... What is avalable is only usefull for C++/C programmers when its about extention....Thats very stupid...dumb!

Somehow C++ keep ruling the world and even JAVA is still getting more and more popular (But who wants a VM of 50MB??)..

I simply think that Highlevel programming should become mature.

I have roamed and found only 2 languages last 10 years that suit the furture, based on language layout (elegance and power). Those are
newLisp and Rebol.

Regards, Norman.

Hmm... So we need an .h/.hpp parser which will automatically construct newlisp wrappers around .dll/.so functions.
Here is one question: do we need in such parser or gcc/g++ can do it for us?

Can't we generate pure .c file with all the functions we've called from newlisp code, then simple compile it into .so/.dll/client-server-executable, import/connect it and will have a bunch of newlisp functions with automatic type-conversion done.
Let's turn our compiled file into "cache" to avoid unnecesairy recompilation...

Indeed you could look at it the other way around: program C but import the newLisp SO or DLL and use those functions. You could even create #defines to wrap newLisp funcs into readable C-statements. Maybe then we need an archivefile of newLisp so we could compile the resulting program statically.

In this situation you have the freedom to use newLisp, but you will also have access to other libraries. Some basic C knowledge is required, of course, but the main things can be done using genuine newLisp functions.

For the other libraries, the main problem will be finding a layer which is simple enough to use. For example, programming xLib is something I wouldn't do, because it's too difficult; I'ld probably use GTK or some other abstraction layer which makes life easy.

Peter

That's the reason why I use the combination of neobook/newLISP.

Combine a excellent GUI/RAD tool with the powerfull but lightweight newLISP, and you get a dream-team. Only drawback is, that neobook is not multi-platform. Through neobook's plugin interface and newLISP 'import' function you can add other code-modules written in other languages easily.

Just my 2 cents (euro)!
;-)

Let's turn all C-functions into commandline (as for tcl).
Then let commandline will use lispish infix (with lists instead of plain text).
Sounds pretty unreal... but this thing is one we all like to see ;-)

Btw, can we develop a common rules (template) for building .so/.dll with functions that can be automatically wrapped into newlisp code?

- It would be fine to have a C-library with functions to construct and iterate newLisp lists (and corresponding newlisp code that will pass and get such lists from library calls).
- Then we can have in each such library a function with predefined name, that will return text/list specs for other functions in library, so some newlisp wrapper function around (load) can automatically build proper, fully functional newlisp functions-wrappers around library contents.

A way like a tcl does, but I'm not a specialist in this technique details...

well the problem is more the Struct unions en nested kind of stuff... But a addon for SWIG that does the jobs porting to newlisp would be nice ;-)

My idea is that i dont want to be involved in any C programming at all!
I chose 100% for higher languages which give me the speed but the disadvantage of not be able access C related issues is a fast matter..
I hate switching programming languages.. Brrrrrrrr....

Over and out from Leipzig (Germany)

Norman.