Renaming $ to %

[Ralf Hemmecke]

Hi Peter,

Waldek recently renamed $ to % in the FriCAS code.
Unfortunately, Aldor does now no longer find the respective functions at
runtime. (That is my suspicion.)

See thread
https://groups.google.com/g/fricas-devel/c/rB-7qgL5Rvk/m/rm5xyiwmAQAJ

I've found several places where the old $ is still mentioned in Aldor code.

https://github.com/aldorlang/aldor/blob/master/aldor/aldor/src/test/test_foam.c#L180

Unfortunately, I am unable to find exactly the place where things go wrong.

Ralf

[Peter Broadbery]

Hi Ralf,

Thanks for the reminder on this - I've been meaning to look at it, but
'stuff' has got in the way a few times.
Looking at the thread (and nothing else), one quick thing to try is to
replace the removed line with
symbol
typeform = '% => '%

Although that might be covered in another clause.

As an aside, I would like to rework the aldor runtime to be more
compatible with fricas - ideally the compiler should understand .NRLIB
files, and there should be no need to have an aldor specific build
step in fricas. Unfortunately, it's a big project, I don't think it's
a one-person job.

Peter

> --
> You received this message because you are subscribed to the Google Groups "aldor-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to aldor-devel...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/aldor-devel/3a1d0cee-4542-544f-1c4f-c91f9beab153%40hemmecke.de.

[Ralf Hemmecke]

On 13.05.23 17:29, Peter Broadbery wrote:
> Looking at the thread (and nothing else), one quick thing to try is to
> replace the removed line with
> symbol
> typeform = '% => '%

This has already been done.
Note that there were two proplems.
1) libfricas.al could not be built
2) sieve.as compiles but does not run.

(1) has been solved by committing

typeform = '% => '%

to fricas.

Now the problem is (2).
Waldek thinks
https://groups.google.com/g/fricas-devel/c/rB-7qgL5Rvk/m/GrZMq5mXBQAJ
that it is an incompatibility of the hash codes.

Unfortunately, I do not know whether this is really the case not do I
know where to look for this incompatibility.

> As an aside, I would like to rework the aldor runtime to be more
> compatible with fricas - ideally the compiler should understand .NRLIB
> files, and there should be no need to have an aldor specific build
> step in fricas. Unfortunately, it's a big project, I don't think it's
> a one-person job.

If you tell me where I could help/look at. I would be happy to help.
Of course, time is an issue, but usually two people are faster (even if
it means that one person only serves as a mild contributor -- but it's
more fun).

Best regards,
Ralf

[Peter Broadbery]

Hi,

Thanks for the extra details; I'll start digging into it.

I think the runtime improvements plan looks like:
-- Write something in C that can ingest .NRLIB/index.KAF files; I have
this in aldor; the 'C' version won't be too different.
-- Knit the fricas generated .KAF files into an object similar to the
internal 'Library' datastructure in the compiler
-- Language level: aldor probably wants support for something like
'import from Foreign(Fricas)' to trigger the process

I guess the first part is easy enough - the aldor compiler can deal
with lisp-like data-structures, and so should be able to read .KAF
files.
(Aldor code is here:
https://github.com/pbroadbery/fricas-aldor-types.git - it's not
production quality, but is a proof of concept. A starting point is
axiomlib.as)
The final part is just arguing about syntax that can be hidden by
'#include', and some internal plumbing.

The second part is to interpret the .KAF files. I'll try a brief
summary - names in parentheses are Aldor compiler data structures

The fricas library can be represented as an Aldor library object -
possibly a new one. There's a (Library) type, but it looks to be a
bit too low-level.
Each fricas type or constructor in that library can be mapped to a
symbol meaning (Syme) in the aldor compiler; a symbol meaning has a
type (TForm).
This type can be obtained by taking the fricas type and applying a
bunch of rules for dealing with
- categories
- constructors
- domains
- function signatures
- conditionals
- mappings
- dependent types
The idea would be recursive descent, stealing ideas from as.boot as
needed. Note that a type is a recursive object - made up of types and
symbol meanings already created.
It might be best to do this in a number of stages - create a
dictionary for the full library, then expand the dictionary replacing
names with references.

Peter

> --
> You received this message because you are subscribed to the Google Groups "aldor-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to aldor-devel...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/aldor-devel/393c7cf8-970a-e730-b8ba-696ca302d049%40hemmecke.org.

[Peter Broadbery]

Hi,

The fricas patch below is enough for sieve.as. There might still be
some references to '$' that ought to be '%'. So, I'll make another
pass later.
As an aside, it would be good if dollar was not used as a variable
name. 'self' might be a good replacement.

Peter

diff --git a/src/interp/interop.boot b/src/interp/interop.boot
index 1944bff8..a2f82bda 100644
--- a/src/interp/interop.boot
+++ b/src/interp/interop.boot
@@ -290,7 +290,7 @@ oldAxiomDomainLookupExport _
EQL(op, $hashSeg) => op := 'SEGMENT
constant := nil
if hashCode? sig and self and EQL(sig, getDomainHash self) then
- sig := '($)
+ sig := '(%)
constant := true
val :=
skipdefaults =>
@@ -500,7 +502,8 @@ hashNewLookupInTable(op,sig,dollar,[domain,opvec],flag) ==
VECP dollar => hashType(dollar.0,0)
hashType(dollar,0)
if hashCode? sig and EQL(sig, hashPercent) then
- sig := hashType('(Mapping $), hashPercent)
+ sig := hashType('(Mapping %), hashPercent)
dollar = nil => systemError()
$lookupDefaults = true =>
-- lookup first in my cats

[Ralf Hemmecke]

Thank you, Peter, for investing your time into this.

Since this stuff concerns FriCAS code, I crosspost to fricas-devel.

Obviously, Waldek missed some places while renaming $ to %.

In my branch https://github.com/hemmecke/fricas/tree/dollar-percent

https://github.com/hemmecke/fricas/commit/e7c4cca1aaa3e24951a9b826ffc0fdf9ab18586b.patch

I have collected more suspicious places (where I have replaced $ by % --
maybe not all correct, but should be considered).

Ralf

[Ralf Hemmecke]

Thank you, Waldek, for the quick reaction.

On 15.05.23 03:59, Waldek Hebisch wrote:

> On Mon, May 15, 2023 at 12:47:37AM +0200, Ralf Hemmecke wrote:
>> Thank you, Peter, for investing your time into this.
>>
>> Since this stuff concerns FriCAS code, I crosspost to fricas-devel.
>>
>> Obviously, Waldek missed some places while renaming $ to %.
>>
>> In my branch https://github.com/hemmecke/fricas/tree/dollar-percent
>>
>> https://github.com/hemmecke/fricas/commit/e7c4cca1aaa3e24951a9b826ffc0fdf9ab18586b.patch
>>
>> I have collected more suspicious places (where I have replaced $ by % --
>> maybe not all correct, but should be considered).
>

> Quick comment about changes:
>
> 1) $$ is different than $, no need for replacement.
> Similarly $$$ is different than $ and $$, no need for replacement.

I wasn't sure, but AFAICS, Aldor also uses %% in categories. Maybe $$
and $$$ are future candidates for replacements.

> So changes to br-data.boot, compiler.boot, define.boot, modemap.boot,
> nruncomp.boot, nrunfast.boot, nrungo.boot, nrunopt.boot,
> i-map.boot, i-spec1.boot, i-spec2.boot, third and fifth
> change to interop.boot, are not needed
>
> 2) in format.boot second change is wrong, we want $ here.
> AFAICS formatOpConstant is unused, so better remove it.
> Third change looks good.
> Similarly, first change to i-output.boot is wrong (second is good).
>
> 3) I am not sure about change to trace.boot, but it is likely to
> be wrong.
>
> 4) For Aldor you probably only need changes to as.boot and 3 of the
> changes to interop.boot.

In fact, I am not sure whether as.boot is used at all. For the
FriCAS-Aldor interface ax.boot is used, but what as.boot is needed for,
I have no clue.

I'll try to prepare a proper (tested) pull-request for "$ --> % renaming".

Ralf