On Mar 16, 2010, at 8:47 AM, dmiles@users.sourceforge.net wrote:
This is because ABCL: Fixnum => int Bignum => BigInteger
ABCL does not have a 'long' type so it is normal workaround to produce a new 'long in your case.
So depends who is desiring: There is no real spec other than Allegro http://www.franz.com/support/documentation/8.0/doc/jlinker.htm#data=types-co... But Allegro spec here is lossy.. (meaning if you went from a Lisp Bignum->Java->Lisp.. the number would scaled back to Long.MAX_VALUE) So their spec is even more undesirable.
Agreed.
It would be possible that when the Bignum is within normal java long range the javaInstance() could return a java.lang.Long instead.
Does everyone think this would be better behavior than current ABCL and Allegro?
I'm thinking it would be. However, given that there is a workaround I wouldn't put it as high priority - more as a cleanup. -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
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:
This is because ABCL: Fixnum => int Bignum => BigInteger
ABCL does not have a 'long' type so it is normal workaround to produce a new 'long in your case.
So depends who is desiring: There is no real spec other than Allegro http://www.franz.com/support/documentation/8.0/doc/jlinker.htm#data=types-co... But Allegro spec here is lossy.. (meaning if you went from a Lisp Bignum->Java->Lisp.. the number would scaled back to Long.MAX_VALUE) So their spec is even more undesirable.
Agreed.
It would be possible that when the Bignum is within normal java long range the javaInstance() could return a java.lang.Long instead.
Does everyone think this would be better behavior than current ABCL and Allegro?
I'm thinking it would be. However, given that there is a workaround I wouldn't put it as high priority - more as a cleanup.
I think it would be, too. It's also arguably more efficient to manipulate Longs than BigIntegers. However, doing so requires that we also implement promotion, I mean, if a calculation result overflows longs it should be automatically upgraded to big integer. Java does not do anything like that, so I believe we must do it ourselves. Alessio
-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
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:
This is because ABCL: Fixnum => int Bignum => BigInteger
ABCL does not have a 'long' type so it is normal workaround to produce a new 'long in your case.
So depends who is desiring: There is no real spec other than Allegro http://www.franz.com/support/documentation/8.0/doc/jlinker.htm#data=types-co... But Allegro spec here is lossy.. (meaning if you went from a Lisp Bignum->Java->Lisp.. the number would scaled back to Long.MAX_VALUE) So their spec is even more undesirable.
Agreed.
It would be possible that when the Bignum is within normal java long range the javaInstance() could return a java.lang.Long instead.
Does everyone think this would be better behavior than current ABCL and Allegro?
I'm thinking it would be. However, given that there is a workaround I wouldn't put it as high priority - more as a cleanup.
I think it would be, too. It's also arguably more efficient to manipulate Longs than BigIntegers. However, doing so requires that we also implement promotion, I mean, if a calculation result overflows longs it should be automatically upgraded to big integer. Java does not do anything like that, so I believe we must do it ourselves.
Alessio
My suggestion above was for an easy work around is something like this in Bignum.java @Override public Object javaInstance() { long lng = value.longValue(); if (value.equals(BigInteger.valueOf(lng))) return Long.valueOf(lng); return value; } The java lisp I work on has bignum types that get demoted and promoted as needed. 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
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? Is your lisp ready for consumption? Does it make sense to combine efforts? I'm intrigued as I see it's associated with LarKC, and mostly I use ABCL for projects related to ontology and semweb. -Alan
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
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
Ok LarKC now supports full Common Lisp now. (ready for consumption!) Now passes LarKC UnitTest (and runs LarKC) and ANSI-TESTs Although I am checking in at http://larkc.svn.sourceforge.net/viewvc/larkc/branches/LarKC_CommonLisp_Exte... as well.. I am trying to pace myself Though I'd consume it with hg clone https://logicmoo-invoke-interface.googlecode.com/hg/ larkc-platform Build with ant -f lisp-build.xml run with java -jar lib/larkc-platform.jar Armed Bear Common Lisp 0.20.0-dev Java 1.6.0_14 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 8.531 seconds. LISP_HOME = C:\development\logicmoo-invoke-interface\bin\com\cyc\tool\subl\jrtl\nativeCode\commonLisp\ Startup completed in 13.297 seconds. Type ":help" for a list of available commands. CL-USER(1): The number long vs bigint - the reason for the email discussion can be tested. On Wed, Mar 17, 2010 at 3:38 AM, dmiles@users.sourceforge.net <logicmoo@gmail.com> wrote:
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
participants (3)
-
Alan Ruttenberg -
Alessio Stalla -
dmiles＠users.sourceforge.net