fyi http://wiki.ros.org/roslisp
On Sunday, June 11, 2017 at 12:11:57 PM UTC+8, Ben Goertzel wrote: > > !!! Caveat: This post presents some speculative suggestions, not to be > interpreted > > as a definitive plan or mandate for work-to-be-done or anything like > > that; just as an interesting-looking directly for investigation > > > TL;DR — particularly for use of OpenCog in bioinformatics and other > > scientific-computing applications — but also for other applications like > > corpus linguistics where one deals with large datasets and wants to > > combine OpenCog with other command-line tools — it might be a good > > idea to replace or supplement our current Guile shell with a wrapping-up > > of OpenCog in Common Lisp … and in particular in the CLASP Common > > Lisp framework that Christian Schafmeister has developed. This would > > also have some other smaller side-benefits like letting us exploit the CL > > bindings for Jupiter Notebooks which would be cool for OpenCog > > tutorials; and making it easy to generate LISP bindings for ROS, thus > > avoiding the need to deal with ros-py for OpenCog robotics applications… > > > Basic reasons are: CLASP is efficient at handling large datasets and > > piping them from one place to another. It can also automatically > > generate bindings for C++ code, which could be used to auto-generate > > LISP bindings for ROS…. > > > … > > > So I met Christian Schafmeister at an AI-nanotech workshop in Palo > > Alto late last month, and I became aware of this really cool LISP > > environment for scientific computing that he's been developing... > > > https://github.com/drmeister/clasp > > > https://github.com/drmeister/cando > > > https://drmeister.wordpress.com/ > > > He has some strong arguments as to why this is a better way than R or > > python to get scientific computing done on large datasets…. > > > One thing he found is that in many of his computational chemistry > > analysis scripts, the bulk of compute time was getting taken up > > passing around datasets and results between different C++ programs, > > in R or python or whatever other glue language was being used… > > > Via using Common LISP compiled into LLVM, he found this could be > > worked around, because one could then script stuff in CL but have > > efficient garbage collection done via LLVM … > > > My speculative line of thinking now is that it might be interesting to > > > -- supplement or replace Guile with Clasp as a shell for working with > OpenCog > > > -- Integrate C++ bio-analytics tools into Clasp, in a similar way to > > what Schafmeister has been doing for chem-analytics tools > > > — Integrate R bio-analytics tools into Clasp as well, using the following > > LLVM compiler for R > > > https://github.com/duncantl/RLLVMCompile > > > https://arxiv.org/abs/1409.3144 > > > (although I note this compiler appears to still need a bit of work to be > fully > > generally usable…) > > > — Use the Clasp tools for automatically generating and updating LISP > bindings > > for C++ code, to auto-generating ROS bindings for CL > > > — Use the Jupyter Notebooks wrapping for CL to make Jupyter tutorials > > for OpenCog > > > (although, as a side note, integrating Guile with Jupyter Notebooks > > would also not be impossible ... it would just be a bunch of work, > > like any of this…) > > > … > > > I note, one can auto-convert Guile to Common Lisp using existing available > > scripts, though obviously this will require some hand-checking > afterwards... > > For OpenCog uses of Guile that are basically just “Guile wrapping > Atomese”, > > auto-conversion to CL would likely work fine. For cases where there is > > more actual programming done in Guile, more hand-adjustment of conversions > > to CL would probably be necessary.. > > > One could also emulate what Schafmeister did for C++, and auto-generate CL > > bindings for R packages. Although much of the time, the R packages are > just > > wrapping C++ functions; so in those cases, it might sometimes be better > just > > to bypass R and go straight from the underlying C++ functions to CL … > > > Another possibility would be to develop R-like syntax in a domain-specific > > language within CL … much as we’re now developing ChatScript-like > > syntax within Guile for authoring content for the Hanson robots… > > > … > > > Anyway it is not yet clear that the above would be a great idea, and > obviously > > it would be a lot of work to do…. However I think that, insofar as we can > find > > time to consider new development directions, this is worth thinking about… > > > — Ben > > > -- > Ben Goertzel, PhD > http://goertzel.org > > "I am God! I am nothing, I'm play, I am freedom, I am life. I am the > boundary, I am the peak." -- Alexander Scriabin > -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/5b2ee105-32bb-4a1f-b284-e3c15c555fc3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
