Re: [fricas-devel] New release

[Peter Broadbery]

On Mon, 10 Jun 2024, 21:23 Waldek Hebisch,  wrote:

> On Mon, Jun 10, 2024 at 09:47:53PM +0200, Ralf Hemmecke wrote:
> > On 6/10/24 20:34, Waldek Hebisch wrote:
> > > I would like to do new release in June.  I would like to include

> > Qian work on HyperDoc and the FriCAS book, that is main thing
> > > that needs to be resolved before release.
> >
> > I am looking at Qian's stuff.
> >
> > Unfortunately, the new release will break the FriCAS-Aldor interface if
> > nothing is done about it. I'm not really happy about that.
>
> For release we can revert the change to algebra, ATM nothing depends
> on this change.  But this is important change, and allows better
> structuring of integration code.  So either we allow Aldor to block
> developement of algebra (and I do not want to do this) or somebody
> (and I am affraid only Peter can do this) changes Aldor to remove
> current limitation or interface will be broken in the future


My plan is to look at this in the next few weeks.  Based on some
preliminary work, it looks solvable, as there are similar constructs in
other places.  I'd rather not be a bottleneck, so if anyone wants to help
with either this or to help make a start on a newer (aldor/spad based)
compiler, it would be welcome.

Peter






>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN94TxSCzF36Y-CEH0%3DZHoU3w0GNinN5Vs%2BnSyP0gRannA%40mail.gmail.com.

Re: [fricas-devel] Instructions for building with Aldor

[Peter Broadbery]

On Tue, 12 Dec 2023 at 07:08, Ralf Hemmecke  wrote:
>
> > For the user experience side of things, writing a GUI is hard. ...
> > In this vein, I've picked intellij as a starting point.  It does
> > around 80% of what I want - ie. host projects, compile on the fly,
> > and jump between definitions, documentation and usages of names.
> > Pretty much hyperdoc embedded in an editing UI.
>
> Peter, in install.rst I have already included some text to jFriCAS and
> the emacs frimacs-mode, I think it would be good to also provide some
> pointers to your intellij GUI so that it becomes a little more visible.
> Can you give a pointer to your installation instructions for the
> intellij aldor+fricas mode?
>

Hi Ralf,

Instructions are here: https://github.com/pbroadbery/aldor-idea-plugin
Latest release is here:
https://github.com/pbroadbery/aldor-idea-plugin/releases/tag/release-1.3.2

It's due an update, as the underlying framework has moved on a little
over the last couple of years. That said, it ought to work.
I expect I'll have time to look at rolling a new version over the holidays.

Peter

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN9gJmTh6fQZ0QcfJ7Ez7Y_VO_jCvOW2sQaEh0pP82UjyQ%40mail.gmail.com.

Re: [fricas-devel] Instructions for building with Aldor

[Peter Broadbery]

On Mon, 11 Dec 2023 at 03:35, Waldek Hebisch  wrote:
>
> On Sat, Dec 09, 2023 at 08:26:57PM +, Peter Broadbery wrote:
> > On Sat, 9 Dec 2023 at 16:47, Ralf Hemmecke  wrote:
> > >
> > > Hi Peter,
> > >
> > > > I think the reference to 'Aldor folks' above is optimistic - I'd like
> > > > to get a few more people helping with development (this is an
> > > > optimistic plea for interested parties, to get involved btw).
> > >
> > > Yes, would be supergood to have more developers, but it's somewhat of a
> > > hen-egg-problem. Nobody can get interested in Aldor if he/she doesn't
> > > know about the advantages of Aldor. I'm afraid that FriCAS will not help
> > > much. I try to have an eye on the generation of libfricas.al so that
> > > Aldor is at least usable together with FriCAS, but what is needed is a
> > > kind of killer application that shows why Aldor is good. Now many people
> > > jump on the Julia train simply because they see faster development
> > > there. It's hard to say how one can best advertise Aldor to other
> > > compiler developers.
> > >
> >
> > Yes - it is hard to sell without a strong application; unfortunately I
> > don't have a strong sense of what a
> > killer application would look like.  I suspect that the algebra
> > library contains several
> > good starting points for anyone wishing to push it further.
>
> I am affraid that it works differently: you or somebody else have
> a cool idea and use Aldor to implement it.  There are some
> necessery (but certainly not sufficient) condition for this.
> First, Aldor must be good language to solve given problem.
> Now, in abstract Aldor language is good.  But when doing something
> new there is a lot of experimentation and for this it matters
> how smooth is developement cycle.  First, one needs fast compilation
> and interactive testing.  Clear compiler diagnostics help.
> IDE and debugger can make a difference.
>

> Next, there is need for libraries.  For math Aldor library is
> resonable start, but is limited.  FriCAS library gives more
> coverage, so symbolic math is resonably covered.  But symbolic
> math is rather narrow programming domain and I think that
> Aldor alone here have little chance.  In more general context
> people want database access, web framework, GUI toolkit etc.
> For heavy computations people want multithreading and there
> are tricky issues of parallel garbage collection.
>
> I am not saying that language must have all of the above,
> but need enough for a succesful application.
>
> Also, for other people to join Aldor must be easy to build
> and work on their machines.  Which means either being very
> careful to use portable constructs or have a build/test
> farm of machines (possibly virtual) running several different
> configurations.
>
> In different spirit: fact that Aldor is not written in Aldor
> also is a disadvantage.  You need a person that is comfortable
> writing C and likes Aldor, and persons liking Aldor are
> unlikely to want to develop in C.  Also, given that Aldor
> developers used C, Aldor users may have doubts about suitablity
> of Aldor for serious projects.  Of course, it is probably too
> late to change this...
>

You make a lot of good points - aldor is steadily improving as both a
code base and a development environment - I find it ok for the projects
I have, but there is space to do more to improve it.  For the user experience
side of things, writing a GUI is hard.  Common practice is to steal
someone else's.
In this vein, I've picked intellij as a starting point.  It does
around 80% of what I want
 - ie. host projects, compile on the fly, and jump between
definitions, documentation
and usages of names.  Pretty much hyperdoc embedded in an editing UI.
That said, other
people want different things (or only use the One True Editor).

The java and lisp ports can provide database, web and GUI -
re-inventing those wheels would be
time consuming otherwise.

For the 'C' side of things, the Aldor code base is quite friendly -
there are no issues with
memory management (it assumes a garbage collector), and it's largely
written in a very clear manner.
As far as self-hosting goes, I have usefully experimented with writing
the type system in aldor
Rewriting the parser, codegen and optimisation passes would just take time.

I'll put a bit more effort into the build environment - I guess a
larger farm of agents would be handy.

Peter

> --
>   Waldek Hebisch
>
> --
> You received this message because you are subscribed to the Google Groups 
> "FriCAS - computer algeb

Re: [fricas-devel] Instructions for building with Aldor

[Peter Broadbery]

On Sat, 9 Dec 2023 at 16:47, Ralf Hemmecke  wrote:
>
> Hi Peter,
>
> > I think the reference to 'Aldor folks' above is optimistic - I'd like
> > to get a few more people helping with development (this is an
> > optimistic plea for interested parties, to get involved btw).
>
> Yes, would be supergood to have more developers, but it's somewhat of a
> hen-egg-problem. Nobody can get interested in Aldor if he/she doesn't
> know about the advantages of Aldor. I'm afraid that FriCAS will not help
> much. I try to have an eye on the generation of libfricas.al so that
> Aldor is at least usable together with FriCAS, but what is needed is a
> kind of killer application that shows why Aldor is good. Now many people
> jump on the Julia train simply because they see faster development
> there. It's hard to say how one can best advertise Aldor to other
> compiler developers.
>

Yes - it is hard to sell without a strong application; unfortunately I
don't have a strong sense of what a
killer application would look like.  I suspect that the algebra
library contains several
good starting points for anyone wishing to push it further.

>
> Thank you for still keeping Aldor alive,
> Actually I wonder where you are heading too. I see several commits
> connected to Java. Do you aim at a .as --> .java translation?
>

The .as -> java thing is pretty much done (excluding fully generic
generics/type constructors).  It is quite possible
to call java methods from aldor and vice-versa. My other side project
of an Aldor/Fricas code editor uses it quite intensely.
Maybe exposing the algebra library as java would be an interesting
project.. I've yet to try it.

As for where I'm heading with Aldor - my todo list is: (in increasing
order of vagueness)
- Improvements to way C functions are called, fixing compiler warnings
- Re-implementing generators, thus improving code generation
- Java port performance analysis and improvements
- Better Fricas interop (the libfricas.al thing is, I think, avoidable)
- Type inference improvements to allow undeclared parameters and locals
But this list may change over time.

Peter

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN_DU_Qm8Bs2k-AWaqygvqN57MUK80540-ejGDtywtdAxA%40mail.gmail.com.

Re: [fricas-devel] Instructions for building with Aldor

[Peter Broadbery]

On Sat, 9 Dec 2023 at 01:55, Waldek Hebisch  wrote:
>
> On Sat, Dec 09, 2023 at 01:55:34AM +0100, Ralf Hemmecke wrote:
> > > BTW: When installing Aldor in the wiki I updated:
> > >
> > > http://wiki.fricas.org/AldorForFriCAS
> > >
> > > so that it contains info needed to install Aldor on wiki machine.
> > > In particular I did not see _working_ instructions for building
> > > Aldor itself in single place (there were hints in emails from
> > > Peter).
> >
> > Oh, up to now I thought that Aldor build instructions is something that the
> > Aldor project is responsible for.
>
> Well, it should be done by Aldor folks.  But to build Aldor
> interface one needs to get (that is build) Aldor first and at
> least for wiki the simplest way was to add instructions to
> page above.
>

> > But I agree, the need for "--disable-maintainer-mode" should be more> > 
> > prominent in the Aldor build instructions or rather should be the default.
> > There seems to be a problem with the standard way.
> >
> > [git checkout...]
> > cd $ALDOR/aldor
> > ./autogen.sh
> > cd $BUILDDIR
> > $ALDOR/aldor/configure
> > make -j8
> >
> > gives
> >
> > libtool: Version mismatch error.  This is libtool 2.4.7 Debian-2.4.7-4, but
> > the
> > libtool: definition of this LT_INIT comes from libtool 2.4.6.
> > libtool: You should recreate aclocal.m4 with macros from libtool 2.4.7
> > Debian-2.4.7-4
> > libtool: and run autoconf again.
> >
> > Maybe autogen.sh must be updated to regenerate everything properly for the
> > standard --enable-maintainer-mode.
>
> AFAIK in maintainer mode autotools do not tolerate any version
> differences: maintainers are supposed to use exactly the same
> autotools version.  I mean that upgrade/downgrade may require
> modifying code which should be trivial for person familiar
> with build system, that is maintainer.  But in practice IIUC projects
> with complicated build systems tend to stay with single version
> and then there is real work to upgrade.  I affraid that having
> users to deal with maintainer mode is too problematic.
>

I think the reference to 'Aldor folks' above is optimistic - I'd like
to get a few more
people helping with development (this is an optimistic plea for
interested parties, to get involved btw).
Anyway, I hadn't noted the impact of maintainer mode.  If it's easier
to work without it, then it's not a problem to drop it from the github
configure.ac

Peter


Peter


> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/ZXPJDyEqIn8y7BVL%40fricas.org.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN8KoYPWdGpvrGBYmV1uUpQHeq13U0A64ZgJ6hGPqs%3D0Hw%40mail.gmail.com.

Re: [fricas-devel] Re: Syntax highlighting spad, input and aldor files

[Peter Broadbery]

There is a lexer and parser in the intellij plugin code. I think these
could be used as a starting point..  lexing (ie.deciding on what is an id,
number or keyword) is relatively easy, mostly lex regexps with some special
cases.

The hard part is accounting for indented blocks in the grammar.. there is
code for that in the plugin (Linearise.java), based on the aldor and Fricas
code bases. Be warned that it isn't pretty, with are a lot of edge cases.
To be expected given the problem domain, I guess.

At the grammar level the spad and aldor languages are pretty similar and
can be dealt with together, but there's enough differences to force some
special cases. The plugin covers most of this, but I'd have to remind
myself of the details. It covers about 98% if both code bases.

Happy to help with any questions you have.

Peter

On Wed, 26 Jul 2023, 00:56 Grégory Vanuxem,  wrote:

> II guess I have to start with src/boot/typrops.boot.
> But if you know some other sources, for example for Aldor or
> differences between the Spad language and the interpreter language,
> that would. great.
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZEGn-K3P38ZYScv-6kBSEFA_HyEnfbSb0pnwviKRyCYQ%40mail.gmail.com
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN8xSz5a6%2BZ7FHt2c1F81o2W1xRyAOekLBOrCdbVuvgjdw%40mail.gmail.com.

Re: [fricas-devel] Re: [aldor-devel] Renaming $ to %

[Peter Broadbery]

In aldor, %% is an internal symbol used to expose parent categories -
You will sometimes see categories that have exports like:
"with {%%: BasicType; eq: (%, %) -> Boolean}".  The idea being that
exposing a parent category acts in a similar way to exposing a single
export.
This makes the compiler's life easier and gives an easy way to
implement the 'has' test. You'll see that interop.boot implements
'has' tests in aldor domains this way as well.

I've never looked at the fricas compiler, so I can't comment on what
'$$' and '$$$' mean there.  In the aldor world it would be an error to
confuse '%', (a name referring the current domain) with '%%'
(something that is internal and does not refer to any concrete value),
so it would be fine to give the two very different names.

My inclination would be to leave the fricas '$$' and '$$$' alone - at
least until aldor behaves well following the '$' to '%' changes.

On another subject, I've raised
https://github.com/fricas/fricas/pull/125 so that a fricas build can
do some testing against aldor as an optional part of the build.  It
would be nice to include it, but I can equally see that it might not
be wanted as part of the default regression test suite.

Peter

On Mon, 15 May 2023 at 11:54, Waldek Hebisch
 wrote:
>
> On Mon, May 15, 2023 at 07:36:06AM +0200, Ralf Hemmecke wrote:
> > 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.
>
> I suspect that Aldor use of %% is different than our $$.  And we use
> %%, but for printing single %.
>
> > > 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.
>
>
> Hmm, AFAICS ax.boot is for "exporting" info to Aldor, as.boot is to
> get back info (databases) from Aldor.  'astran' should be called when
> you do ')lib' on Aldor files.  Parts of as.boot apparently are unused,
> but since I can not test I did not try to remove them.
>
> > I'll try to prepare a proper (tested) pull-request for "$ --> % renaming".
>
> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/20230515113639.xuvzoezy5o4e6qj4%40fricas.math.uni.wroc.pl.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN9GZLShEEdjxSe__VToyU%2BhTETyhUQJGdDmVf9d82KgNA%40mail.gmail.com.

Re: [fricas-devel] about sbcl-2.3.2 (package related) compile error

[Peter Broadbery]

OK - I like the nice simple solutions.  I've merged a commit to remove
the extra :use from the generated files and foam_l.lsp.

Changing the lisp generator and function library is pretty easy - if
there are any other changes that would improve things at this level do
let me know.

Peter


On Sun, 5 Mar 2023 at 15:25, Waldek Hebisch
 wrote:
>
> On Sun, Mar 05, 2023 at 02:33:20PM +0000, Peter Broadbery wrote:
> > > Aldor generates non-standard Lisp -- "in-package" with :use keyword.
> >
> > What should be generated?  I'm happy to change it to something more 
> > standard.
> > I don't really know lisp, so I'd rather implement other peoples ideas
> > in this area..
>
> Just 'in-package' without extra stuff, like:
>
> (in-package "BOOT")
>
> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/20230305160818.odtfek3il3k7un66%40fricas.math.uni.wroc.pl.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN-n%3D%2BL246%3DKXHcw5yKpJtzCbtnaHkgnLAc%3DHx4V0hU3vQ%40mail.gmail.com.

Re: [fricas-devel] about sbcl-2.3.2 (package related) compile error

[Peter Broadbery]

> Aldor generates non-standard Lisp -- "in-package" with :use keyword.

What should be generated?  I'm happy to change it to something more standard.
I don't really know lisp, so I'd rather implement other peoples ideas
in this area..

Peter

On Sun, 5 Mar 2023 at 13:26, oldk1331  wrote:
>
> As Waldek said in the github comment:
>
> "IIRC redefined 'in-package' was added for Aldor. I do not know
> if Aldor still need it."
>
> Aldor generates non-standard Lisp -- "in-package" with :use keyword.
>
> - Qian
>
> On Sun, Mar 5, 2023, 9:14 PM Ralf Hemmecke  wrote:
>>
>> > So, what we intend to do: (due to still existed issue on the Aldor side)
>>
>> What exactly do you mean here?
>>
>> At least I am relieved that your patch does seemingly not break the
>> fricas-aldor interface.
>>
>> Ralf
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/fricas-devel/601f3797-8bfd-088d-a67e-9a1d1b68ad61%40hemmecke.org.
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/CAGBJN92z-YcU4WvOxiWaCpKws7wLQ%3DznufzWvSBHvWC_kBFbuQ%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN-dbux8azK5n2OZyE670roN7v2xskG79MQHC6mWFegH%2Bw%40mail.gmail.com.

Re: [fricas-devel] Fricas/aldor intelij plugin

[Peter Broadbery]

OK - I'm working on updating the plugin to a more recent edition -
there should be an updated release soon.

Please do use the issue tracker - it makes it easier for development.

Thanks,

Peter



On Wed, 31 Mar 2021 at 08:57, Grégory Vanuxem  wrote:
>
> Hi,
>
> Le mar. 30 mars 2021 à 09:59, Peter Broadbery  a écrit 
> :
> >
> > Hi Greg,
> >
> > First, which version  of the plugin are you using? I created a new
> > release over the weekend, but it's not quite fully tested.
>
> Just a quick note. As I said I use the previous version of your plugin.
>
> I tried to install your actual release, release 1.2, but it's not
> installable in the 2020.3 community edition.
> Message : "it requires build 201.* or older version but the current
> build is IC-203.7717.56"
>
> Later if I submit other issues I'll preferably use GitHub issues tracker.
>
> Regards
>
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/CAHnU2dbM0qAHmo8TGU6w5dbyM4MD_asYMoNW%3DO%2BvVRV_-577jg%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN-trkHZBRJnhTaVAKjicnhnKKxjxfx6ORzTEzrWw-%2BKCA%40mail.gmail.com.

Re: [fricas-devel] Fricas/aldor intelij plugin

[Peter Broadbery]

Hi Greg,

First, which version  of the plugin are you using? I created a new
release over the weekend, but it's not quite fully tested.

The code that checks for a valid fricas directory expects to find a
file called 'bin/fricas', and so it's unlikely to work in windows
where the script would be 'fricas.bat'. It's a small code change, so
will test on a windows box prior to the next release. As a workaround,
 it might be enough to create an empty file then remove it once the
setup stage is done.

Code within ')if' and ')endif' is recognised as such, but shows up as
normal text, rather than comments. Thanks for letting me know as it
can be fixed.

I'll also have a look at the issue on floating point numbers.  It's
probably that I didn't get round to implementing them and the current
approach looks kind of ok, if wrong.


On Tue, 30 Mar 2021 at 05:03, Grégory Vanuxem  wrote:
>
> Le mar. 30 mars 2021 à 03:45, Grégory Vanuxem  a écrit :
> >
> > Hi,
> >
> > I'm trying your plugin and it looks promising, thanks.
> > Unfortunately I still can't get it to work on Windows to have full
> > functionalities.
> > I presume a path problem to FriCAS 'target' directory, I have to
> > investigate the problem.
> > I'll tell you necessary tricks if I find how it's possible to get it
> > to work. Maybe you know how?
>
> I forgot, the error message is "The selected directory is not a valid
> home for FriCAS SDK".
>
> C:\FriCAS\lib\fricas\target\x86_64-w64-mingw32
>
> With in it:
> Mode LastWriteTime Length Name
>  - -- 
> d-16/03/2021 17:54algebra
> d-16/03/2021 17:54autoload
> d-16/03/2021 17:54bin
> d-16/03/2021 17:54lib
> d-16/03/2021 17:54share
> d-16/03/2021 17:54src
>
> Greg
>
> > Nevertheless, I use a lot VSCode because it's possible to easily
> > switch between Windows and Linux (WSL) OSes, it's just one click with
> > VSCode
> > only installed on Windows. So it helps to code on Windows or on Linux
> > with all their development tools, shells etc. And since I ported the
> > Atom
> > spad syntax code* from Bill Page to VSCode I looked at your source and
> > code. Astonishing! But I noticed that maybe you can add the ')if false
> >  )endif' comments, see for example texmacs.spad. And last thing,
> > I'm just trying your plugin for now, more important, apparently you
> > forgot floating point numbers (with or without 'e'). 1.2 is treated as
> > two integers separated by a dot, so colors are different.
> >
> > That's all :)
> >
> > Greg
> >
> > * Bill you forgot to change *.*.python to *.*.spad for several "name"s
> > in your .cson syntax file ;). See quoted strings part.
> >
> >
> >
> >
> > Le sam. 3 mars 2018 à 11:28, Peter Broadbery  a 
> > écrit :
> > >
> > >
> > > Hi,
> > >
> > > I've just uploaded a preliminary intellij plugin for Fricas and Aldor 
> > > code.
> > > This version supports:
> > > - Syntax highlighting
> > > - Type browser (SPAD code only)
> > > - Documentation for types and operations
> > > - Running .input files
> > >
> > > It's good enough for me to use on aldor code, and looks good for Spad.
> > >
> > > Release is here: 
> > > https://github.com/pbroadbery/aldor-idea-plugin/releases/tag/preview-3
> > > There are some "getting started" notes on the wiki pages..
> > > https://github.com/pbroadbery/aldor-idea-plugin/wiki .  There's some 
> > > parts that might need a fuller explanation (especially if you're new to 
> > > intellij), so feedback appreciated.
> > >
> > > For this to work, I've also modified the Aldor compiler so that it can 
> > > export domains as java classes (and vice-versa).  The plugin uses a very 
> > > rough Aldor implementation of the Spad and Aldor type systems in 
> > > https://github.com/pbroadbery/fricas-aldor-types.
> > >
> > > If anyone is interested in improving either the plugin (java) or the type 
> > > inference bit (aldor), or the aldor/java interface (mostly C), please let 
> > > me know.  There's a lot of additional functionality that could be added.
> > >
> > > Equally

Re: [fricas-devel] Moving away from "failed"?

[Peter Broadbery]

On Tue, 23 Feb 2021 at 18:00, Waldek Hebisch  wrote:
>
> On Tue, Feb 23, 2021 at 10:03:25AM +0800, Qian Yun wrote:
> >
> >
> > On 2/22/21 3:19 AM, Ralf Hemmecke wrote:
> > >
> > >
> > > On 21.02.21 18:53, Peter Broadbery wrote:
> > > > On Fri, 19 Feb 2021 at 09:48, Ralf Hemmecke  wrote:
> > >
> > > > > > IIUC Aldor does not suport "failed" (with Spad notation) as a type,
> > > > > > which leads to massive source changes (this is in the language
> > > > > > differences page).
> > >
> > > > Aldor does allow 'Union(a: T, failed?: 'failed'), which might be 
> > > > similar enough.
> > > > Tangentially, what would be the issues with switching the algebra code 
> > > > to use
> > > > Partial instead of the Union?
> > >
> > > I would love to see such a change and I would happily help in this
> > > endeavour.
> > >
> > > Ralf
> > > Ralf
> > >
> >
> >
> > I would like FriCAS to move away from "failed" and choose Haskell style
> > "Maybe" instead.  This topic has been discussed before, I wonder if
> > Waldek's opinion has changed.
>
> Up to now I saw nothing to change my opinion.  To clarify, automatic
> "lifting" of operations for T to say Maybe(T) would be useful.
> But up to now I do not see workable proposal how to implement
> such lifting and what exact rules should be.  Without viable
> strategy for implementing extra functionality change to
> Maybe from my point of view looks pointless.
>
> To put is differenly, I view compiler, language and coding idioms
> as a whole.  Clearly many language constructs need compiler
> support.  Coding idioms depend on language and compiler.
> New coding idiom my be quite useful without new support.
> But IMO usefulness of Maybe depends very much on features
> of Haskell and Haskell compiler.  While it may be
> possible to have useful effect is quite different way,
> mere change of notation does not look useful.
>

OK - That does make sense.   I do have some ideas for how automatic
lifting can be
done within Aldor, but it looks like there are a lot of other issues
to work through as well.

> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/20210223180017.GB15427%40math.uni.wroc.pl.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN8EnEBDOE%2BCJecF-Q5cRPpnYDwficZgYZenNUjn5aR4Dw%40mail.gmail.com.

Re: [fricas-devel] Development of packages with Aldor

[Peter Broadbery]

On Sun, 21 Feb 2021 at 19:19, Ralf Hemmecke  wrote:
>
>
>
> On 21.02.21 18:53, Peter Broadbery wrote:
> > On Fri, 19 Feb 2021 at 09:48, Ralf Hemmecke  wrote:
> >>
> >>>> "/mnt/lv3/fricas/axp19/pp1/algreduc2/RDEEFX3a.as", line 36:
> >>>> ei_int : (Z, F, F, SE) -> PSOL2
> >>>> ..^
> >>>> [L36 C7] #1 (Warning) Escape character ignored.  Do you mean '__'?
> >>>>
> >>> This is just a warning, in first pass of checking Spad code we
> >>> probably can ignore warnings.
> >>
> >> Ooops. Yes, indeed. However, it gives different identifiers in Aldor and
> >> SPAD. In Aldor ei_int is the same as eiint.
> >>
> >
> > This has always struck me as a bit of a misfeature; It may be better
> > if the lexer was
> > modified to treat '_' as a normal character within identifiers.
>
> BTW, I never said that I like double underscores in identifiers. I just
> think that we should rather stick with using CamelCase identifiers in
> Aldor/SPAD code and not being driven by naming conventions in other
> languages (neither Lisp nor C).
>
> If you like then change the Aldor lexer. I find it then just a little
> annoying that the underscore is no longer an escape character in all
> situations.
>

The plan would be that the underscore would only be an escape character
within an identifier if it changed the treatment of the following character.
So _+ would be an identifier called '+', mod_+ would be 'mod+' (as today),
but foo_bar would be 'foo_bar'.  Calls to lisp hyphenated names would still
need underscores, so 'read_-byte', etc

> Long time ago I also heard Stephen Watt thinking aloud to change the
> escape character from underscore to something else. I would also be open
> to that, but have no good suggestion for another escape character.
> There are, however identifiers like ts_v_+ in FriCAS or mod_+ in Aldor,
> that rely on _ being an escape character and would probably look strange
> with another escape character.
>
> The backslash would be fine if we didn't have identifiers like /\ and
> \/. However, if the character set for identifiers would be extended to
> unicode, then backslash would be OK. Unicode identifiers would also
> allow for more operation symbols like
>
> Unicode Character 'CIRCLED PLUS' (U+2295).
>
> and more. (Well... hopefully that doesn't start the discussion about
> SemiGroup vs. AbelianSemiGroup again.)
>
>
> >> One way to avoid most of the explicit imports is to always add the type
> >> to a variable when you first assign it.
> >> That has two (at least for me) important aspects.
> >>
> >> (1) Readers of the code explicitly see what the type of the variable is
> >> and don't have to figure it out from the context --- that's sometimes
> >> not so easy. (Maybe that can some day be relaxed, if we have editors
> >> that show the type of an expression when your mouse hovers over it.)
>
> Peter, that would be great, but I fear that doesn't make everyone happy
> since it requires a certain editor with your plugin, right?
>

The certain editor would be intellij. I like it, at least for certain
types of work.  Others
will have other opinions, and as with vi & emacs, each to their own.

> >>> IIUC Aldor does not suport "failed" (with Spad notation) as a type,
> >>> which leads to massive source changes (this is in the language
> >>> differences page).
>
> > Aldor does allow 'Union(a: T, failed?: 'failed'), which might be similar 
> > enough.
> > Tangentially, what would be the issues with switching the algebra code to 
> > use
> > Partial instead of the Union?
>
> I would love to see such a change and I would happily help in this
> endeavour.
>
> Ralf
> Ralf
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/7fee7312-a143-8cf9-92d2-b194e30d2e10%40hemmecke.org.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN-BPWXktmrMMadSJCFjdXJf_8obVAnNzmzwWn8W4-o2Sw%40mail.gmail.com.

Re: [fricas-devel] Development of packages with Aldor

[Peter Broadbery]

On Fri, 19 Feb 2021 at 09:48, Ralf Hemmecke  wrote:
>
> >> "/mnt/lv3/fricas/axp19/pp1/algreduc2/RDEEFX3a.as", line 36:
> >> ei_int : (Z, F, F, SE) -> PSOL2
> >> ..^
> >> [L36 C7] #1 (Warning) Escape character ignored.  Do you mean '__'?
> >>
> > This is just a warning, in first pass of checking Spad code we
> > probably can ignore warnings.
>
> Ooops. Yes, indeed. However, it gives different identifiers in Aldor and
> SPAD. In Aldor ei_int is the same as eiint.
>

This has always struck me as a bit of a misfeature; It may be better
if the lexer was
modified to treat '_' as a normal character within identifiers.

> > OTOH this is important feature
> > for mixed-language code.  In Lisp camelCase is not practical,
>
> From primitives.lisp ...
>
>   (defun |STR_to_CHAR_fun| (s)
>
> As far as I understand it would be perfectly fine to use |CamelCase|
> identifiers in Lisp. So, yes, I agree that there are different naming
> conventions in Lisp and Aldor/SPAD, but I don't think that in a
> multi-language system (where one language (SPAD) is the main language
> and all the others are helper languages that implement the underlying
> system)
> one must unify the naming conventions.
>
> That said, yes, let's ignore the underscore warnings in an approach to
> bring the full library to Aldor.
>
> > Yes, I know this.  One point of this excercise was to see how many
> > explicit imports I would need.  It was disappointing that other
> > problems apparently dwarfed issue with imports.
>
> One way to avoid most of the explicit imports is to always add the type
> to a variable when you first assign it.
> That has two (at least for me) important aspects.
>
> (1) Readers of the code explicitly see what the type of the variable is
> and don't have to figure it out from the context --- that's sometimes
> not so easy. (Maybe that can some day be relaxed, if we have editors
> that show the type of an expression when your mouse hovers over it.)
>

We are potentially quite close to this for Aldor - a lot of the groundwork
has been done, but not there yet.

> (2) In Aldor 'a: A' means also an implicit 'import from A'. Aldor has :*
> for avoiding this implicit import. See Section 8.13 of the Aldor User Guide.
>
> If there is too much in scope one has to help the compiler in certain
> places to disambiguate function calls with the same name and argument
> types. But that is easy with $ and @. Actually, Aldor is quite good in
> selecting the right function if it can figure out enough type
> information from the context.
>
> > IIUC Aldor does not suport "failed" (with Spad notation) as a type,
> > which leads to massive source changes (this is in the language
> > differences page).
>

Aldor does allow 'Union(a: T, failed?: 'failed'), which might be similar enough.
Tangentially, what would be the issues with switching the algebra code to use
Partial instead of the Union?


Peter

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN_BdyEwsd-Vt%2BsLJTkB-DS5A%3Do2JxLTvLK8H3Si0xRBjQ%40mail.gmail.com.

Re: [fricas-devel] Development of packages with Aldor

[Peter Broadbery]

I'll take a look at your example; it's possible that there's some
unreleased changes that will help.
Does that test file also show a factor of 10 slowdown?

I had also started a bottom up translation of SPAD to Aldor code, but
stopped for some reason.  If any one is interested in resurrecting
this project I'm happy to share it.

Peter



Peter





On Thu, 18 Feb 2021 at 17:37, Waldek Hebisch  wrote:
>
> On Thu, Feb 18, 2021 at 08:24:08AM +0100, Ralf Hemmecke wrote:
> > > There were plans in early period of open source Axiom.  AFAIK there
> > > are no visible results.  There would be some benefit if one could
> > > compile algebra using Aldor.  Relatively recently I did a little
> > > experiment and it seems that there is a lot of use of few constructs
> > > that are valid and perfectly good Spad but which are rejected by
> > > Aldor.  IMO if one seriously thinks about using Aldor to compile
> > > FriCAS algebra one first needs to modify Aldor to accept those
> > > constructs.
> >
> > Waldek, can you give a list of those constructs so that we can show them
> > publicly in "Differences between Aldor and SPAD"?
>
> See attached file and Aldor compilation report (I sent it before
> but I include it in case it got lost).
> >
> > > Also, on files that I tried Aldor compiler was about 10 times slower
> > > than Spad compiler.  For me Spad compiler is slow and 10 times
> > > slowdown would be step back.
> >
> > That is one issue. But honestly, it is more important to me if the
> > compiled code runs faster and is safer.
>
> Yes, safer code is among expected benefits.  Concerning speed:
> AFAIK there is no inlining between Aldor and Spad code.  So
> if you use Spad types from Aldor (via interface) all operations
> would go via function calls and consequently almost all Aldor
> optimizations will be ineffective.  So you will get better
> speed only when all time-critical parts will be pure Aldor.
> IIUC in your interface few basic Spad types are entirely replaced
> by low Aldor types, but my impression is that Spad compiler
> can profitably inline more than that.
>
> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/20210218173657.GA12410%40math.uni.wroc.pl.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN-kx0LDMaU0d9gG5LM2z4psQbPq_kfsQ4Gk4aVwfhECAA%40mail.gmail.com.

Re: [fricas-devel] setelt! vs. set!

[Peter Broadbery]

On Wed, 4 Dec 2019 at 17:47, Waldek Hebisch  wrote:
>
> Peter Broadbery wrote:
> >
> > In aldor 'elt' was renamed to 'apply' - since it can be used for
> > things other than data structure like domains.
> > So, setelt! had to become something a bit more general as well, and
> > set! was chosen.
>

> Not very strong motivation, but reasonable.  Does this means that
> to have agreement we would have to rename 'elt' to 'apply' in
> FriCAS?   AFAICS there are few uses of 'apply' in FriCAS for
> other purposes.
>
>

For complete agreement with aldor, yes.  But maybe there's some value
in just doing 'set!'.
It's fine to have other uses of apply in aldor, For example, one can
say apply(foo, x) instead of
the shorthand 'foo(x)'


> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/E1icYkg-0002fH-Tt%40hera.math.uni.wroc.pl.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN96yJ5cmNv6i_sCWDV9UadUeTAbUHRGA0k5W%2BpmP3pfdg%40mail.gmail.com.

Re: [fricas-devel] setelt! vs. set!

[Peter Broadbery]

In aldor 'elt' was renamed to 'apply' - since it can be used for
things other than data structure like domains.
So, setelt! had to become something a bit more general as well, and
set! was chosen.

It may be possible to add a 'use fricas names' flag to aldor for use
when compiling fricas code.
This is probably the simplest solution if the fricas name is kept. (it
will take time to implement, of course).


On Mon, 2 Dec 2019 at 16:49, Waldek Hebisch  wrote:
>
> Ralf Hemmecke wrote:
> >
> > Hi Peter, hi Waldek, (and fricas-devel list),
> >
> > since I wanted to take advantage of Aldor's ability to show me exactly
> > which functions are still unimplemented, I tried to compile a .spad file
> > with Aldor.
> >
> > There were a few expected problems because the Aldor compiler is more
> > strict with respect to types. But then I hit the problem with a missing
> > setelt!.
> >
> > Obviously, in libfricas, we have "set!" instead of "setelt!". That's
> > necessary so that assignment "a(i,j,k) := val" works in Aldor.
> > Unfortunately, I was using "setelt!" by its name and stumpled over the
> > problem that "setelt!" is actually missing. (Below shown for the domain
> > "Reference".
> >
> > Of course, that's not a very big problem, but in order to make the
> > languages SPAD and Aldor more similar, it would be good, if "setelt!"
> > would be renamed to "set!" in FriCAS.
> >
> > find . -type f -exec grep --color -nH -e 'setelt!' {} +|grep -Ev
> > 'qsetelt!|~:|ChangeLog'| grep --color 'setelt!'|wc -l
> > 361
> >
> > Waldek, I know it's only a cosmetic change but would you approve such a
> > patch?
>
> I do not why Aldor changed name.  To say the truth 'setelt!' is
> more descriptive so looks like a better name.
>
> I have no obection in principle, but the question is who should
> adapt:
> - if Aldor has good reasons to change then it makes sense to follow
> - if change in Aldor was without reason, then it would make sense
>   to change Aldor
> - if for some reason Aldor _needs_ different name, then we just
>   should live with it.
>
> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/fricas-devel/E1ibot9-0001zZ-OM%40hera.math.uni.wroc.pl.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/CAK%3DmBN-KKHjwRkx_7X%3DaDAGy35RkRQKP2kFz%2BseanrbqveDRVg%40mail.gmail.com.

[fricas-devel] Conditional exports in some types

[Peter Broadbery]

Hi,

I've been looking at the aldor interface (again), and found there's a
few categories in fricas with what appears to be an incorrect
condition on some exports

For example, conditionP in POLYCAT has the following condition:

conditionP : Matrix(%) -> Union(Vector(%),"failed") if
and(has($,CharacteristicNonZero),has(R,PolynomialFactorizationExplicit))

I'd expect 'AND' to be an infix operator as normal.

Obviously it's not causing much of a problem as the workaround is
trivial, but seems to imply that there's some simplification missing
(or 'and' is not being mapped to 'AND' in this case).  Two other
categories have similar exports, DIRPCAT and PSCAT.

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Aldor interface

[Peter Broadbery]

I've updated the aldor interface PR to include correct generation of
defaults for conditionals - https://github.com/fricas/fricas/pull/4/files
It does need the latest aldor from https://github.com/pippijn/aldor - which
also contains some performance improvements.

The PR also modifies configure.ac to allow specification of the aldor
binary, which is handy for testing.

Peter


On Thu, 19 Jul 2018 at 16:55, Waldek Hebisch 
wrote:

> Ralf Hemmecke wrote:
> >
> > This contains recent discussion about a patch for the
> > fricas-aldor-interface due to changes in the Aldor compiler.
> > -
> >
> > The conditions for the exports can obviously be extracted from the
> > database. At least I see these ifs in the .ap file with the ax.boot that
> > we currently have.
> >
> > The main problem is to get the conditions for default implementations.
> >
> > Since fricas generates lisp, I'm pretty sure that even if they are deep
> > in compiled code, at the time a function is needed at runtime, there
> > must be some piece of code to actually find which domain (or default
> > package) that function actually implements. Unfortunately, I have no
> > idea, where this code is how to translate the information into an .ap
> > format.
>
> IIUC current code generating interface lies: it says that operations
> are unconditional.  Pragmatically, it should be good enough to
> say that default operation is present when it is exported from
> category.
>
> If you want to do better you can look at the domain constructor
> for default package.  For DIRPCAT the domain constructor is
> in DIRPCAT-.NRLIB/DIRPCAT-.lst.  The name is 'DirectProductCategory&'.
> There are three COND-s at the end containing things like:
>
>  (QSETREFV $ 12
>(CONS (|dispatchFunction| |DIRPCAT-;coerce;IS;1|)
> $))
>
> The conditions in COND-s are exactly donditions under which
> 'coerce' has default implementation.  As you can see conditions
> are collected in a bit vector.  Meaning of bits is in database:
>
> (1) -> )boot GETDATABASE("DirectProductCategory&", 'PREDICATES)
> (EVAL-WHEN (EVAL LOAD)
>   (PROG () (RETURN (GETDATABASE '|DirectProductCategory&| 'PREDICATES
> Value = ((|HasCategory| |#3| '(|Field|))
>  (|HasCategory| |#3| '(|OrderedAbelianMonoidSup|))
>  (|HasCategory| |#3| '(|OrderedSet|))
>  (|HasCategory| |#3| '(|unitsKnown|))
>  (|HasCategory| |#3| '(|CommutativeRing|))
>  (|HasCategory| |#3| '(|Finite|)) (|HasCategory| |#3|
> '(|SemiGroup|))
>  (|HasCategory| |#3| '(|SemiRng|)) (|HasCategory| |#3| '(|Monoid|))
>  (|HasCategory| |#3| '(|AbelianMonoid|)) (|HasCategory| |#3|
> '(|Ring|))
>  (|HasCategory| |#3| '(|SetCategory|)))
>
> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Fricas on SPAD vs Fricas on Aldor?

[Peter Broadbery]

On 10 July 2018 at 18:44, Ralf Hemmecke  wrote:

> On 07/10/2018 06:35 PM, Waldek Hebisch wrote:
> > Just a comment: current Spad compiler essentially imports every
> > domain that is sees: types of function arguments, type of value,
> > etc.  This is creasy, because set of visible functions depends
> > on exact computation path taken in the compiler -- slight change
> > to compiler code and suddenly something does not compile
> > because needed domain is not longer visible.
>
> Isn't it also the case that suddenly something doesn't compile anymore
> only because there is a new domain (automatically imported) that exports
> the similar functionality so that now a function that does not
> explicitly state from which package/domain it should be called.
>
> What I definitely don't want is that a .spad file cannot be compiled
> anymore only because someone added another .spad file.
>
> For that reason, I'm very much in favour of giving the programmer full
> control of what is imported and what is not visible.
>
> As far as I remember, if I write
>
>   x: T := foo(...)
>
> then T will be imported.
>
> Giving explicit types is not necessarily a bad thing. The names of
> variables are not always so telling that code becomes easy to read.
>
> Peter once suggested to let an IDE show the type of a variable in a
> pop-up bubble when hovering with the cursor over that variable. That
> would be great. But I definitely don't want to just hide the type.
>
> Just my 2 cents.
>
>
For what it's worth I have a variant of this working in aldor - showing
docs in place of types.
If the spad compiler generated a marked up parse tree it might be doable
there as well.



> Ralf
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Fricas on SPAD vs Fricas on Aldor?

[Peter Broadbery]

[Replying privately as not totally thought through]

Proposal sounds like its ok, but does it deal with package imports,
especially for things like map and reduce operations?

To be a bit more specific my plan for aldor is to
1) introduce 'import from F', where F is a domain or package constructor.
2) drop the requirement for function return types to be specified.

Peter

On Tue, 10 Jul 2018, 17:35 Waldek Hebisch,  wrote:

> Peter Broadbery wrote:
> >
> > A second issue is that Aldor is much stricter about imports and function
> > declarations.  I have a set of changes that may help to address these,
> but
> > there is a bit more to do.  If there's anyone who wants to help with
> these,
> > it would be appreciated.
>
> Just a comment: current Spad compiler essentially imports every
> domain that is sees: types of function arguments, type of value,
> etc.  This is creasy, because set of visible functions depends
> on exact computation path taken in the compiler -- slight change
> to compiler code and suddenly something does not compile
> because needed domain is not longer visible.
>
> I would like to have well-defined systematic handling of visiblity.
> ATM I am not sure if I like Aldor way.  IIUC the afficial Aldor
> statement is that one has to explicitely import everything.
> This is simple to implement and clear, but may be restritive
> in practice (I do not not how restrictive).  At theoretical
> level I considered different approach: compile first treating
> everyting from library as visible and then reject that types
> which are "unjustified".  Namely, some things are visible,
> those are "justified".  Given justified function with argument a
> of type T, function from T used as last step of computation of
> a is justified too.  Similarly, when f comes from T, argument
> of f is justified and of type T, then f is justified too.
> Theoreticaly it looks nice, while more complex than expicit
> imports is still reasonably easy to describe.  I guess that
> implementation should not be very hard.  I am not sure
> how it work in practice.
>
> Anyway, in current algebra I have added several expicit imports
> to I plan to add more.
>
> Concerning function signatures, recently I improved capability
> of Spad to infer signatures so that one can give only minimal
> information needed to choose correct signature.  OTOH Spad
> produces warning when there is more than one possible
> signature and I added explicit declarations to disambiguate
> all cases that used to produce warnings.
>
> There is tiny difference between user (Spad programmer) convenience
> and sloppy coding, but while I would like to make Spad coding
> more convenient I am commited to remiving/fixing sloppy code
> from FriCAS library.
>
> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Fricas on SPAD vs Fricas on Aldor?

[Peter Broadbery]

Just to add a little, I am working on addressing the compilation time
issue,
and the newer version is significantly faster, but there is more to be done.

A second issue is that Aldor is much stricter about imports and function
declarations.  I have a set of changes that may help to address these, but
there is a bit more to do.  If there's anyone who wants to help with these,
it would be appreciated.

Peter

On 2 July 2018 at 20:43, Waldek Hebisch  wrote:

> Riccardo GUIDA wrote:
> >
> > Thoughts:
> >
> > * The Aldor compiler is an improved version of the Spad compiler,
> written by one of its authors. So, as a non-expert, I would blindly tend to
> say that Aldor compiler is "better" than Spad compiler. At least it has
> written documentation and, I guess, it should produce faster compiled code
> (eg by compiling via the C compiler not the lisp one).
> >
> > *  Spad syntax is, say, "90% equal" to Aldor, so moving the .spad files
> in algebra to .as files should not be impossible.
> >
> > * I guess the really "hard" problem is "porting" the interpreter to work
> on the top of Aldor, maybe using its -gloop shell.
> >
> > * On this list, I've never heard mentioning this "port to Aldor" even as
> a long term/dreamy  project, while I've heard hypothetical mentions on
> rewriting the current fricas interpreter, which should also be "hard".
> >
> > So my questions:
> >
> > * would "porting" the interpreter on the top of aldor be much more
> difficult & unrealistic than rewriting the current fricas interpreter?
> >
> > * Which solution do you prefer, and, more important, could you somehow
> explain why?
>
> This "porting to Aldor" thing is more complex than your questions
> suggest.  First, Aldor was intended to be "library compiler", so
> natural use of Aldor would be to compile FriCAS library.  Clearly
> "not impossible", but requires some work.  I view this as main
> part of port, because once it is done could use Aldor interpreter
> as user interface and get "FriCAS on Aldor" in this way (of course
> loosing most of functionality of current FriCAS interpreter).
>
> There is question of desired runtime support ("virtual machine").
> Since Aldor can generate Lisp code we could continue to use Lisp
> runtime.  With Lisp runtime it should be possible to use
> current FriCAS interpreter with minimal changes.  Or we could
> try to port to Aldor runtime (working on top of C).  Using
> Aldor runtime and compilation via C has advantage to better
> speed of compiled code (my guesstimate is that we can gain
> factor of 2 compared to sbcl).
>
> You write about porting "interpreter".  Using Lisp runtime
> this should be quite small job.  If one want interpreter
> on Aldor runtime, then IMO best way is to rewrite
> interpreter -- you need it in a language which is compatible
> with Aldor runtime.  In other words I treat interpreter
> rewrite as preconditiont to port to Aldor.
>
> Before we spent time on port we should think about benefits.
> Unfortunatly, this does not look so good.  First, speed
> on current Spad code depends on several optimizations
> performed by Spad compiler.  Aldor in principle can do
> better optimizations, but current Aldor interface
> essentially disables all possibilities for optimization.
> So in intermediate stages we will get _slower_ code.
> Only when port is done and we have "native Aldor"
> (as opposed to using Aldor-FriCAS interface) we can
> count on faster code and benefit from Aldor
> optimizations.
> Second, my recent experiments suggest that Spad compiler
> compiles about 10 times faster than Aldor compiler.
> I would say that Spad compiler is slow, but tolerable.
> ATM for me Aldor is "too slow", IMO it needs significant
> improvement to compilation speed.
> Third, Aldor language is better.  However, there is
> a factor here: while better I do not treat Aldor as
> kind of ultimate language.  I think that various aspects
> of Aldor need improvement.  So there is question
> how much effort improvements to Aldor compiler would
> take?
>
> Now, which solution I take?  ATM I leave question of
> Aldor port open.  As I wrote I consider interpreter
> rewrite as precondition to porting intepreter to Aldor,
> so before rewrite I see no point in planning/attempting port.
> For FriCAS library ("algebra") problem is that at
> intermedate stages there is loss, only at the end
> we would get benefits.  Important question is
> developement of Aldor.  Namely, Aldor compiler is much
> larger than Spad compiler, so probaly will r

Re: [fricas-devel] Small documentation patch

[Peter Broadbery]

I

On 11 Mar 2018 13:53, "Waldek Hebisch"  wrote:

> > I've noticed a couple of places in the algebra code where the
> documentation
> > strings are misplaced, causing the generated documentation to be
> incorrect.
> > (eg. IndexedExponents), or just looks like they should have been a
> > comment.  Obviously, fixing these helps with the IDE stuff I'm doing as
> > well.
> >
> > Would it be possible to get the patch below applied:
> >
> > https://github.com/pbroadbery/fricas/commit/3b73adb1692ed039
> 95df0dad3e18c17b4436bbc5.patch
> >
>
> Mostly looks good.  But the patch to 'fortran.spad' introduces overlong
> lines.
>
>
OK - I wasn't sure about there being a line length limit.  New patch
without fortran.spad:
https://github.com/pbroadbery/fricas/commit/714402fa5224c5b39d77c46b5eac9e98553bdd7e.patch

Thanks,

Peter



> --
>   Waldek Hebisch
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Small documentation patch

[Peter Broadbery]

Hi,

I've noticed a couple of places in the algebra code where the documentation
strings are misplaced, causing the generated documentation to be incorrect.
(eg. IndexedExponents), or just looks like they should have been a
comment.  Obviously, fixing these helps with the IDE stuff I'm doing as
well.

Would it be possible to get the patch below applied:

https://github.com/pbroadbery/fricas/commit/3b73adb1692ed03995df0dad3e18c17b4436bbc5.patch

Thanks,

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Fricas/aldor intelij plugin

[Peter Broadbery]

Thanks - it was an interesting path getting it to this point.

I've not looked at atom or Julia but will - it looks like there things to
learn from it.

Regards

Peter

On 8 Mar 2018 19:10, "Grégory Vanuxem"  wrote:

Dear M. Broadbery,

This looks like a beautiful things, I must admit.

Am working on add-ons of Juno-Julia which I find is also a beautiful thing
too.
The purpose is different but am looking right now more into what you have
done. Seems interesting.

Juno-Julia, you know I think :

https://julialang.org/
http://junolab.org/
https://atom.io/

Have a good night (or...)

__
G. Vanuxem








2018-03-03 11:27 GMT+01:00 Peter Broadbery :

>
> Hi,
>
> I've just uploaded a preliminary intellij plugin for Fricas and Aldor code.
> This version supports:
> - Syntax highlighting
> - Type browser (SPAD code only)
> - Documentation for types and operations
> - Running .input files
>
> It's good enough for me to use on aldor code, and looks good for Spad.
>
> Release is here: https://github.com/pbroadbery/
> aldor-idea-plugin/releases/tag/preview-3
> There are some "getting started" notes on the wiki pages..
> https://github.com/pbroadbery/aldor-idea-plugin/wiki .  There's some
> parts that might need a fuller explanation (especially if you're new to
> intellij), so feedback appreciated.
>
> For this to work, I've also modified the Aldor compiler so that it can
> export domains as java classes (and vice-versa).  The plugin uses a very
> rough Aldor implementation of the Spad and Aldor type systems in
> https://github.com/pbroadbery/fricas-aldor-types.
>
> If anyone is interested in improving either the plugin (java) or the type
> inference bit (aldor), or the aldor/java interface (mostly C), please let
> me know.  There's a lot of additional functionality that could be added.
>
> Equally, suggestions for improvements welcome.
>
> Peter
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Fricas/aldor intelij plugin

[Peter Broadbery]

Hi,

I've just uploaded a preliminary intellij plugin for Fricas and Aldor code.
This version supports:
- Syntax highlighting
- Type browser (SPAD code only)
- Documentation for types and operations
- Running .input files

It's good enough for me to use on aldor code, and looks good for Spad.

Release is here:
https://github.com/pbroadbery/aldor-idea-plugin/releases/tag/preview-3
There are some "getting started" notes on the wiki pages..
https://github.com/pbroadbery/aldor-idea-plugin/wiki .  There's some parts
that might need a fuller explanation (especially if you're new to
intellij), so feedback appreciated.

For this to work, I've also modified the Aldor compiler so that it can
export domains as java classes (and vice-versa).  The plugin uses a very
rough Aldor implementation of the Spad and Aldor type systems in
https://github.com/pbroadbery/fricas-aldor-types.

If anyone is interested in improving either the plugin (java) or the type
inference bit (aldor), or the aldor/java interface (mostly C), please let
me know.  There's a lot of additional functionality that could be added.

Equally, suggestions for improvements welcome.

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [aldor-devel] Re: [fricas-devel] interpreter/spad/aldor grammar for atom

[Peter Broadbery]

On 31 March 2017 at 09:28, Martin Baker  wrote:
>
> On 30/03/17 23:25, Ralf Hemmecke wrote:
>>
>> On 03/30/2017 10:59 PM, Peter Broadbery wrote:
>>>
>>> Sorry - somewhat unclear.. The plugin is fairly good for spad files and 
>>> shows ++
>>> comments for domains, without any pre-processing.. In the java world the
>>> corresponding /** comments are turned into html with a bit more markup. This
>>> could potentially happen for spad, would "just" be a question of being able 
>>> to
>>> generate the appropriate markup and link to it.  As I understand it, the api
>>> docs on the .io site contain the right html.
>
>
> This may be irrelevant or off topic but, since you mention ++ comments and 
> fricas.github.io, I have some views on the content if not the markup.
>
> In my recent attempts to understand permgrps.spad I have thought about what 
> meta information would be useful to someone new to the code, both user or 
> developer.
>
> One of the most important things for me, in understanding a function, is 
> information about the parameters and return value of a function. If I am very 
> clear about the inputs and outputs I can often work out the bits in-between. 
> This information can be coded in the /** comments of java so I guess the java 
> language designers agree with me on this issue.
>

Yes, being able to document parameters is a good thing.. although it
ought to be optional to cover cases where the parameters are
"obvious".

> Another thing I would really like is links (coded as URLs) to other sources 
> of information about a given domain, function, etc. In FriCAS there are so 
> many potential places where documentation/tutorial/explanation may, or may 
> not be, found. It is a time consuming process just to find out if there is 
> any information known. Even if (as often happens) the only explanation is a 
> post from Waldek then I think there should be a link to it.
>

Agreed that a link is helpful, but I agree with other folks that
having too much in the way of ++ comments is distracting.  If the
comment is short or very important, then it belongs, otherwise maybe
in another document.  One thing that is possible is to index
documentation files, and use this index to show links to relevant
documentation.  This could also work for .input files.

> Another thing I would like coded in ++ comments and picked up by .io is local 
> in addition to exported metadata. I suspect this would be harder to do and 
> get away from the original intention. However I would like to be able to 
> drill down to information about Rep and local functions.
>

Well, implementation documentation can be important, and isn't part of
the exports.. so ideally the two could be linked in some way (I'm in
handwave mode, but it can be done where the implementation matches the
export).


> Sorry if this is off-topic but if there is any chance of some of this 
> happening then its worth mentioning it.
>

I'd like to do some of it, but do have time constraints, and don't
really know enough about axiom's internals to know what's possible.
Tweaking aldor is a bit easier for me.


> Martin B
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [aldor-devel] Re: [fricas-devel] interpreter/spad/aldor grammar for atom

[Peter Broadbery]

Sorry - somewhat unclear.. The plugin is fairly good for spad files and
shows ++ comments for domains, without any pre-processing.. In the java
world the corresponding /** comments are turned into html with a bit more
markup. This could potentially happen for spad, would "just" be a question
of being able to generate the appropriate markup and link to it.  As I
understand it, the api docs on the .io site contain the right html.  It's
entirely possible that I'm barking up the wrong alley of course.

Obviously it'll be clearer if you give it a go as it is now.

One of the reasons I'm trying to get the .spad docs right is that I'm not
altogether happy with the ALDOC style comments in aldor, but not sure on a
final form.  So seeing what works in .spad will help.


On 30 March 2017 at 21:24, Ralf Hemmecke  wrote:

> > To switch subjects slightly, I would like it to use some of the work
> that has
> > gone into the fricas.github.io  docs, as the
> plugin
> > shows raw text in docs at the moment.  There is a fair amount to
> investigate
> > here, if anyone is interested.
>
> What exactly do you mean here?
>
> Ralf
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [aldor-devel] Re: [fricas-devel] interpreter/spad/aldor grammar for atom

[Peter Broadbery]

I would be interested in seeing what atom can do (not really heard of it
before now tbh).. From my experience with the intellij lexer/grammar, the
easy part (relatively) is lexing and parsing.. the trickier part is
recognising indented blocks.  Would be interested in seeing how your
grammar works.

The intellij-idea plugin linked above is somewhat functional with some
syntax highlighting (it's easy to do in intellij, but one shouldn't overdo
it).  The eclipse one has foundered; I think I spent too much time trying
to get building to work automatically.. the intellij version gives up on
that and relies on makefiles doing the right thing.

The IDE approach can be very powerful when compared to a text editor; being
able to see docs for symbols without having to switch contexts is great, as
well as searching for functions by name.  Internally, the IDE has a full
view of the abstract syntax for any file; this can be used for all sorts of
things - basic semantic checks, some refactorings, documentation, basic
type extraction.  Downside is that it can feel slower.  Some of that is
inevitable due to having to reparse files more completely, of course.

As an aside, writing intellij extensions feels quite rewarding; one notices
a feature in some other extension, and twisting it into a form for spad or
aldor often turns out easier than expected.

To switch subjects slightly, I would like it to use some of the work that
has gone into the  fricas.github.io docs, as the plugin shows raw text in
docs at the moment.  There is a fair amount to investigate here, if anyone
is interested.

Peter



On 30 March 2017 at 17:28, Martin Baker  wrote:

> On 30/03/17 16:48, Bill Page wrote:
>
>> I have been playing with defining a language package for atom to
>> provide syntax highlighting and other edit functions for spad.  I have
>> a few simple things working. Is anyone else interested in using atom
>> this way? Does anyone have more experience with doing this sort of
>> thing in atom? I think it could eventually provide a good modern
>> alternative to emacs mode.
>>
>
> I am curious, what are the pros and cons of using a hackable editor to do
> this rather than an IDE as Peter Broadbery is doing:
>
> https://github.com/pbroadbery/aldor-eclipse
> https://github.com/pbroadbery/aldor-idea-plugin
>
> I am guessing that an editor is easier to start with but an IDE would
> ultimately be more powerful, is this guess correct?
>
> Martin B
>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Re: [aldor-devel] foldl and foldr

[Peter Broadbery]

On 14 Feb 2017 08:03, "Ralf Hemmecke"  wrote:

On 02/14/2017 08:38 AM, Peter Broadbery wrote:
> Interesting.  It definitely does work in .spad files (search for ^+\[).

Oh...

https://github.com/fricas/fricas/blob/master/src/algebra/aggcat.spad#L146

count(f : S -> Boolean, c : %) == _+/[1 for x in parts c | f x]

Then it even looks like a compiler builtin in FriCAS, if it appears
already in aggcat.spad.

Maybe FriCAS should also make this into a library feature?

> In any case,  as written it's left to right. There's an argument that it
should
> be undefined - ie require an associative argument (for parallel
accumulation)
> but that is likely to be more work than I have time for at the moment.

Peter, that's not urgent. I just wanted to make some comments that
related to your aldor-patch series.


Thanks - will add a fold and foldr as then '/' can be left as possibly
needing an associative argument.

Will be after the current patch is merged.


Ralf

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: [aldor-devel] foldl and foldr

[Peter Broadbery]

Interesting.  It definitely does work in .spad files (search for ^+\[).

In any case,  as written it's left to right. There's an argument that it
should be undefined - ie require an associative argument (for parallel
accumulation) but that is likely to be more work than I have time for at
the moment.

On 14 Feb 2017 07:28, "Ralf Hemmecke"  wrote:

Can it be that this /-fold-notation is interpreter-only in FriCAS?

fricas/src/algebra> grep '^[  "_]*/[  "]*:' *.spad
catdef.spad:  "/": (%,%) -> %
catdef.spad:  "/": (%,%) -> %   ++ x/y is the same as x
times the inverse of y.
catdef.spad:"/"  : (%, S) -> %
equation1.spad:  "/": (%, %) -> %
ffnb.spad:  "/"   :(VGF,VGF) -> VGF
float.spad:   _/  : (%, I) -> %
fraction.spad:  _/ : (%, R) -> %
fraction.spad:  _/ : (M, R) -> %
fraction.spad:  _/ : (%, R) -> %
fraction.spad:  _/ : (A, R) -> %
fraction.spad:_/ : (S, S) -> %
fspace.spad: "/"   : (MP, MP) -> %
mantepse.spad:  _/ : (%, %) -> %
mantepse.spad:  _/ : (%, %) -> %
matcat.spad:   "/": (%,R) -> %
matcat.spad:  "/": (%,R) -> %
mkfunc.spad:"/"  : (%, %) -> %
outform.spad:"/": (%, %) -> %
pattern.spad:    "/"  : (%, %) -> %
sf.spad:  _/   : (%, Integer) -> %
sttaylor.spad:"/"  : (ST A,ST A) -> ST A
xlpoly.spad:   "/"   :  (%,R) -> %

Ralf

On 02/13/2017 11:29 PM, Peter Broadbery wrote:
> It should match axiom's notation. Will check against it and document-
unless you
> want to take a look?
>
> On 13 Feb 2017 21:01, "Ralf Hemmecke"  <mailto:r...@hemmecke.org>> wrote:
>
> Hi Peter,
>
> In 5dae29765f95c0c127034b87ecbd78d8dc77150f you touch the file
> lib/aldor/src/datastruc/sal_fold.as
>
> I would probably have introduced the names foldl and foldr.
>
> Suppose Z==>Integer and that I have a non-associative function
f:(Z,Z)->Z.
>
> Without documentation, I don't know whether
>
>f / [1,2,3,4]
>
> is equivalent to
>
>f(1, f(2, f(3, 4)))
>
> or to
>
>f(f(f(1, 2), 3), 4)
>
> Doesn't make that the "/" notation useless?
>
> I can probably live with using \ for the second fold direction, but
not
> without documentation for either of them.
>
> Ralf

--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] fricas-aldor does not compile

[Peter Broadbery]

The 'with' does make a difference (it shouldn''t, of course).

There's a patch I missed - apply it manually as I have edited out an
unrelated change.

diff --git a/src/aldor/Makefile.in b/src/aldor/Makefile.in
index ae7a8df..b419038 100644
--- a/src/aldor/Makefile.in
+++ b/src/aldor/Makefile.in
@@ -41,12 +41,11 @@ INTERPSYS = DAASE=$(fricas_targetdir) FRICAS_INITFILE=''
-axextend.as:
-$(XCAT) $(ALDORBASICS)/$@ | \
-sed -e '/^extend Matrix/ s/Ring/with {SemiRng;AbelianMonoid}/' > $@
+axextend.as: $(ALDORBASICS)/axextend.as
+$(XCAT) $(ALDORBASICS)/$@ > @

-minimach.as:
+minimach.as: $(ALDORBASICS)/minimach.as
 $(XCAT) $(ALDORBASICS)/$@ | \
 sed -e 's/^#.*//;s/Language;/AxiomLib;inline from AxiomLib;/' > $@


On 19 August 2016 at 10:24, Ralf Hemmecke  wrote:
> On 08/19/2016 10:57 AM, Peter Broadbery wrote:
>> this should do the job:
>>
>> - src/aldor/aldor/axextend.as 
>> -
>> index 1a080bf..4d119ad 100644
>> @@ -561,7 +561,7 @@ extend Vector(S: Type): with {
>>  (rep x).(dec n) := v pretend BVal;
>>  }
>>
>> -extend Matrix(R: with {SemiRng;AbelianMonoid}): with {
>> +extend Matrix(R: AbelianMonoid): with {
>>  apply:(%, Integer, Integer)-> R;
>>  set!: (%, Integer, Integer, R) -> R;
>>  qelt:(%, Integer, Integer)-> R;
>>
>>  src/aldor/initlist.as 
>> 
>> index 6342230..60941e1 100644
>> @@ -46,5 +46,5 @@ export Vector: (T: Type)
>>   -> with;
>>
>>  export Factored:   (T: IntegralDomain) -> IntegralDomain;
>>  export Fraction:   (T: IntegralDomain) -> Field;
>> -export Matrix: (T: with {SemiRng;AbelianMonoid}) -> 
>> with;
>> +export Matrix: (T: AbelianMonoid) -> with;
>>  export SparseUnivariatePolynomial: (T: with {SemiRng;AbelianMonoid})
>> -> IntegralDomain;
>
> Yes, I've already found that. But it still leads to ... (see below).
>
> Well, I have
>
> export Matrix: (T: with {AbelianMonoid}) -> with;
>
> but that shouldn't make a difference.
>
> I'll try to figure out how I can get closer to the problem, but
> "segmentation violation"... Ufff...
>
> Ralf
>
> make -f Makefile2 aldor_srcs="lang minimach boolean0 axextend axlit
> subsetc"
> GENAX="/home/hemmecke/g/fricas-bisect/fricas/src/aldor/gendepap.lsp"
> make[1]: Entering directory
> '/home/hemmecke/scratch/build/fricas-bisect/build/6fed71e291469fd0b3e46f1335f07f6cc4d339db_2016-08-19_10-14-53/src/aldor'
> mkdir -p ao
> touch -t 19990101 ao/.dir
> aldor  -Y al -L AxiomLib=axiom_axextend -fao=ao/axextend.ao ap/axextend.ap
> Program fault (segmentation violation).#1 (Error) Program fault
> (segmentation violation).
> Makefile2:224: recipe for target 'ao/axextend.ao' failed
> rm ao/.dir
> make[1]: Leaving directory
> '/home/hemmecke/scratch/build/fricas-bisect/build/6fed71e291469fd0b3e46f1335f07f6cc4d339db_2016-08-19_10-14-53/src/aldor'
> Makefile:434: recipe for target 'al/libaxiom.al' failed
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] fricas-aldor does not compile

[Peter Broadbery]

this should do the job:

- src/aldor/aldor/axextend.as -
index 1a080bf..4d119ad 100644
@@ -561,7 +561,7 @@ extend Vector(S: Type): with {
 (rep x).(dec n) := v pretend BVal;
 }

-extend Matrix(R: with {SemiRng;AbelianMonoid}): with {
+extend Matrix(R: AbelianMonoid): with {
 apply:(%, Integer, Integer)-> R;
 set!: (%, Integer, Integer, R) -> R;
 qelt:(%, Integer, Integer)-> R;

 src/aldor/initlist.as 
index 6342230..60941e1 100644
@@ -46,5 +46,5 @@ export Vector: (T: Type)
  -> with;

 export Factored:   (T: IntegralDomain) -> IntegralDomain;
 export Fraction:   (T: IntegralDomain) -> Field;
-export Matrix: (T: with {SemiRng;AbelianMonoid}) -> with;
+export Matrix: (T: AbelianMonoid) -> with;
 export SparseUnivariatePolynomial: (T: with {SemiRng;AbelianMonoid})
-> IntegralDomain;




On 19 August 2016 at 08:45, Ralf Hemmecke  wrote:
> I just tried to compile the fricas-aldor interface. It fails. No time at
> the moment, but I guess it is in connection with the latest
> generalization of the argument of Matrix.
>
> Ralf
>
> #1 (Error) Argument 1 of `Matrix' did not match any possible parameter type.
> The rejected type is AbelianMonoid.
> Expected type Join(SemiRng, AbelianMonoid) with .
>
> (Message Preview)
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] aldor compilation of fricas fails

[Peter Broadbery]

Some are for cases of "if % has Foo then   Xyz (%)" which are still
problematic.  There's a very good chance that some more special cases are
no longer required.
On 11 May 2016 11:03, "Ralf Hemmecke"  wrote:

> There's quite a few "X pretend Y" clauses being generated too.. it
> might be possible to lose them.

Yes, I've seen those "pretend"s. Some of them I had to introduce myself
(as far as I remember). But the were of generic nature, i.e., not
dependent on some specific type name, but rather due to the fact that
the aldor compiler would otherwise complain.

However, I also see a few special typenames in connection with
"pretend".  Maybe I can remove them in the near future.

Ralf

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] aldor compilation of fricas fails

[Peter Broadbery]

It looks as if it's worth removing - it's probably a hack around an
old compiler limitation (just tried it, and the algebra compiled at
least - not tested it).

There's quite a few "X pretend Y" clauses being generated too.. it
might be possible to lose them.


On 10 May 2016 at 16:54, Ralf Hemmecke  wrote:
> Hi Peter,
>
> sorry to bother you, but I guess, you might know best why the this line
> (which does special treatment of StreamAggregate and
> FiniteLinearAggregate argument types) is in the code.
>
> https://github.com/fricas/fricas/blob/master/src/interp/ax.boot#L209O
>
> --
> axFormatDecl(sym, type) ==
>if sym = '$ then sym := '%
>opOf type in '(StreamAggregate FiniteLinearAggregate) =>
> ['Declare, sym, 'Type]
>['Declare, sym, axFormatType type]
> --
>
> Do you think I should try to remove it or do you remember what
> difficulties arise if these types are not mapped to "Type"?
>
> Thanks in advance
> Ralf

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] BUG: (Aldor) "if % has shallowlyMutable then" not honoured

[Peter Broadbery]

Turns out this was easier to fix in aldor than I expected.. will push a
small patch,  (plus a collection of bug fixes)in a couple of days.
Hi Peter,

Thank you for looking into the details.

On 11/20/2015 07:30 AM, Peter Broadbery wrote:
> Hi Ralf,
>
> I took a look at this and it's due to the way ELTAGG is translated to
> aldor - the definition of the default definition of qsetelt! in the
> generated ATAGG.ap is unconditional, and this is enough to make the
> export unconditional.  It's probably feasible to fix this in the
> compiler.

You mean "fix the SPAD compiler"? Or is the Aldor compiler doing
something wrong. The .ap has probably more to do with Aldor than with spad.

> Alternativey, the generated code should say 'if % has
> shallowllyMutable then { qsetelt!: ...; default qsetelt!(): ... }',
> which will give the desired result.

What exactly can I do? I don't understand that this is an alternative to
fixing the Aldor compiler?

Ralf

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] BUG: (Aldor) "if % has shallowlyMutable then" not honoured

[Peter Broadbery]

Hi Ralf,

I took a look at this and it's due to the way ELTAGG is translated to
aldor - the definition of the default definition of qsetelt! in the
generated ATAGG.ap is unconditional, and this is enough to make the
export unconditional.  It's probably feasible to fix this in the
compiler.  Alternativey, the generated code should say 'if % has
shallowllyMutable then { qsetelt!: ...; default qsetelt!(): ... }',
which will give the desired result.

Peter

On 18 November 2015 at 10:59, Ralf Hemmecke  wrote:
> Hi,
>
> the following is probably a question to Peter.
>
> The program below copiles fine in FriCAS using the Aldor compiler. It
> also runs perfectly well.
>
> I wanted to translate it into SPAD code, but failed.
>
> The reason is that the respective program (yes, I use streams then)
> complains about the line
>
> qsetelt!(d, i, e);
>
> And the SPAD compiler is right here.
>
> ** comp fails at level 2 with expression: **
> error in function lists
>
> (SEQ
>  (LET |d|
>(|first| |s|))
>  (LET |s|
>(|rest| |s|))
>  | << | (|qsetelt!| |d| |i| |e|) | >> | (|exit| 1 (|cons| |d| |z|)))
> ** level 2  **
> $x:= (qsetelt! d i e)
> $m:= NoValueMode
> $f:=
> |s| # . #1=#) (|d| #) (#:G5078 # #) (|s| . #1#) ...)))
>
>>> Apparent user error:
>not known that (DirectProduct n (Integer)) has (has (DirectProduct n
> (Integer)) (shallowlyMutable))
>
> If one reads the documentation of DirectProduct
> http://fricas.github.io/api/DirectProduct
> it says that no updating functions are provided. So that setelt! is not
> implemented is on purpose.
>
> But obviously via inheritance we get from EltableAggregate(Integer, R)
>
>   if % has shallowlyMutable then
>   qsetelt!: (%, Integer, R) -> R
>
> So SPAD takes into account that % does not have shallowlyMutable, but
> Aldor somehow ignores that fact.
>
> That's not a terribly important to me, I just wanted to let you know.
>
> Ralf
>
>
> ===
> #include "axiom"
>
> N ==> NonNegativeInteger;
> Z ==> Integer;
> DZ ==> DirectProduct(n, Z);
>
> Lists(n: N): with {
> lists: (Z, DZ) -> List DZ
> } == add {
> lists(deg: Z, i: Z, kappa: DZ, dz: DZ): Generator DZ == generate {
> zero? deg => yield copy dz;
> zero? i => {}; -- deg is non-zero, so don't yield anything.
> for e in 0..kappa.i - 1 repeat
> for d in lists(deg-e, i-1, kappa, dz) repeat {
> qsetelt!(d, i, e);
> yield d
> }
> }
> lists(deg: Z, kappa: DZ): List DZ == {
> [d for d in lists(deg, n::Integer, kappa, 0::DZ)];
> }
> }
> 
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Improved Error messages of Compiler?

[Peter Broadbery]

I started work on it, but was sidetracked.. The easy part is to get errors
into eclipse with the correct lines marked (I think it was working,  if
clunky) and some kind of work flow. Projects could generate lisp for fricas
easily enough.

More difficult is a browser for types, and it seemed a waste to reimplement
in java.  Trying aldor at the moment, but obviously making slow progress.
On 8 Nov 2015 18:37, "Martin Baker"  wrote:

> On 08/11/15 13:18, Prof. Dr. Johannes Grabmeier privat wrote:
>
>> I once thought about starting a project to make an Eclipse Environment
>> for programming in AXIOM/FriCAS to get e.g. stump implementation
>> automatically. If this is done first, I could support Ralfs idea. Anyone
>> interested in such a project?
>>
>
> I am curious about what you had in mind here?
>
> Were you thinking about something like Peter Broadberys Eclipse
> development environment for Aldor:
> https://github.com/pbroadbery/aldor-eclipse
>
> I think this is mostly a front end for existing programs. So it would
> still need C code for Aldor (or Lisp if it was modified for FriCAS). So I
> guess this would not change the error messages generated by those programs.
>
> I attempted to write a more native editor for Aldor and FriCAS here:
> https://github.com/martinbaker/euclideanspace
> This managed to parse (not compile) a surprisingly high proportion of
> categories and domains, even in FriCAS. I doubt if it could ever be 100%
> since it uses a conventional parser as opposed to Pratt parser which seems
> impossible to predict exactly.
>
> Martin
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Improved Error messages of Compiler?

[Peter Broadbery]

Aldor will tell you if a definition of a domain does not match its
declaration.  It does track where symbols are defined and whether it's
in a default block and under what condition it is defined.  To get it
right one does need quite a lot of machinery, and I'm not sure aldor
is correct in all cases.



On 8 November 2015 at 21:16, Ralf Hemmecke  wrote:
 Well, finding what is implemented is the hard part.
>>>
>>> Oh, that surprises me a bit, since I thought that the compiler knows
>>> that. Or has a way to figure it out. But you are the compiler expert and
>>> know probably better that this is not that easy.
>>
>> No, compiler has no idea what is implemented.  It just looks
>> at declarations happily accepting calls to routines that
>> are declared but unimplemented.  It is runtime job to find
>> implementations and accoridingly you get errors at runtime...
>
> Hmmm... then again, I like Aldor better. Don't ask me how it does it,
> but I still believe that the Aldor compiler will reject a program if
> some signature is not implemented.
>
> I may be wrong. Peter, are you listening?
>
> Ralf
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] FriCAS-aldor problem

[Peter Broadbery]

Hi Ralf,

Not sure this has ever been supported, but I might have a look over
the weekend to see if it is anything obvious.  Failing that, I expect
the next best thing would be to warn the user when loading a file
which exports non-type valued objects.

Peter

On 25 October 2015 at 11:35, Ralf Hemmecke  wrote:
> Hi,
>
> I've taken die sieve program and compiled it in FriCAS. Works fine and
> it seems to work perfecly, but what I don't understand is why the assignment
>
> mysieve: NonNegativeInteger -> NonNegativeInteger := sieve
>
> gives an error.
>
> For
>
> mysieve2: NonNegativeInteger -> NonNegativeInteger := sieve2
>
> on the other hand, i.e., when sieve2 is wrapped into a package
> everything works fine.
>
> I faintly remember that there was a problem with top-level functions
> from Aldor. True?
>
> Can this easily be cured or should we currently have the suggestion that
> there should be no aldor toplevel functions?
>
> Ralf
>
>
> 
> --
> -- sieve.as: A prime number sieve to count primes <= n.
> --
> #include "axiom"
>
> import from Boolean, NonNegativeInteger, Integer;
>
> sieve(n: NonNegativeInteger): NonNegativeInteger  == {
> isprime: PrimitiveArray Boolean := new(n+1, true);
>
> np: NonNegativeInteger := 0;
> for p in 2..n | isprime(p::Integer) repeat {
> np := np + 1;
> for i in 2*p..n by p::Integer repeat {
> isprime(i::Integer) := false;
> }
> }
> np
> }
> 
>
> trex:~/scratch>fricas -nosman
> Checking for foreign routines
> AXIOM="/home/hemmecke/g/fricas-bisect/install/lib/fricas/target/x86_64-unknown-linux"
> spad-lib="/home/hemmecke/g/fricas-bisect/install/lib/fricas/target/x86_64-unknown-linux/lib/libspad.so"
> foreign routines found
> openServer result -2
>FriCAS Computer Algebra System
>   Version: FriCAS 10564c5be33b4d74cd053ffdadd42f347f3d06c0
>   Timestamp: Fri Oct 23 23:00:22 CEST 2015
> -
>Issue )copyright to view copyright notices.
>Issue )summary for a summary of useful system commands.
>Issue )quit to leave FriCAS and return to shell.
> -
>
> (1) -> )co sieve.as
>Compiling FriCAS source code from file
>   /home/hemmecke/scratch/sieve.as using AXIOM-XL compiler and
>   options
> -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
> $AXIOM/algebra -I $AXIOM/algebra
>   Use the system command )set compiler args to change these
>   options.
>Compiling Lisp source code from file ./sieve.lsp
>Issuing )library command for sieve
>Reading /home/hemmecke/scratch/sieve.asy
> (1) -> sieve 20
>
>(1)  8
> Type:
> PositiveInteger
> (2) -> mysieve: NonNegativeInteger -> NonNegativeInteger := sieve
>
>
>>> System error:
>The value FOAM-USER::|G-sieve_sieve_825325564| is not of type LIST.
>
> ==
> #include "axiom"
>
> import from Boolean, NonNegativeInteger, Integer;
>
> Sieve2(): with {
> sieve2: NonNegativeInteger -> NonNegativeInteger;
> } == add {
> sieve2(n: NonNegativeInteger): NonNegativeInteger  == {
> isprime: PrimitiveArray Boolean := new(n+1, true);
>
> np: NonNegativeInteger := 0;
> for p in 2..n | isprime(p::Integer) repeat {
> np := np + 1;
> for i in 2*p..n by p::Integer repeat {
> isprime(i::Integer) := false;
> }
> }
> np
> }
> }
> =
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] lifting of properties to Record

[Peter Broadbery]

It is almost possible in aldor, given Record(T: Tuple Type), one could say
'if _and(t has PrimitiveType for t in T) then PrimitiveType'. This won't
work at the moment, but I think the restriction on conditional exports
using 'has' isn't required.  I'll experiment a bit later.
On Sep 10, 2015 6:20 AM, "Ralf Hemmecke"  wrote:

> > If all fields have SetCategory, then record should have SetCategory
> > too.  Currently Spad cheats and unconditionally asserts SetCategory.
> > If Aldor unconditionally considers records to _not_ have
> > SetCategory, then this looks like serious limitation of Aldor.
>
> The SPAD compiler cheats. But even if it doesn't, your rule looks like
> "the spad compiler knows SetCategory" and so SetCategory would be more
> or less a type belonging to the Spad Language and not to the library.
>
> Would you agree that record should also export BasicType if all its
> fields have BasicType? Or Monoid if all its fields have Monoid? Where do
> you draw the line? What if I produce another library where my
> "SetCategory" type is called "Setcategory" or simply "Set"?
>
> Some properties can be lifted, but some not. You are right that Aldor
> does not allow to express such a lifting statement in terms of the
> language, but still I'd prefer rather extend the language to express
> such lifting (even if the number of fields of Record is arbitrary)
> rather than including library knowledge into the compiler.
>
> Just my 2 cents.
>
> Ralf
>
> PS: I'll try to produce a patch to change Set to List in lodof2.spad.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: Union(X, "failed") and Aldor

[Peter Broadbery]

I think the error is due to a disagreement on how enumerations are
handled - in aldor they are integers, but in the spad world they look
to be strings (this is a bit of a guess, just looking at the error
above).  I've not really looked at how the interop code works in this
case, but I expect that fixing it is non-trivial.

The partial type would probably make a few things clearer in the spad
world, but no idea how far reaching a change that would work out to
be.

Peter

On 25 March 2015 at 15:24, Ralf Hemmecke  wrote:
> Hi Peter,
>
> Just out of curiosity, I don't really need a treatment for the following
> problem.
>
> The attached program compiles fine and it seems that foo also works
> great. However, bar is not really working for the "failed" case.
>
> Am I right that this is simply due to the fact that FriCAS has no
> 'Enumeration' in
>
>   U ==> Union(value1: V, failed: Enumeration(failed: Type));
>
> and thus doesn't know what to do with the result?
>
> I somehow get the feeling that FriCAS should introduce something like
> Partial in Aldor instead of this funny type Union(X,"failed").
>
> https://github.com/pippijn/aldor/blob/master/aldor/lib/aldor/src/base/sal_partial.as#L46
>
> Ralf
>
> (1) -> R==>Integer
>Type:
> Void
> (2) -> V==>OrderedVariableList(['x,'y])
>Type:
> Void
> (3) -> P==> SparseMultivariatePolynomial(R, V)
>Type:
> Void
> (4) -> x: P := 'x::P
>
> (19) -> bar x
>
>(19)  x
> Type: Union(value1: OrderedVariableList([x,y]),...)
>
> (19) -> bar(0$P)
>
>
>>> System error:
>The value "failed" is not of type SB-INT:INDEX.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] Re: extend from Aldor in FriCAS

[Peter Broadbery]

Agreed, it's a problem of adding runtime support.  Sadly, it would
have to fit the current mechanism for domain lookup.

The detail of how domain lookup and extensions interact is fairly
complicated, and I don't recall it exactly - basically there's a
couple of functions that need to exist in the axiom domain vector, and
I don't know if they are implemented (it'll be somewhere in
interop.boot), nor do I know exactly what they should do (see
runtime.as for the aldor implementation).  Once the extend "works" in
the aldor world (ie. you can use an extended axiom domain in aldor
code), it should work in axiom (worst case is that you'd need to force
all the exports somehow).

All that said, I have very little time to look at this at the moment.
If you take a look at the generated lisp you might be able to see how
domains are currently given to axiom.

Peter



On 3 March 2015 at 21:59, Waldek Hebisch  wrote:
> Peter Broadbery wrote:
>>
>> Did this ever work?  I can't remember to be honest.
>
> AFAIK 'extend' never worked on Axiom/FriCAS domains.
>
>> In either case it's not going to be an easy fix.
>
> It seems to be problem of adding runtime support.  Basically,
> each domain needs to be represented by a chain of extensions.
> Most of real work probably could be delegated to existing support of
> inheritance (add domain).  Of course the 'interp' code would
> need enhancement to understand Aldor 'extend'.  In
> Axiom/FriCAS there is extra difficulty:
>
> )lib INT
>
> is supposed to wipe old version of INT and replace it by a new
> version.  In case of Aldor style 'extend' semantics is not clear:
> do the user want to load _new_ extenstion on top of old one?
> Or is the intent to wipe old extension and repleace it by
> new version.  The problem is because extensions are
> effectively anonymous, so one way would be to require names
> for extensions (but that would be incompatible with current
> Aldor).   Alternatively, we could have some protocol, for
> example that reloading INT wipes all extensions.  Or maybe
> extra command to unload extensions.  But without way to identify
> extensions this looks clumsy.  Maybe produce some machine
> generated identifier during load which user could use to unload
> specific extension?
>
> --
>   Waldek Hebisch
> hebi...@math.uni.wroc.pl
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: extend from Aldor in FriCAS

[Peter Broadbery]

Did this ever work?  I can't remember to be honest.

In either case it's not going to be an easy fix.

Peter

On 2 March 2015 at 20:31, Ralf Hemmecke  wrote:
> The program
>
> #include "axiom"
>
> extend Integer: with {
> foo: (%, %) -> %
> } == add {
> foo(x: %, y: %): % == x*x + y*y;
> }
>
> compiles fine inside fricas, but I cannot use it. :-(
>
> Does someone have an idea how to make it work?
> (Yes, I want to keep the name Integer and I don't want to rewrite
> integer.spad.)
>
> Thanks in advance.
>
> Ralf
>
> (1) -> a: Integer := 3
>
>(1)  3
> Type:
> Integer
> (2) -> b: Integer := 3
>
>(2)  3
> Type:
> Integer
> (3) -> )cd ..
>The current FriCAS default directory is
>   /home/hemmecke/backup/git/spadunit
> (3) -> )co src/extendtst.as
>Compiling FriCAS source code from file
>   /home/hemmecke/backup/git/spadunit/src/extendtst.as using
>   AXIOM-XL compiler and options
> -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
> $AXIOM/algebra -I $AXIOM/algebra
>   Use the system command )set compiler args to change these
>   options.
>Compiling Lisp source code from file ./extendtst.lsp
>Issuing )library command for extendtst
>Reading /home/hemmecke/backup/git/spadunit/extendtst.asy
>Integer is now explicitly exposed in frame initial
>Integer will be automatically loaded when needed from
>   /home/hemmecke/backup/git/spadunit/extendtst
> (3) -> a+b
>
>
>>> System error:
>The function FOAM-USER::|fiRaiseException| is undefined.
>
> (3) -> foo(a,b)
>
>>> System error:
>The function FOAM-USER::|fiRaiseException| is undefined.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [fricas-devel] SpadUnit

[Peter Broadbery]

Hi Ralf,

Looks interesting - I was doing something similar in the aldor code
base, but haven't got very far.. The idea was that the SpadUnit type
(or Assert, as it is known in the aldor library) would have
conditionals to include things like assertNotZero,
assertGreaterThan',etc as the target type allowed.

I think my next extension would be something that would collect
errors, rather than throwing an immediate exception (no time to work
on it at the moment though).  Anyways, the unit approach seems to be
less fragile than the output comparison stuff.

Peter


On 18 January 2015 at 20:38, Ralf Hemmecke  wrote:
> I'm currently working on a testing framework for PanAxiom.
>
> It's basically already working, so I'd like to get feedback, feature
> requests etc.
>
> https://github.com/hemmecke/spadunit
>
> Ralf
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

[fricas-devel] Re: [aldor-devel] Aldor in FriCAS (temporarily solved)

[Peter Broadbery]

I've added the 'remove downcasing' patch to my local tree;  will push later.

You had a whitespace cleanup patch as well which I'm not going to
commit - I think it's better to have a clear commit history, and only
adjust whitespace when it's closely tied to code being changed.


Peter

On Sun, Feb 9, 2014 at 6:03 PM, Ralf Hemmecke  wrote:
>>> Oh, my question was imprecise. I wanted to ask why you need a separate
>>> filename for each category/domain/package?
>>
>> It seems to me that Aldor in FriCAS as it works now is forcing us to use
>> separate files if we want these objects in different libraries, or am I
>> mistaken?
>
> No. I think you are right. But it's still unclear to me why you care
> about generating different libraries?
>
>>> I think it would be enough if all the mutual recursive constructors live
>>> in just one .lsp file (or .fasl or .o file).
>
>> Yes, that is what I was proposing but I thought that the current naming
>> method used in the Aldor interface would prevent me from doing that.
>
> I don't understand. What is done in aldor is: If constructors A,B,C are
> in file f.as then also A,B,C will be in f.lsp and f.asy. And that's
> enough for FriCAS.
>
> Why would you want anything different?
>
>
> Anyway, meanwhile I have a fix for the problem with not-all-lower-case
> filenames.
>
> One commit from here...
> https://github.com/hemmecke/fricas/commits/do-not-downcase-filename
>
> Two commits from there
> https://github.com/hemmecke/aldor/commits/no-global-tolower-foam
>
> The patches are pretty trivial since they only remove tolower from
> genfoam.c in Aldor and string-downcase from foam_l.lisp in FriCAS.
>
> I don't know whether I can be happy with that change.
>
> Pippijn, Peter, please check these patches. They change something in the
> generation of foam and thus have also impact on the C code generation.
> Unfortunately, I have no idea at all, why genfoam wanted to have
> lowercase there in the first place. I just hope that lowercase names are
> not imposed by something elsewhere.
>
> Ralf
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] Re: [aldor-devel] Aldor in FriCAS

[Peter Broadbery]

I guess the two should be kept in sync, but testing aldor against
libax0 gives almost no guarantees about what happens in when the code
is run.

For testing, calling (sb-ext:exit :code 1) will exit immediately with
a non-zero error code.  Put that (or whatever relevant axiom magic is
required) in a random package, and you're away.

Peter

On Thu, Feb 6, 2014 at 10:52 PM, Ralf Hemmecke  wrote:
> On 02/06/2014 11:03 PM, Peter Broadbery wrote:
>> Not sure about streamlining it (at least this week) but I'd prefer it
>> if the fricas build did not copy axextend and axlit from the aldor
>> distribution but instead  maintain them locally.
>
> As you can see, in the aldor tree there is only an additional "import
> from Boolean" in axllit and a missing change from Ring to "with
> {SemiRng;AbelianMonoid}" line 564 (see
> https://github.com/hemmecke/aldor/tree/sync-with-fricas). Otherwise only
> space changes. I think it would be good if we can keep those files in sync.
>
>> Setting up jenkins or similar to immediately do a fricas rebuild after
>> an aldor build is relatively easy, and would enable more thorough
>> testing.
>
> That would be great, but the problem is not only compilation. There
> should also be a few simple .as programs compiled and *run* to better
> detect nasty changes.
>
> The problem is that there is not yet that change in fricas that aborts
> fricas with a nonzero exit code if something breaks, i.e. writing
> testcases is currently not really supported.
>
> There are two commits waiting here.
> https://github.com/hemmecke/fricas/tree/test-framework
>
> Ralf
>
>> trex:~/g/fricas:fix-aldor-interface *%>git diff
> diff --git a/src/aldor/aldor/axlit.as b/src/aldor/aldor/axlit.as
> index 495f5fc..7acf697 100644
> --- a/src/aldor/aldor/axlit.as
> +++ b/src/aldor/aldor/axlit.as
> @@ -11,6 +11,7 @@
>
>  import from AxiomLib;
>  inline from AxiomLib;
> +import from Boolean;
>
>  macro {
>  rep x == x @ % pretend Rep;
> @@ -258,7 +259,7 @@ extend List (S: Type) : with {
> cons (x: S, y: %): % == AXL_-cons(x, y);
> setfirst!(x: %, y: S): S == AXL_-rplaca(x, y);
> setrest! (x: %, y: %): % == AXL_-rplacd(x, y);
> -
> +
> empty(): %   == AXL_-nilfn();
> empty?   (x: %): Bit == AXL_-null? x;
> test (x: %): Bit == not empty? x;
>
>
> g/aldor:sync-with-fricas %>git show --ignore-space-change
> commit 60ce6c61b4f86716180626f727cbffca2fcd6c35
> Author: Ralf Hemmecke 
> Date:   Thu Feb 6 21:44:13 2014 +0100
>
> sync with fricas version
>
> diff --git a/aldor/lib/ax0/src/axextend.as b/aldor/lib/ax0/src/axextend.as
> index bb0004f..1a080bf 100644
> --- a/aldor/lib/ax0/src/axextend.as
> +++ b/aldor/lib/ax0/src/axextend.as
> @@ -561,7 +561,7 @@ extend Vector(S: Type): with {
> (rep x).(dec n) := v pretend BVal;
>  }
>
> -extend Matrix(R: Ring): with {
> +extend Matrix(R: with {SemiRng;AbelianMonoid}): with {
> apply:  (%, Integer, Integer)-> R;
> set!:   (%, Integer, Integer, R) -> R;
> qelt:   (%, Integer, Integer)-> R;
> @@ -714,4 +714,3 @@ extend UniversalSegment (S: Type) : with {
> }
> }
>  }
> -
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] Re: [aldor-devel] Aldor in FriCAS

[Peter Broadbery]

Not sure about streamlining it (at least this week) but I'd prefer it
if the fricas build did not copy axextend and axlit from the aldor
distribution but instead  maintain them locally.

Setting up jenkins or similar to immediately do a fricas rebuild after
an aldor build is relatively easy, and would enable more thorough
testing.

Peter






On Thu, Feb 6, 2014 at 9:35 PM, Ralf Hemmecke  wrote:
> Thanks Bill for reporting this bug and thanks to Peter to point me to
> the axextend.as fix. I could now also find the setelt! fix.
>
> See the last two commits at
>
> https://github.com/hemmecke/fricas/commits/fix-aldor-interface
>
> with that, the program sieve.as compiles and runs fine.
>
> Waldek, can I commit to the SVN repo?
> Peter, it sounded as if you still wanted to streamline the axextend
> stuff. What's your opinion?
>
> Ralf
>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] Re: [aldor-devel] Aldor in FriCAS

[Peter Broadbery]

OK, just looked into this; the breaking change in aldor was that "and"
conditions are now respected properly (this changed sometime in
november, I think)... in the definition of segment th (in axextend.as)
ere is this piece of code:

ShouldHaveSegmentGenerator(S) ==>
S has OrderedSet and S has AbelianSemiGroup
and S has with { coerce: I -> S; }
which determines if UNISEG S should have a 'by' function (the error
message above indicates that it is not found)

And the third condition was never evaluated, but treated as
unconditionally true, so UNISEG NNI exported 'by' and 'generator'.

Now, NNI does not export coerce: I -> NNI, so the test fails, and so
UNISEG NNI does not come with a generator function.  The fix is to
change 'I -> S' in the above to 'I -> %', and it goes through
swimmingly.


I need to clean up the patch slightly, will push to a repo once that is done.

Peter

On Wed, Feb 5, 2014 at 5:22 PM, Bill Page  wrote:
> I just compiled the most recent Aldor from git trunk and then the most
> recent FriCAS source with the --enable-aldor option.  Everything
> seemed to go OK but I am no longer able to compile a simple Aldor
> example that I am quite sure used to work. As I recall I last
> successfully compiled this example on cloud.sagemath.com about 6
> months ago.  I just tried it again there but it seems that fricas is
> no longer compiled with the aldor option on that system.
>
> It has been a while since I tried to use Aldor in FriCAS. Am I doing
> something wrong or is something broken?
>
> ---
>
> wspage@suse:~> sbcl --version
> SBCL 1.1.15
>
> wspage@suse:~> gcc --version
> gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]
>
> wspage@suse:~> cat /etc/SuSE-release
> SUSE Linux Enterprise Server 11 (x86_64)
> VERSION = 11
> PATCHLEVEL = 3
>
> wspage@suse:~> uname -a
> Linux suse 3.0.101-0.8-default #1 SMP Fri Nov 1 12:51:09 UTC 2013
> (2417eb9) x86_64 x86_64 x86_64 GNU/Linux
>
> wspage@suse:~> aldor -version
> Aldor version 1.2.0 for LINUX(glibc2.10+) (debug version)
>
> wspage@suse:~> fricas
> Checking for foreign routines
> AXIOM="/usr/local/lib/fricas/target/x86_64-suse-linux"
> spad-lib="/usr/local/lib/fricas/target/x86_64-suse-linux/lib/libspad.so"
> foreign routines found
> openServer result 0
>FriCAS Computer Algebra System
>  Version: FriCAS 2013-09-27
>Timestamp: Wed Feb  5 08:34:56 EST 2014
> -
>Issue )copyright to view copyright notices.
>Issue )summary for a summary of useful system commands.
>Issue )quit to leave FriCAS and return to shell.
> -
>
>
> (1) -> )sys cat axiomSieve.as
> --
> -- sieve.as: A prime number sieve to count primes <= n.
> --
> #include "axiom.as"
>
> import from Boolean, NonNegativeInteger;
>
> sieve(n: NonNegativeInteger): NonNegativeInteger  == {
> isprime: PrimitiveArray Boolean := new(n, true);
>
> np := 0;
> for p in 2..n | isprime (p::Integer) repeat {
> np := np + 1;
> for i in 2*p..n by p::Integer repeat
> isprime(i::Integer) := false;
>
> }
> np
> }
>
> (1) -> )co axiomSieve.as
>Compiling FriCAS source code from file /home/wspage/axiomSieve.as
>   using AXIOM-XL compiler and options
> -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
> $AXIOM/algebra -I $AXIOM/algebra
>   Use the system command )set compiler args to change these
>   options.
> "/home/wspage/axiomSieve.as", line 12:
> for p in 2..n | isprime (p::Integer) repeat {
> ^...^
> [L12 C9] #1 (Error) There are no suitable meanings for the operator `p'.
> [L12 C13] #2 (Error) No meaning for identifier `p'.
>
> "/home/wspage/axiomSieve.as", line 14:
> for i in 2*p..n by p::Integer repeat
> isprime(i::Integer) := false;
> ^^
> [L14 C33] #3 (Error) There are no suitable meanings for the operator `by'.
> [L14 C54] #4 (Error) There are no suitable meanings for the operator `set!'.
>   There is no `set!' definition with this number of arguments.
>
>The )library system command was not called after compilation.
> (1) ->
>
> ---
>
> Note: Aldor it self compiles and runs a similar example natively.
>
> wspage@suse:~> cat aldorSieve.as
> --
> -- sieve.as: A prime number sieve to count primes <= n.
> --
> #include "aldor.as"
> #include "aldorio.as"
>
> import from Boolean, MachineInteger;
>
> sieve(n: MachineInteger): MachineInteger  == {
> isprime: PrimitiveArray Boolean := new(n, true);
>
> np := 0;
> for p in 2..n | isprime p repeat {
> np := np + 1;
> for i in 2*p..n by p repeat isprime i := false;
>
> }
> np
> }
>
> for i in 1..7 repeat {
> n := 10^i;
> stdout << "There are " << sieve n <

Re: [fricas-devel] sync with new aldor hash code

[Peter Broadbery]

I'm not sure what you mean by ancestors, fundamental ancestors and
parents - could you clarify?  Equally, what step is missing?

>From memory, I don't think anyone has really attempted to optimise the
lookup code, so it is almost certain it can be done better.  For
example, the recursive category expansion isn't needed, as long as one
can identify the categories that are interesting for a given
operation.  That said, I don't know enough about axiom's
representation of types to see exactly how that can be done.

Peter




On Fri, Nov 15, 2013 at 3:38 AM, Waldek Hebisch
 wrote:
>>
>> Dear Waldek,
>>
>> I've rebased Peter's pull request
>> https://github.com/hemmecke/fricas-svn/pull/8
>> on top of master and amended it a bit (adding changelog and the missing
>> foam_l.lisp part).
>>
>> https://github.com/hemmecke/fricas/commits/sync-with-aldor-hashcode
>>
>> Now funny.as works again in FriCAS. See the following thread.
>>
>> https://groups.google.com/forum/#!topic/aldor-devel/QwLnlBW5D38
>>
>> May I commit?
>
> In short: yes please go on.  However there are some issues
> related to the patch.  One thing is Aldor interface wants
> to have list of parents of given category.  Spad computes
> ancestors and fundamental ancestors and they seem more
> relevant than parents.  And Spad is doing this at compile
> time, it is not clear why Aldor wants this at runtime.
> Another thing is that during ancestor computation Spad
> removes several redundancies, what that patch is doing
> is similar but performs just one step and omits other.
> And at runtime Spad is quite care careful to avoid unneeded
> evaluation (in particular Spad can usually avoid evaluating
> categories).  So, there is bunch of questions why Aldor interface
> is doing such things and depending on answer we may wish to
> write quite diffent code.
>
> Now, why I am telling you to go on: answering questions will
> take time and IIUC the patch is important for resolving problems
> with Aldor interface.  In particular after applying patch
> we can test if interface works OK or has more problems.
>
> --
>   Waldek Hebisch
> hebi...@math.uni.wroc.pl
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] ALDORROOT

[Peter Broadbery]

Could the lookup be something like: $ALDOR_COMPILER (if present),
$(prefix)/bin/aldor (if present), then $PATH, with $(prefix) coming
from the configure command.  Not too concerned what the env. var is
called, as I will almost always argue that they shouldn't be used.

That way building into a shared prefix will work as expected, or it
can be picked up off the path.

Peter

Peter



On Thu, Nov 14, 2013 at 3:03 PM, Ralf Hemmecke  wrote:
>> AFAICS the simplest solution is to replace ALDORROOT by another
>> variable, say ALDOR_COMPILER (or maybe just ALDOR).  Then in
>> 'fricas' script we can do
>>
>> ALDOR_COMPILER = ${ALDOR_COMPILER:-aldor}
>>
>> And i-syscmd.boot use
>>
>> command :=
>>STRCONC(getEnv('"ALDOR_COMPILER"),_
>>  '" ", asharpArgs, '" ", namestring args)
>>
>> The point is that by default aldor will be taken from the PATH,
>> but if user want to override this, then simply defines appropriate
>> ALDOR_COMPILER.
>
> Accepted.
>
> I only have a problem with the name of the variable. I guess it would be
> better to prefix with 'FRICAS_' to make it clear that the variable
> belongs to FriCAS and does not give a conflict with a variable of that
> name issued in the future by the Aldor Project. Well, that's of course
> not a big issue. So I'm fine if the idea is realized with any name. I
> just wanted to raise my concerns.
>
> Thank you.
> Ralf
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to fricas-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] Re: [aldor-devel] Re: [aldor] Pab/devel (#85)

[Peter Broadbery]

Hi Ralf,

I've added a pull request onto your fricas github repo which makes the
algorithms line up again.  I'm not really wanting to lock down the
algorithm at the moment as we might change details in the future.
Ultimately, the calling system should have a way of discovering the
appropriate calculation, and then using that (an 'aldor --version'
would be sufficient, I guess).  Unfortunately I don't know the best
way to do this via lisp/boot.

In terms of what it does at the moment, in outline
- any unparameterised type hashes to the hash of the name of the type
- any parameterised type (other than Mapping) hashes to be combination
of its arguments, plus the hashcode of the constructor name (eg.
"List" for List X)
- any value which is not a type hashes to 7
- mappings hash to the hashcode of mapping combined with: return type
if present, a magic value, then the hashes of the argument types.
- Enumerations hash to the combination of the hashes of the names of the values.
- Union and Record hash to the combination of their arguments.

I've left off the definition of 'combination' and 'hash of a string'..
I had to change the former recently as it was too easy to get
collisions.  The other is probably ok for the moment.

There's a bunch of problems with the algorithm:
- The definition for mapping is very ugly
- The special rules for Record, Union and Enumeration should not be needed
- the non-types hashing to 7 thing puts a restriction on what can be
exported by a domain
- The whole idea of using hashcodes is a bit broken anyway - it should
be as fast to do name based lookup.

Peter


On Sun, Oct 6, 2013 at 11:08 PM, Ralf Hemmecke  wrote:
> Hello, in particular hi Peter and hi Waldek,
>
> Since Aldor is now free, wouldn't it make sense to put the hashing
> algorithm for function signatures on the table (i.e. identify where it
> is implemented and document it properly) and then use the *same*
> algorithm (maybe abstracted into a library) for aldor and fricas?
>
> Ralf
>
>
> On 10/06/2013 10:49 PM, pbroadbery wrote:
>> Add the hashcode changes (I changed it around to be slightly more axiom 
>> friendly.
>> Fix a few spurious bug() errors in terror.c - so code with a == (a: I): I 
>> +-> 2; a("string") gives a nice error
>> add ald_flags to the build.
>>
>> Plus a couple of random bugfixes.
>> You can merge this Pull Request by running:
>>
>>   git pull https://github.com/pippijn/aldor pab/devel
>>
>> Or you can view, comment on it, or merge it online at:
>>
>>   https://github.com/pippijn/aldor/pull/85
>>
>> -- Commit Summary --
>>
>>   * genfoam: Look at the type of the generator when unpacking a cross.
>>   * Add hashCombinePair function (leaving hashCombine to be used in strHash).
>>   * terror.c: Don't assume that an operator is immediately a Map tform.. 
>> we
>>   * terror.c: Just issue an error message when we don't have an exit type
>>   * Hashcode algo changed again (to be compatible with axiom's strHash). 
>>  Update
>>   * Add a function exploring hash functions - this was mostly for tracking
>>   * showexports: Dump the cascaded exports from a domain.
>>   * syme.c: Add 'symeExportingSyme' function to identify the original
>>   * Add ald_flags (a Bit Array datatype) to the build.  For some reason it
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [aldor-devel] Re: [fricas-devel] Problem with aldor interface

[Peter Broadbery]

Just sent a pull request for this
https://github.com/hemmecke/fricas-svn/pull/8 with this change, plus a
hashcode fix.  It's sufficient to make a couple of small examples work.

Please let send along other examples of broken aldor code.. I don't get a
lot of time to create examples.


Slightly unrelated: Is there any test framework at the lisp/boot level?
Being able to smoke test a change would be useful, I suspect.

Peter


On Wed, Sep 18, 2013 at 8:50 PM, Peter Broadbery wrote:

> I've just tried this example, and found that it breaks in three ways for
> me.
>
> Firstly, the aldor/axiom interop code gets itself into a loop looking up
> 'AbelianMonoid' from 'Ring'.  Short reason is that LeftModule % contains
> 'if R has AbelianMonoid then AbelianMonoid', and Ring is a LeftModule %.
> There's a new defn of oldAxiomPreCategoryParents below which seems to fix
> it.
>
> Second - the domain funny.as compiles with the definition of '*'
> removed.  Unless there's a default definition of '*' someplace (and there
> isn'), this is an aldor bug.
>
> Third, the scons  issue.  This looks to be a hashcode collision - probably
> made more likely by two non-type parameters being passed to ULS.. I'll have
> to experiment with a couple of variants, but it will mean a somewhat
> breaking change in the aldor/axiom interface.
>
> Peter
>
> oldAxiomPreCategoryParents(catform,dom) ==
>   vars := ["$",:rest GETDATABASE(opOf catform, 'CONSTRUCTORFORM)]
>   vals := [dom,:rest catform]
>   -- parents :=  GETDATABASE(opOf catform, 'PARENTS)
>   parents := parentsOf opOf catform
>   -- strip out forms listed both conditionally and unconditionally
>   unconditionalParents := []
>   filteredParents := []
>   for [cat, :pred] in parents repeat
>  if pred = true then
> unconditionalParents := [cat,:unconditionalParents]
> filteredParents := [[cat,:pred], :filteredParents]
>   for [cat, :pred] in parents repeat
>  if not pred = true and not member(cat, unconditionalParents) then
> filteredParents=[[cat,:pred], :filteredParents]
>   PROGV(vars, vals,
> LIST2VEC
>   [EVAL quoteCatOp cat for [cat,:pred] in filteredParents | EVAL pred])
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [aldor-devel] Re: [fricas-devel] Problem with aldor interface

[Peter Broadbery]

I've just tried this example, and found that it breaks in three ways for me.

Firstly, the aldor/axiom interop code gets itself into a loop looking up
'AbelianMonoid' from 'Ring'.  Short reason is that LeftModule % contains
'if R has AbelianMonoid then AbelianMonoid', and Ring is a LeftModule %.
There's a new defn of oldAxiomPreCategoryParents below which seems to fix
it.

Second - the domain funny.as compiles with the definition of '*' removed.
Unless there's a default definition of '*' someplace (and there isn'), this
is an aldor bug.

Third, the scons  issue.  This looks to be a hashcode collision - probably
made more likely by two non-type parameters being passed to ULS.. I'll have
to experiment with a couple of variants, but it will mean a somewhat
breaking change in the aldor/axiom interface.

Peter

oldAxiomPreCategoryParents(catform,dom) ==
  vars := ["$",:rest GETDATABASE(opOf catform, 'CONSTRUCTORFORM)]
  vals := [dom,:rest catform]
  -- parents :=  GETDATABASE(opOf catform, 'PARENTS)
  parents := parentsOf opOf catform
  -- strip out forms listed both conditionally and unconditionally
  unconditionalParents := []
  filteredParents := []
  for [cat, :pred] in parents repeat
 if pred = true then
unconditionalParents := [cat,:unconditionalParents]
filteredParents := [[cat,:pred], :filteredParents]
  for [cat, :pred] in parents repeat
 if not pred = true and not member(cat, unconditionalParents) then
filteredParents=[[cat,:pred], :filteredParents]
  PROGV(vars, vals,
LIST2VEC
  [EVAL quoteCatOp cat for [cat,:pred] in filteredParents | EVAL pred])

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] tmp-aldorlib

[Peter Broadbery]

>
> That is serious limitation.  Spad solution is not nice
> (either compile first with $bootStrapMode set to true
> or compile whole algebra using special bootstraping
> function) but works.  FriCAS algebra contains more
> nasty dependencies, where there is cyclic dependend
> in types, I first suspected something of that sort...
>
>

I don't think the exact issue here is impossible to fix (ralf asked,
so you got the gory details), and this case is certainly possible to
work around  - in fact, there is a one line fix if you just want
compilation and working code, but wasn't perfect.  Basically, the
point of this was to see how well aldor deals with large libraries,
with the specific goal of finding compiler issues.

I was quite happy to get as far as the IntegerRoots package, as it is
fairly high up in the dependency graph.  Is there a list anywhere of
things that must be compiled with $bootstrapMode?

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] tmp-aldorlib

[Peter Broadbery]

On Wed, Jul 24, 2013 at 7:50 PM, Ralf Hemmecke  wrote:
>> Foo(I: with): with
>>f: () -> ()
>> == add
>>import from Bar I
>>f(): () == a()
>>
>> Bar(I: with): with
>>a: () -> ()
>> == add
>>import from Foo I
>>a(): () == f();
>
> Peter,
>
> what code do you expect that to produce?
> Peronally, I would be happy, if the compiler does *not* compile this.
> Semantics would anyway be that invoking a() runs forever.
>

That's simply the smallest example that fails - The original obviously
was a bit more interesting. (it was possibly
IntegerRoots/IntegerPrimesPackage)

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] tmp-aldorlib

[Peter Broadbery]

On Wed, Jul 24, 2013 at 1:03 PM, Waldek Hebisch
 wrote:
> Peter Broadbery wrote:
>>
>> >
>> > Although you call it aldorlib, that looks more like you try to bring the
>> > FriCAS algebra library (at least a part of) to Aldor.
>> >
>> > a) What is your exact goal with this?
>> > b) Will that be usable from within FriCAS? How?
>> > c) Have you translated all these constructors by hand or did you use
>> > some tool?
>> >
>>
>> I decided that I'd try to wring a few long standing bugs out of aldor
>> - largely for my own amusement.  So, I decided to try a domain for
>> domain replica of the fricas library as it stood at that point in
>> time, and try to be as honest about it as possible - ie. none of the
>> workarounds that exist implicitly in the aldor libraries.  The goal
>> was basically to see how far the exercise  would go before I either
>> got sidetracked or found an insurmountable problem.  I stopped roughly
>> when I found an issue with mutually dependent types that I wasn't able
>> to fix properly.
>
> Could you say more what the problem was?
>
> --

Quick summary; a file with two mutually referential parameterised
types does not compile.  It is possible to work around, but that would
(for me) defeat the purpose of the exercise.  I'm sure it's fixable,
just that I had some more interesting distractions show up when I came
across this issue.

Peter

Foo(I: with): with
   f: () -> ()
== add
   import from Bar I
   f(): () == a()

Bar(I: with): with
   a: () -> ()
== add
   import from Foo I
   a(): () == f();

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [fricas-devel] tmp-aldorlib

[Peter Broadbery]

>
> Although you call it aldorlib, that looks more like you try to bring the
> FriCAS algebra library (at least a part of) to Aldor.
>
> a) What is your exact goal with this?
> b) Will that be usable from within FriCAS? How?
> c) Have you translated all these constructors by hand or did you use
> some tool?
>

I decided that I'd try to wring a few long standing bugs out of aldor
- largely for my own amusement.  So, I decided to try a domain for
domain replica of the fricas library as it stood at that point in
time, and try to be as honest about it as possible - ie. none of the
workarounds that exist implicitly in the aldor libraries.  The goal
was basically to see how far the exercise  would go before I either
got sidetracked or found an insurmountable problem.  I stopped roughly
when I found an issue with mutually dependent types that I wasn't able
to fix properly.

As it stands, it's up to about a level where some polynomial types are
available, but not all.  It's about as far from production ready as it
can be without eating your hard disk (I can promise that it probably
won't do that).

It is "usable" within fricas - ie. it will generate a file with a
bunch of load statements, and fricas will load the domains and work as
far as it goes, although in a thoroughly lobotomized way.  I've not
benchmarked it against fricas, but I'd expect it's pretty poor, due to
lack of inlining on non-concrete types.

Peter

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[fricas-devel] Re: Something missing in new Aldor interface?

[Peter Broadbery]

On Mon, Oct 19, 2009 at 11:04 PM, Ralf Hemmecke  wrote:

> This mail also goes to Peter Broadbery. Peter, perhaps you can give us some
> hints...
>
>  Note: 1073741789 is the largest prime that can be represented in 30
>> bits. Assuming Lisp integers are not less than 30 bits (maybe not a
>> good assumption?)
>>
>
> That is what I meant. Didn't we have problems with sbcl on other occasions
> connected to the aldor interface? Wasn't that related to fixnum or so? But
> then probably fricas-aldor should fail on my 32 bit sbcl machine. But it
> didn't. (Or at least I haven't realized it. --- I don't think I actually
> checked carefully.)
>
> > one might expect this code to behave the same way in
>
>> FriCAS whether it compiled for a 32 bit or 64 bit machine.
>>
>
>  ...
>> $hashModulus := 1073741789  -- largest 30-bit prime
>>
>> -- Produce a 30-bit hash code.  This function must produce the same codes
>> -- as the asharp string hasher in src/strops.c
>> hashString str ==
>>h := 0
>>for i in 0..#str-1 repeat
>>j := CHAR_-CODE char str.i
>>h := LOGXOR(h, ASH(h, 8))
>>h := h + j + 200041
>>h := LOGAND(h, 1073741823)  -- 0x3FFF
>>REM(h, $hashModulus)
>>
>
> The function from aldor/src/strops.c is
> Hash
> strHash(register String s)
> {
>register Hash   h = 0;
>register intc;
>
>while ((c = *s++) != 0) {
>h ^= (h << 8);
>h += (charToAscii(c) + 200041);
>h &= 0x3FFF;
>}
>return h;
> }
>
> That looks pretty much the same.
>
>  -- Combine two hash codes to make a new one.  Must be the same as in
>> -- the hashCombine function in aslib/runtime.as in asharp.
>> hashCombine(hash1, hash2) ==
>> MOD(ASH(LOGAND(hash2, 16777215), 6) + hash1, $hashModulus)
>> ...
>>
>> This does not appear to confirm what you say: "hashCombine(32236,hash)
>>  just cuts it down to 16 bit or so'.
>>
>> Off hand I do not see anything remarkable about the value 32236.
>>
>
> /aldor/lib/libfoam/runtime.as is the only file that looks appropriate.
>
> But I don't find anything that looks like hashCombine.
>
> Peter, can you explain why you suggested that patch and where the actual
> place inside the Aldor compiler code is.
>
>
> http://groups.google.com/group/fricas-devel/browse_thread/thread/c1d1ccc263415ba5
> and more specifically...
> http://groups.google.com/group/fricas-devel/msg/c0423375adc2e6d2
>
> Ralf
>



If I remember correctly, 32236 comes from the hashcode of '->', or possibly
Map, maybe combined with the hashing function. There isn't quite enough
context in the diff for me to tell, and I don't have sourcecode around at
the moment.

The problem is that axiom and aldor need to agree on hashcodes for a given
type, and in the patched case, I guess they didn't.  Debugging this usually
means looking at the aldor hash code calculation (write domain with one
export of the type in question, & compile with all optimisation off)  and
comparing that with what axiom/fricas/etc  does.


Peter

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to 
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---