On Tue, Mar 16, 2010 at 10:25 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Wed, Mar 17, 2010 at 12:34 AM, dmiles@users.sourceforge.net logicmoo@gmail.com wrote:
On Tue, Mar 16, 2010 at 8:57 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Mar 16, 2010 at 4:41 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Mar 16, 2010, at 8:47 AM, dmiles@users.sourceforge.net wrote:
The java lisp I work on has bignum types that get demoted and promoted as needed.
So, this begs the question: What is the difference between your lisp and ABCL?
ABCL is CommonLisp LarKC is SubLisp written to support the Cyc® application, allowing it to run both under Lisp environments and as a Java application generated by a SubL-to-Java translator.
It was 4 years ago as I was able to complete a highly successful merge the two code bases of ABCL and the JavaLisp that LarKC uses. It ran both languages equally well (since SubLisp is compatible with common lisp when used from its own lisp package).. And passed at least the same ANSI-TESTs At that time, ABCL was only passing 90 some ansi-tests, LarKC project hadn't started, and the JavaLisp's development was secret.
Code-wise the major difference was I took parts of the ABCL compiler/interpreter to make it targets the JavaLisp's lisp object system which is based on java interfaces instead of ABCLs current non-interface representations. For instance you could take any working java source (like JENA or DROOLS).. and add the lisp interfaces Vector, Cons, Symbol, HashTable, StructureObject etc, as long as you add whatever methods they contracted, Lisp could not tell the difference between it and something it had produced on its own. This often allowed zero "re-representation" of data between java and lisp. (This also lets generator tools like beanshell/jruby/jython/etc to implement Mixins with any superclass or implementation they please)
Another difference is most all symbol functions are converted to final static methods... and static methods just call static methods.. calling more static method (when this is undesirable the user uses "define-public" which means its #'funcallable outside of the java file is in).. this made it so not as many java must be "new"ed while the lisp application is running.
Is your lisp ready for consumption?
The merge of ABCL took four months of the following routine:
1) Balance plates for 10-16 hours - run the ansi-tests watch them all smash.. start all over the next day. 2) Balance plates for one hour . watch the ansi-tests for 5 minutes.. repeat 15 more times (only 10 start overs!).. 3) next day only lost 3 hours! 4) next day lost no hours. 5) next day get brave and improve something difficult - failure - lose 1-3 whole days of life 6) next day only lose 5 hours 7) smile/talk to wife/family for 15 minutes 8) get brave and improve something difficult - success! 9) goto 1 - repeat this loop 15-20 times
So since then, the original JavaLisp (with a few bits an pieces from the above merge in it) has become the central platform of LarKC.
The new ABCL team has improved ABCL in some great ways (ansi-tests went from ~90 failures to ~28 failures).
So I have developed amnesia and starting over the with the LarKC project doing the same merge because this time it is open sourced. Integrating those same features from above and reusing the ABCL's compiler and current improvements and incorporating new ones when they happen.
With lessons learned for this time around... It should only take 1-2 months to complete full ansi lisp compatibility again
Does it make sense to combine efforts?
Probably, but I brought this up to ABCL a few times in the last 16 months.. They have accepted some ansi-test fixes but I don't think they like the redesign of ABCL into a something that is an unknown quantity for them. Some parts of the new design/merge to ABCL were very brutal. (and required the above work loop)
I'm intrigued as I see it's associated with LarKC, and mostly I use ABCL for projects related to ontology and semweb.
-Alan
Indeed as LarKC is an application framework for writing semweb apps. My *goal* is to make it easier for people to write LarKC plug-ins. If they want to write in lispy language currently means they must learn SubLisp and then be willing to write in it afterwards. To anyone that submits to doing this, I think they will get more out of the ability to use Common Lisp instead. I'd like LarKC module authors to be able to leverage tools like Pellet in the middle of their code. They currently can plug in Pellet into the pipeline as module..just as LSW could be another pipeline module. (Pipeline modules can be called by each other).
-Doug
SubLFixnum -> int SubLLongBignum -> long SubLBigIntBignum -> BigInteger
The code is at http://larkc.svn.sourceforge.net/viewvc/larkc/branches/LarKC_CommonLisp_Exte...
-Alan
On Mon, Mar 15, 2010 at 11:47 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Am I right to observe that abcl coerces any number > fixnum size to bigint? I'm having trouble calling a java method that takes a long. I seem to have worked around it calling the method with (new 'long "9223372036854775807") rather than 9223372036854775807 .
Is this the desired behavior?
-Alan
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel