Suggesting PRs for next release (after 2.10)

[jpellegrini]

Hi @egallesio !
This is a suggestion for inclusion in the next release... Just a suggestion of course!

Bug fixes:

• [trivial] max/min: do not compare complexes #846 -- trivial
• [simple] Fix acos for numbers outside [-1, +1] #854 -- simple
• [trivial] Fix 0/0 (which should not be zero) #876 -- trivial, and important (currently, 0/0 is equal to 0)

Trivial compilation instruction or configure changes:

• [simple] Fix Android build instructions #687 -- I think this one is important... Without it, the build instructions for Android are non-functional
• [trivial] Mention status of DEBUG_VM, STAT_VM and STK_DEBUG in configure script #785 -- trvial one, gives more info after ./configure

SRFIs that have no issues:

• Add SRFI 225 - Dictionaries (without subdirectories) #867
• Add SRFI 264: String Syntax for Scheme Regular Expressions #835
• [simple ?] Add SRFI 239 - Destructuring Lists #716

Documentation:

• [trivial] Document autoload #738 -- simple
• [simple] Document the C part of call/cc implementation #767 -- not really essential, but helps when hacking

Optimizations that have no issues:

• [somewhat simple (?)] Optimize rational comparison; also optimize general number comparisons #768 -- no issues, gives nice speedup, just a better method
• Optimize SRFI-1 #800 -- big optimizations, but nothing complicated
• [simple] Optimize repeat #844 -- a really nice optimization to small numbers of iterations in repeat...
• [simple] Optimize LCM #848 -- Optimizes LCM. Simple enhancement, and a nice, unexpected speedup!
• [simple] Optimize away (not (not inside if... #850 -- we were not cancelling out (not (not inside conditionals!
• [simple] Use BIGNUM_FITS_DOUBLE instead of BIGNUM_FITS_INTEGER #851 -- we were testing if a bignum fits an INTEGER before storing it in a DOUBLE!

New examples:

• [simple] Add example of R7RS library #742 -- simple example. I could not make the Makefile generate the ostk file, though.
• Add an example of object oriented program #681 -- not just "an OO example", I actually had fun using it. "use the terminal as canvas for drawing colorful geometric objects" :)
• Add example using regexps #678 -- not "Unix-like", and fixing it is left as an exercise...

Changes to the core:

• Add fold and reduce to the core #734 -- STklos would become more featureful and faster...

[egallesio]

Bug fixes:

• [trivial] max/min: do not compare complexes #846 -- trivial

Probably (not really looked at it yet)

Trivial compilation instruction or configure changes:

• [simple] Fix Android build instructions #687 -- I think this one is important... Without it, the build instructions for Android are non-functional

When I tested it, it didn't work for me. I have a very old phone (Android 10) and not a lot of memory to test it (now). However, it doesn't seem to work on all the Android versions.

• [trivial] Mention status of DEBUG_VM, STAT_VM and STK_DEBUG in configure script #785 -- trvial one, gives more info after ./configure

This code doesn't work since flags must be propagated in the Makefiles. Furthermore, in current form, configure results start to be too verbose IMO.

SRFIs that have no issues:

• Add SRFI 225 - Dictionaries #799

SRFIS with subdirs are generally the source of many little problems (for installation, cleaning, ...). This one seems quite complex, and I have not tested it with various directory options configurations.

• Add SRFI 264: String Syntax for Scheme Regular Expressions #835

The tests of this SRFI increase the execution time of make test from less than 6s to 7.2s on my laptop. Looking more closely at the tests, there are strange things. We have a lot of identical tests (often they are near, but not always):

   144  (test-ssre ".*$" (: (* nonl) eos))
   145  (test-ssre ".*$" (: (* nonl) eos))
   146  (test-ssre ".*$" (: (* nonl) eos))
   147  (test-ssre ".*$" (: (* nonl) eos))
   148  (test-ssre ".*$" (: (* nonl) eos))
   149  (test-ssre ".*$" (: (* nonl) eos))
   150  (test-ssre ".*$" (: (* nonl) eos))

Launching grep '^(test-s' 264.KTK | sort | uniq -c | sort -n | tail -20, we have

      6 (test-ssre "\\b...\\B" (: (or bow eow) nonl nonl nonl nwb))
      6 (test-ssre "^" bos)
      6 (test-ssre ">\\s+<" (: #\> (+ space) #\<))
      7 (test-sre (~ #\a) "[^a]")
      7 (test-sre (: #\a #\b #\c #\d) "abcd")
      7 (test-sre (+ numeric) "\\d+")
      7 (test-ssre "[^a]" (~ #\a))
      7 (test-ssre "abc$" (: #\a #\b #\c eos))
      7 (test-ssre "^abc$" (: bos #\a #\b #\c eos))
      7 (test-ssre "\\d+" (+ numeric))
      8 (test-ssre ".*\\.gif" (: (* nonl) #\. #\g #\i #\f))
      9 (test-sre (+ (~ #\a)) "[^a]+")
      9 (test-sre (: bos #\a #\b #\c eos) "^abc$")
      9 (test-sre (+ (or alnum #\_)) "\\w+")
      9 (test-ssre "[^a]+" (+ (~ #\a)))
      9 (test-ssre "\\w+" (+ (or alnum #\_)))
     10 (test-ssre "abcd" (: #\a #\b #\c #\d))
     16 (test-sre (: #\a #\b #\c) "abc")
     16 (test-ssre ".*$" (: (* nonl) eos))
     18 (test-ssre "abc" (: #\a #\b #\c))

In fact, it seems we have 1545 unique tests (on 2751). I have seen that this the test file used in the SRFI directory, but I don't understand why all those repetitions.

This point is important for me, since this is often with a make tests that I rapidly evaluate if a modification is negatively impacting the overall system. It is far from perfect, but targeted tests can be confusing (because it is unlikely that the tested situation arises IRL).

• [simple ?] Add SRFI 239 - Destructuring Lists #716

We discussed this one, and I thought we didn't conclude. This doesn't seem to be the case anymore.

Documentation:

• [trivial] Document autoload #738 -- simple

I find your documentation too descriptive. It shows how things are implemented, and it probably should not do so (to permit another implementation). For instance, the actual implementation doesn't work with syntax. One way to implement it could be to have a special cell for autoload function and macros. I had a (not so good) prototype, and the absent documentation of autoload is in fact a reminder to recall me that I need to finish this prototype.

• [simple] Document the C part of call/cc implementation #767 -- not really essential, but helps when hacking

I must admit that I have not really looked at this one yet.

Optimizations that have no issues:

• [somewhat simple (?)] Optimize rational comparison; also optimize general number comparisons #768 -- no issues, gives nice speedup, just a better method

You are right, I'll add this one!

• Optimize SRFI-1 #800 -- big optimizations, but nothing complicated

I have not implemented it yet, because:

• list.c starts to be too complicated with its 4500 lines (not as much as number.c which is now 15000 lines!!!)
• we add a consequent number of functions for lists, and some (except iota) are not of current use imho.
• iota could be more efficient if we know that the resulting list is a list of fixnums, since we could use C addition rather than calling STk_add2.
• A better solution would be probably to implement srfi-1 in Scheme and in C (this is already the case)
• Now that we have cell pools, the advantage of STk_C_make_list is not so evident and C functions tends to be more convoluted when using this function. I planned to study more precisely if we should add more uses for STk_C_make_list

• [simple] Optimize repeat #844 -- a really nice optimization to small numbers of iterations in repeat...

Probably not frequent, but yes this could be added.

• [simple] Optimize LCM #848 -- Optimizes LCM. Simple enhancement, and a nice, unexpected speedup!

Not looked at it yet, and I'll have to test that it still works with gmp light (and it makes number.c a bit more complex, which is something which begins to be worrying).

• [simple] Optimize away (not (not inside if... #850 -- we were not cancelling out (not (not inside conditionals!

I have not looked at it yet. However, this configuration doesn't appear at all in all STklos code, and it will be tested for each if condition. I'm not sure about the need to add it to the compiler, but I need more time to see it.

• [simple] Use BIGNUM_FITS_DOUBLE instead of BIGNUM_FITS_INTEGER #851 -- we were testing if a bignum fits an INTEGER before storing it in a DOUBLE!

New examples:

• [simple] Add example of R7RS library #742 -- simple example. I could not make the Makefile generate the ostk file, though.

Unfortunately, this example illustrates the bad way macros are implemented in STklos: you can use dotimes without importing it. So this example is not really R7RS, and I'm not happy with the fact this is not detected.

I have not looked why you cannot generate the .ostk file

• Add an example of object oriented program #681 -- not just "an OO example", I actually had fun using it. "use the terminal as canvas for drawing colorful geometric objects" :)

Yes, this one is funny! I have not integrated it yet because

1. there is no executable generated. We could have a simple interactive program which calls describe on the object that will be displayed and wait that the user hits return before calling display.
2. the make-class-predicate could be used in a more interesting way with the MOP: we could define a metaclass <predicate-class> used in the <drawable> class, and all the inherited classes will have a predicate for free. The code would be shorter, more sure (you cannot forget to make a predicate) and it will illustrate an interesting use of metaclasses.
3. if using metaclasses is too complex for this example, we could get rid of all the code for make-class-predicate since it is nearly 50 lines on 600, and we could just define the point? function (since it is the only one actually used).

• Add example using regexps #678 -- not "Unix-like", and fixing it is left as an exercise...

This example is not completely correct, since addresses such as 2130706433 (equivalent to 127.0.0.1) or 127.1 are also valid. Furthermore, in actual state, 13000.1.1.1 is accepted (13 is skipped) while 1.1.1.13000 is not OK. For all those reasons, I think that parsing an IP number with a regexp is generally doomed.

Changes to the core:

• Add fold and reduce to the core #734 -- STklos would become more featureful and faster...

I agree. This one could be added.

[jpellegrini]

• [simple] Fix Android build instructions #687 -- I think this one is important... Without it, the build instructions for Android are non-functional

When I tested it, it didn't work for me. I have a very old phone (Android 10) and not a lot of memory to test it (now). However, it doesn't seem to work on all the Android versions.

Hm, ok. It only became a problem when I got a newer version of Android... Not sure what to do.

• [trivial] Mention status of DEBUG_VM, STAT_VM and STK_DEBUG in configure script #785 -- trvial one, gives more info after ./configure

This code doesn't work since flags must be propagated in the Makefiles. Furthermore, in current form, configure results start to be too verbose IMO.

Ah, OK. I'll close it then.

In fact, it seems we have 1545 unique tests (on 2751). I have seen that this the test file used in the SRFI directory, but I don't understand why all those repetitions.

I have removed the repeated tests! I hadn't realized they were duplicated...

• [simple ?] Add SRFI 239 - Destructuring Lists #716

We discussed this one, and I thought we didn't conclude. This doesn't seem to be the case anymore.

It's OK so far as I can see...

• [trivial] Document autoload #738 -- simple

I find your documentation too descriptive. It shows how things are implemented, and it probably should not do so (to permit another implementation). For instance, the actual implementation doesn't work with syntax. One way to implement it could be to have a special cell for autoload function and macros. I had a (not so good) prototype, and the absent documentation of autoload is in fact a reminder to recall me that I need to finish this prototype.

Ok, I'll close that one.

• Optimize SRFI-1 #800 -- big optimizations, but nothing complicated

I have not implemented it yet, because:

* `list.c` starts to be too complicated with its 4500 lines (not as much as `number.c` which is now 15000 lines!!!)

* we add a consequent number of functions for lists, and some (except `iota`) are not of current use imho.

* `iota` could be more efficient if we know that the resulting list is a list of fixnums,  since we could use C addition rather than calling `STk_add2`.

* A better solution would be probably to implement srfi-1 in Scheme and in C (this is already the case)

* Now that we have cell pools, the advantage of `STk_C_make_list` is not so evident and C functions tends to be more convoluted when using this function. I planned to study more precisely if we should add more uses for `STk_C_make_list`

Hmmm, I tink it may be interesting to select only important parts of this one. I'll do that later.

• [simple] Optimize LCM #848 -- Optimizes LCM. Simple enhancement, and a nice, unexpected speedup!

Not looked at it yet, and I'll have to test that it still works with gmp light (and it makes number.c a bit more complex, which is something which begins to be worrying).

• [simple] Use BIGNUM_FITS_DOUBLE instead of BIGNUM_FITS_INTEGER #851 -- we were testing if a bignum fits an INTEGER before storing it in a DOUBLE!

You didn't comment on this one, but I suppose it's OK (it's simple, doesn't add complexity, and makes the implementation more correct.

New examples:

• [simple] Add example of R7RS library #742 -- simple example. I could not make the Makefile generate the ostk file, though.

Unfortunately, this example illustrates the bad way macros are implemented in STklos: you can use dotimes without importing it. So this example is not really R7RS, and I'm not happy with the fact this is not detected.

Ouch! I hadn't realized I did use dotimes...
What if I switch to "do" instead of dotimes?

• Add an example of object oriented program #681 -- not just "an OO example", I actually had fun using it. "use the terminal as canvas for drawing colorful geometric objects" :)

Yes, this one is funny! I have not integrated it yet because
(.. three reasons)

Hm, right, so maybe later.

• Add example using regexps #678 -- not "Unix-like", and fixing it is left as an exercise...

This example is not completely correct, since addresses such as 2130706433 (equivalent to 127.0.0.1) or 127.1 are also valid. Furthermore, in actual state, 13000.1.1.1 is accepted (13 is skipped) while 1.1.1.13000 is not OK. For all those reasons, I think that parsing an IP number with a regexp is generally doomed.

Oh, sure. I'll close that one!

[jpellegrini]

list.c starts to be too complicated with its 4500 lines (not as much as number.c which is now 15000 lines!!!)

Wait, you mean 5000 right? 😁

Speaking of that, what do you think of splitting number.c into number.c and some other file? For example, split the transcendentals... (Not for this next release, maybe for the other one)

[jpellegrini]

I have not looked at it yet. However, this configuration doesn't appear at all in all STklos code, and it will be tested for each if condition. I'm not sure about the need to add it to the compiler, but I need more time to see it.

It seems that this happens in this case:

stklos> (disassemble-expr '(until (not x) y))

000:  GLOBAL-REF           0
002:  IN-NOT
003:  JUMP-TRUE-V          2	;; ==> 007
005:  GOTO                 -7	;; ==> 000
007:

which could be optimized.

The code below, used for benchmarking, looks quite natural, and can be optimized by this PR:

(let ((i 0))
  (time
    (until (> i 30_000_000)
      (inc! i))))
Old code: 1809.308 ms
New code:  755.170 ms

[jpellegrini]

Yes, this one is funny! I have not integrated it yet because

1. there is no executable generated. We could have a simple interactive program which calls `describe` on the object that will be displayed and wait that the user hits `return` before calling display.

And how would the interaction language be? A series of questions? (Like "what kind of object?" Then "what radius?" and "where?", then a circle is created?

2. the `make-class-predicate` could be used in a more interesting way with the MOP: we could define a metaclass `<predicate-class>` used in the `<drawable>` class, and all the inherited classes will have a predicate for free. The code would be shorter, more sure (you cannot forget to make a predicate) and it will illustrate an interesting use of metaclasses.

3. if using metaclasses is too complex for this example, we could get rid of all the code for `make-class-predicate` since it is nearly 50 lines on 600, and we could just define the `point?` function (since it is the only one actually used).

You're right. Maybe keep this simple, without metaclasses, and come up with an advanced version later?