I was wondering what was the motivation to introduce it, simple convenience or some missing functionality in the official interface?

It looks to me that the same effect can be achieved with:
PROC_make_function_call("cons!-quote", 2);
PROC_lisp_eval();

where cons!-quote is defined as (df cons!-quote (v u) (cons (quote u) (quote v)))

Cheers,
Valery


On 10 April 2014 20:03, Kurt Pagani <nilqed@gmail.com> wrote:

> Can you explain what PROC_make_cons does?

As the name indicates "PROC_make_cons" creates a Lisp "cons" from a qcar/qcdr pair in the PROC stack. To really understand what's going on one should consult http://sourceforge.net/p/reduce-algebra/code/HEAD/tree/trunk/csl/cslbase/csl.c, especially the part at the end of the file.




On 9 April 2014 18:25, Valery Yundin <yu.valery@gmail.com> wrote:
Hi,

Can you explain what PROC_make_cons does?

Thanks,
Valery


On 7 April 2014 15:38, Kurt Pagani <nilqed@gmail.com> wrote:

Hi Valery

There are some minor sticking points in the interface, however, Albert Gräf wrote a patch which you can find in (https://bitbucket.org/purelang/pure-lang/downloads/pure-reduce-0.4.tar.gz). He also wrote a remarkable TeXmacs plugin (https://bitbucket.org/purelang/pure-lang/wiki/pure-texmacs.en.pdf) which heavily relies on PROC_lisp_eval. Morevover, the Lisp eval function is indispensable if you want to use some/many of the packages. How all works is best seen in the  "reduce.pure" file (contained in the tgz mentioned above). To be short,  the PROC_ interface provides full functionality when using some Lisp by lisp_eval/execute_lisp_function.

The Python script is merely a hack to check if it works, so forget about it.


Best
Kurt


 


On 7 April 2014 10:16, Valery Yundin <yu.valery@gmail.com> wrote:
Hi Kurt,

Thanks for the links. I've seen already pure interface, but not your python interface (could've saved myself half an hour if I knew about it).
BTW it seems that conversion to "fixnum"/smallint is not completely bulletproof in your Expr class (they are supposed to be maximum 28-bit long).

I wonder how does "PROC_" interface relate to interactive modes of Reduce: algebraic and symbolic. Does it implement full functionality of both? of one? a subset of one?

Did you manage to get anything useful from PROC_lisp_eval or execute_lisp_function?

Cheers,
Valery


On 6 April 2014 22:15, Kurt Pagani <nilqed@gmail.com> wrote:
Hello Valery

It's not as bad as you might think. There are lots of REDUCE users who are using it in embedded applications. There is a phantastic procedural interface which allows one to use REDUCE as a library. See e.g. Pure (http://puredocs.bitbucket.org/pure-reduce.html) or Python (https://bitbucket.org/kfp/pyreduce). There are also several sophisticated TeXmacs plugins for REDUCE available (e.g. http://arxiv.org/html/1204.3020v1).

Greetings
Kurt

 


On 6 April 2014 01:54, Valery Yundin <yu.valery@gmail.com> wrote:
Hi,

First of all, I'm new to Reduce so some questions may be naive and have been already discussed somewhere.

I think that Reduce gets much less attention than it deserves. There might be many reasons for this, like people being scared away by lisp, but one of them IMO is a bit messy build system and there is no library to use in other projects.

I've noticed that there is a way to compile something like a library in csl/new-embedded sub-directory. I had to make a few changes to make it compile, and got a few questions in the process.

I've managed to approximately identify what -DEMBEDDED=1 does, please correct me if I'm wrong
1. Sets hard-coded stack limit to 2MB
2. Tweaks something in terminal input/output
3. Disables something related to dynamically loadable code
Could anyone give more details?

I started writing autoconf/automake build scripts to compile a library similar to new-embedded but with more flexibility. For that purpose it would be useful to split EMBEDDED functionality into logical subsets. For instance hard-coding stack limit might be useful sometimes, but it is completely unrelated to other things which EMBEDDED does (and which I don't understand fully).

Also I noticed that profiling doesn't see to work with EMBEDDED=1, I'm not sure why yet (might be related to point 3?). It would be useful to be able to compile optimized version of library, at the moment my scripts can do it only with EMBEDDED not set.

I'm curious how much user interface is fused with the backend in Reduce. In particular what kind of inevitable limitations will a library with everything except the UI have? Is it possible to more cleanly separate interface from the core and make it easier to create alternative UI? It seems that now it is all glued with #ifdefs scattered around and for instance --without-gui option seems to be slightly broken (perhaps because developers don't use it often).

Another thing is tests, some of them are not producing reference output. Is it a known problem/not a problem or have I done something wrong?

Do you think a mirror of the official SVN repository on github.com (git interoperate with svn seamlessly) would be useful? Also maybe a separate repository with a cut-down minimal version which contains only CSL and packages (without things like packages/rubi_red/rubi4/IntegrationTestResults/MathematicaTestResults/MathematicaNotebookFiles/) for people to get started easily?

Cheers,
Valery


------------------------------------------------------------------------------

_______________________________________________
Reduce-algebra-developers mailing list
Reduce-algebra-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers