[armedbear-devel] long

Wed Mar 17 10:38:28 UTC 2010

On Tue, Mar 16, 2010 at 10:25 PM, Alan Ruttenberg
<alanruttenberg at gmail.com> wrote:
> On Wed, Mar 17, 2010 at 12:34 AM, dmiles at users.sourceforge.net
> <logicmoo at gmail.com> wrote:
>> On Tue, Mar 16, 2010 at 8:57 AM, Alessio Stalla <alessiostalla at gmail.com> wrote:
>>> On Tue, Mar 16, 2010 at 4:41 PM, Alan Ruttenberg
>>> <alanruttenberg at gmail.com> wrote:
>>>>
>>>> On Mar 16, 2010, at 8:47 AM, dmiles at 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_Extensions/platform/src/com/cyc/tool/subl/jrtl/nativeCode/type/number/
>>
>>
>>
>>
>>
>>
>>>
>>>> -Alan
>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 15, 2010 at 11:47 PM, Alan Ruttenberg
>>>>> <alanruttenberg at 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 at common-lisp.net
>>>>>> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> armedbear-devel mailing list
>>>> armedbear-devel at common-lisp.net
>>>> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>>>>
>>>
>>
>