Adding new lisp (ABCL) support

[Qian Yun]

I'd like to add new lisp support for FriCAS soon, starting with ABCL.

First, ABCL almost supports fricas0, I have identified 2 bugs and they
are fixed upstream (not merged yet, should be available next release).
So I think it is time to add ABCL support in FriCAS repo.

https://github.com/armedbear/abcl/issues/500
https://github.com/armedbear/abcl/issues/504

Second, to add ABCL support for FriCAS, I guess it is similar to add
support for POPLOG? So basically adding "#+abcl" near "#+poplog".

Third, if so, I'd like to clean it up a bit before adding ABCL support:
how about grouping those implementation specific stuff into a single
place/file?

- Qian

[Kurt Pagani]

Hi Qian

I strongly encourage this endeavor :)
ABCL is quite useful when speed is not the top priority. Fricas in a .jar would
be really attractive.

I reported a bug 5 years ago ... but I'm not up to date at the moment.
https://armedbear-devel.common-lisp.narkive.com/Yh8vNHwi/fricas-w-abcl

It works fine with Maxima, especially in combination with the Java based jEdit
editor. Would be great to have something alike for fricas.

https://github.com/nilqed/abcl_maxima
https://github.com/nilqed/abcl-j

[Grégory Vanuxem]

I wonder always : a link to ABCL?

Am not a fan of « Google is your friend » but yes I can find some information.

But, for sure, it’s a good idea and can ameliorate the stuff.

__

Greg

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/87df413f-02a0-76ca-ce0c-9e27c36e1507%40gmail.com.

[Kurt Pagani]

This is the official one:
https://abcl.org/

Meta: it is (very briefly) mentioned in https://en.wikipedia.org/wiki/Common_Lisp

"""
Freely redistributable implementations
Armed Bear Common Lisp (ABCL)
A CL implementation that runs on the Java Virtual Machine.[23] It includes a
compiler to Java byte code, and allows access to Java libraries from CL. It was
formerly just a component of the Armed Bear J Editor.

[Qian Yun]

On 9/19/22 23:31, Kurt Pagani wrote:
> Hi Qian
>
> I strongly encourage this endeavor :)
> ABCL is quite useful when speed is not the top priority. Fricas in a .jar would
> be really attractive.
>
> I reported a bug 5 years ago ... but I'm not up to date at the moment.
> https://armedbear-devel.common-lisp.narkive.com/Yh8vNHwi/fricas-w-abcl

Yes, the first issue you mentioned is the same as
https://github.com/armedbear/abcl/issues/500
I didn't meet the second issue, probably fixed in ABCL already.

- Qian

[Waldek Hebisch]

On Mon, Sep 19, 2022 at 10:24:00PM +0800, Qian Yun wrote:
> I'd like to add new lisp support for FriCAS soon, starting with ABCL.
>
> First, ABCL almost supports fricas0, I have identified 2 bugs and they
> are fixed upstream (not merged yet, should be available next release).
> So I think it is time to add ABCL support in FriCAS repo.
>
> https://github.com/armedbear/abcl/issues/500
> https://github.com/armedbear/abcl/issues/504
>
> Second, to add ABCL support for FriCAS, I guess it is similar to add
> support for POPLOG? So basically adding "#+abcl" near "#+poplog".

Well, adding "#+abcl" in appropriate places (which may be similar
to #+poplog).

> Third, if so, I'd like to clean it up a bit before adding ABCL support:
> how about grouping those implementation specific stuff into a single
> place/file?

I am not sure what you mean. Let me say a bit about logic that
I use when I place Lisp code somewhere. First, lisp/primitives.lisp
is for use from code generared by Spad compiler. In ideal world
rest of Lisp code would be in lisp/fricas-lisp.lisp. However,
for GCL package construction must be in separate file, so we
get lisp/fricas-package.lisp. GMP support is specific to sbcl
and Clozure CL, it is simpler and more logical to keep in separate
file than to use conditionals. That explains layout of src/lisp
subdirectory. There are also Lisp files in src/interp. Those
I consider legacy files and hope that some day they most of
them will go away. foam_l.lisp is Aldor specific (needed to
interface with Aldor). interp-proclaims.lisp is really only present
because it could be used to optimize calls when building FriCAS
on top of GCL. IIUC with newer GCL this is no longer needed or
useful. So the only useful thing done by interp-proclaims.lisp
is to set GCL compilation options (we were not able to use
default GCL setting as in such case build failed).

vmlisp.lisp contains mostly compatibility code with old
IBM Lisp dialect. Use of several constructs there should
be removed (replaced by simpler code), so some parts will
be deleted. Some code in other files really does not need
to be in Lisp, some is candiate for replacement by alternative
code. I keep it where it is mostly to make history clearer
(history helps when I want to reverse-engineer why code
was written in given way).

There are also build details: Boot translator depends on
src/lisp but I belive that it is independent from src/interp.

Now, concerning implementation support. There are some
implementation-specific functions that we need, they are
mostly in fricas-lisp.lisp. Having them together in single
file helps, as we can share parts between similar implementation.
Also, parts of fricas-lisp.lisp are common to all implementations,
keeping this together make it easier to understand the code.

Conditional code in other files is really imperfection of
the world: we need conditionals in primitives.lisp to get
better performance. And there are irregularities in other
places, moving affected code to src/lisp would split logic
making it harder to understand. Moving all Lisp code to src/lisp
would IMO move too much code.

BTW: In our code we have 3 subtly different "general-purpose"
Lisp sorting functions. IMO we should really have typed
data and use type-specific sort functions, so it would be
good to replace or remove them. To put it differenty: all
uses of those are potential bugs. We should look at the
uses, discover what is sorted and decide if sorting is
needed at all. And if sorting is needed we should
decide which _specific_ function to call. To explain
more, those function handle/handled some things that
FriCAS never uses and to do this had dependency on
obscure implementation details. Most problematic part
is now removed but I think that this code could be
cleaned up much more and made much simpler.

--
Waldek Hebisch

[Qian Yun]

On 9/20/22 10:17, Waldek Hebisch wrote:
> BTW: In our code we have 3 subtly different "general-purpose"
> Lisp sorting functions.

I guess you are referring to the "*GREATERP" functions.

> IMO we should really have typed
> data and use type-specific sort functions, so it would be
> good to replace or remove them.

But, when GGREATERP is used in Factored Domain, it is under
condition that the domain does not have Comparable.

> To put it differenty: all
> uses of those are potential bugs. We should look at the
> uses, discover what is sorted and decide if sorting is
> needed at all.

So in the above case, sorting is not needed. We should
use something like "unordered set" to represent it.

But current "Set(S)" when "S does not have OrderedSet"
is incomplete. Also it is questionable that whether its Rep
FlexibleArray is suitable in this case. May be using
a immutable data structure that allows sharing is better.
Just like what we did in MonoidRing.

- Qian

[Grégory Vanuxem]

Thanks! That seems good and very portable (use of Java's)

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/c1a041f1-b501-c3bd-8102-11d9ed5d2dd8%40gmail.com.

[Waldek Hebisch]

On Wed, Sep 21, 2022 at 09:09:43PM +0800, Qian Yun wrote:
>
>
> On 9/20/22 10:17, Waldek Hebisch wrote:
> >BTW: In our code we have 3 subtly different "general-purpose"
> >Lisp sorting functions.
>
> I guess you are referring to the "*GREATERP" functions.

Yes, and ?ORDER.

> >IMO we should really have typed
> >data and use type-specific sort functions, so it would be
> >good to replace or remove them.
>
> But, when GGREATERP is used in Factored Domain, it is under
> condition that the domain does not have Comparable.
>
> >To put it differenty: all
> >uses of those are potential bugs. We should look at the
> >uses, discover what is sorted and decide if sorting is
> >needed at all.
>
> So in the above case, sorting is not needed. We should
> use something like "unordered set" to represent it.

Yes.

> But current "Set(S)" when "S does not have OrderedSet"
> is incomplete. Also it is questionable that whether its Rep
> FlexibleArray is suitable in this case. May be using
> a immutable data structure that allows sharing is better.
> Just like what we did in MonoidRing.

IMO Factored is too general for really efficient implementation.
Of course, you (or some other person) can prove me wrong.

But ATM main use of Factored is as interface to factorizers.
And in this case Factored is actually clumsy. Namely, what
we need is factorization, where order of factors matters.
Internally factorizers use lists to maintain order, it would
make sense to have also offcial interaces that use lists.

Simlarly, is other cases when at first one could think about
factored it is likely that more specialized representation
would be better.

--
Waldek Hebisch

[Qian Yun]

On 9/25/22 23:54, Waldek Hebisch wrote:
>> But current "Set(S)" when "S does not have OrderedSet"
>> is incomplete. Also it is questionable that whether its Rep
>> FlexibleArray is suitable in this case. May be using
>> a immutable data structure that allows sharing is better.
>> Just like what we did in MonoidRing.
>
> IMO Factored is too general for really efficient implementation.
> Of course, you (or some other person) can prove me wrong.
>
> But ATM main use of Factored is as interface to factorizers.
> And in this case Factored is actually clumsy. Namely, what
> we need is factorization, where order of factors matters.

Can you clarify more about this? I had the same concern before:
is there a meaningful domain that does not have Comparable?
Anyway, we still need to handle this (corner) case to remove
*GREATERP from SPAD.

> Internally factorizers use lists to maintain order, it would
> make sense to have also offcial interaces that use lists.
>
> Simlarly, is other cases when at first one could think about
> factored it is likely that more specialized representation
> would be better.
>

To explain my idea more clearly, I'd like to add a new Package
(instead of Domain), that provides functions on "unordered set
that is represented as list", example signatures are:

EQFUN ==> (R, R) -> Boolean
-- All functions are required to pass a equality function with
-- this signature, because R can be Record(...).

RESOLVEFUN ==> (R, R) -> Union("failed", R)
-- when adding a new element to the set, this function determines
-- how to treat duplicated elements: whether to drop one, or drop
-- both (if they cancel), or add a new element computed from the two.

construct: (List R, EQFUN, RESOLVEFUN) -> List R
-- construct unordered set from List R

= : (List R, List R, EQFUN) -> Boolean
-- check if two unordered sets have the same elements

concat : (R, List R, EQFUN, RESOLVEFUN) -> List R
-- add a new element to the set

concat : (List R, List R, EQFUN, RESOLVEFUN) -> List R
-- computes the "union" of two sets, equal elements are handled by
-- RESOLVEFUN

- Qian