| View previous topic :: View next topic |
| Author |
Message |
PeyloW
Joined: 12 Oct 2005
Posts: 14
Location: Sweden
|
 Posted: Wed Dec 07, 2005 12:07 pm Post subject: What to do next |
 |
|
Well since at least two people are on hold for using the project, it is of interest to know what is causing the hold. So this thread is the place to state what you are waiting for, so I can do some prioritisation for what to do next.
First up, the project being marked as alfa-stage is incorrect, the code is stable, has no known bugs, and the major implementation designs are set in stone. As a fairly low number of test-cases are made beta should be an accurate designation, but hey, anyone is welcome to write them  .
I start up with telling what I currently intent to do, and in what order. And then what I have sort of decided to neglect for the time being, or completely .
Next up is:
Iterations, they can already be done using recursion, and had it been schema it would be the right thing to do. But function calls have a overhead and is not quite the Lisp way. Function planned are do, dotimes and dolist.
Listfunctions, same as with iterations, recursion works but listfunctions is much more effective. mapcar and less likely maplist and map.
As a library, so we can call Lisp functions from say C , a php-extension for the heck of it.
Streams, mapping over phobos Stream-class, and allowing for streams on strings, for some better communication with the calling language when embedded as a scripting language.
Bignums, integers with precision limited only by ram. Not of high priority, but can be useful for me atleast when doing database access from PHP where integers are sadly limited to 32 bit.
Optimisation pass, constant folding, dead code elimination could be done, and function replacement could be quite easily done.
Will be ignored for now:
Symbol slots, symbols will not have seperate slots for value, function, documentation etc data. This means two things;
1. You will not be able to have a function with the same name as a variable. so (defun foo (list) (unless (null list) (list (car list) (list (rest list))))) will never work. But if you name a variable simply as list, then you have other problems anyway.
2. (mapcar #'(lamda (a) (abs a)) '(1 -2 3)) will not work, instead do (mapcar (lamda (a) (abs a)) '(1 -2 3)). A bit more like Scheme, but the loss in spead, code-complexity and imho code readability is not worth being CL compatible. If running a 1000 lines+ production application is your goal then Cmucl is probably what you want, not dLisp.
&key for arguments, the mayor bottle-neck is currently function calls, I see no reason to slow it down further with functionality that does not give usability gains on par with the complexity and performance loss it introduces. |
|
| Back to top |
|
 |
brad
Site Admin
Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA
|
| Posted: Wed Dec 07, 2005 3:11 pm Post subject: |
|
|
Files and File I/O would be a cool feature if it's not there already. I'm thinking of embedding this engine into another D app to provide a scripting language to do more dynamic things with files on the file system, as well as data in databases.
I'd be interested in the File I/O as well as the iterators and list functions you have on your TODO.
Thanks,
BA
P.S. Do you want me to mark your project as beta or production? |
|
| Back to top |
|
|
PeyloW
Joined: 12 Oct 2005
Posts: 14
Location: Sweden
|
| Posted: Thu Dec 08, 2005 1:38 am Post subject: |
|
|
| brad wrote: | | I'd be interested in the File I/O as well as the iterators and list functions you have on your TODO. |
It is streams you want then. Only planned for working with text-files as otherwise I would have to implement arrays as well, to handle bytes and such. But for scripting I guess text is fine?
| brad wrote: | | P.S. Do you want me to mark your project as beta or production? |
Production would be bold, but beta feels justified. |
|
| Back to top |
|
|
brad
Site Admin
Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA
|
| Posted: Thu Dec 08, 2005 8:11 am Post subject: |
|
|
| PeyloW wrote: | | brad wrote: | | I'd be interested in the File I/O as well as the iterators and list functions you have on your TODO. |
It is streams you want then. Only planned for working with text-files as otherwise I would have to implement arrays as well, to handle bytes and such. But for scripting I guess text is fine? |
Yes, text is fine.
Also, I need to do some filesystem operations like move or copy files. I'm not sure about the commands in Lisp, or if I'd even use streams or use a call to the OS.
Will I be able to send values of variables from the D program into the Lisp script and (somewhat) vice-versa? i.e. every script run will have access to certain D variables, as well as reporting errors from the script back to D.
| PeyloW wrote: | | brad wrote: | | P.S. Do you want me to mark your project as beta or production? |
Production would be bold, but beta feels justified. |
done |
|
| Back to top |
|
|
PeyloW
Joined: 12 Oct 2005
Posts: 14
Location: Sweden
|
| Posted: Mon Dec 12, 2005 2:42 pm Post subject: |
|
|
| brad wrote: | | PeyloW wrote: | | brad wrote: | | I'd be interested in the File I/O as well as the iterators and list functions you have on your TODO. |
It is streams you want then. Only planned for working with text-files as otherwise I would have to implement arrays as well, to handle bytes and such. But for scripting I guess text is fine? |
Yes, text is fine.
Also, I need to do some filesystem operations like move or copy files. I'm not sure about the commands in Lisp, or if I'd even use streams or use a call to the OS. |
Nothing I have planned on, but it is easy enough to add. But many people will tell you that direct access to host system from script is bad thing (tm)  .
| brad wrote: | | Will I be able to send values of variables from the D program into the Lisp script and (somewhat) vice-versa? i.e. every script run will have access to certain D variables, as well as reporting errors from the script back to D. |
To get value to and from the "interpreter engine" is easy enough if you can convert it to text first. Here is an example, putting the value of foo into the "lisp world", modify it by one, and get it out in bar:
| Code: | int foo = 41;
eval(parse("(setq foo-in-lisp " ~ toString(foo) ~ ")"));
eval(parse("(setq foo-in-lisp (1+ foo-in-lisp))"));
int bar = eval(parse("foo-in-lisp")).intValue; |
But I have though of adding something nicer. As of now the addPredef() function is private for the dlisp.evalpredef module. I am thinking of doing it global so calling D-functions from Lisp can be easy to do from the outside. And at the same time add bindVariable() function. It basically takes a pointer and a type, and instead of storing the value internally it tells the "lisp world" to share the pointer with the outside. So the above example would become:
| Code: | int foo = 42;
bindVariable(&foo, "foo-in-lisp");
eval(parse("setq foo-in-lisp (1+ foo-in-lisp))"));
int bar = foo; |
Well not exactly the same, as foo would be overwritten, but I hope you get the idea. It is only a though, but unless anyone has a better idea, I will implement it. For int, real and char[] only, for lists and symbols you are better of using the Cell struct anyway. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
