One of the reasons that started me looking at a non-Lisp base was the fundamental use of lists in the Boot implementation. Within Icon (or in my case using the Unicon system), lists are implemented in such a way that accessing any element was much faster than via a cons cell. You could treat a list in much the same manner as an array, even though it is not. The other thing that I saw as a poor fit was the use of lists (cons cells) for what was really a record structure. Some people are quite happy to use lists as their general purpose structure of choice, others prefer to use more appropriate structures. This is simply a matter of choice for the individual.
As far as ECL is concerned, I don't have any insight to offer here as I don't as a matter of course use any Common Lisp implementation for any programming that I do.Most of my programming is based on using Unicon/Icon for my interest today. Being effectively retired, I don't have to use whatever is in use by others. Though I was at one stage considering looking at the practicality of using Scheme as the implementation language for Boot. There are just too many fundamental differences in philosophy between Common Lisp and Scheme and I put that project to one side. Hill On Sat, Apr 13, 2024 at 8:54 PM Dima Pasechnik <[email protected]> wrote: > > > On 13 April 2024 02:38:34 CEST, Hill Strong <[email protected]> > wrote: > >There is nothing to stop anyone from breaking the requirement of using any > >Lisp as the destination for Boot code. I translated one section of Boot > >code directly into Icon. Of course there is much in Boot than assumes Lisp > >lists. But that is not an impossible task to change. > > > >You could then use the iconc compiler to transform the icon code to C and > >compile to machine code. > > But that's what ECL is doing, compiling to C and then calling a C > compiler? Would it be more useful to figure out why the resulting FriCAS > runs considerably slower than the one built using SBCL ? > > Dima > > > >I have not continued that development as I am much more interested in > >changing the Spad language to be a more consistent block structured > >language, including adding in static environmental structures ala ALGOL > >and it's descendents. > > > >On Sat, 13 Apr 2024, 6:05 am Ralf Hemmecke, <[email protected]> wrote: > > > >> > >> > >> On 4/12/24 16:20, Martin Baker wrote: > >> > On 12/04/2024 09:23, Ralf Hemmecke wrote: > >> >> I do not understand why you think that not both graphics systems > >> >> can live besides each other (as they do now)? > >> > > >> > Well, I think that the interactive graphics should work seamlessly > >> > with the things that scene.spad can do such as outputting to various > >> > file formats and having much more control over the output. For all > >> > this to work together without duplication it all needs to be written > >> > in SPAD. > >> > >> So, yes. If I were you, I would simply ignore the existing graphics > >> system and provide all the features that *you* think would be great and > >> help you in your work. That would inclulde connecting (or writing from > >> scratch) an interactive graphics system in SPAD. Why would you care what > >> Waldek or anybody else who has write access to the FriCAS repo says? You > >> can put everything into your own repo and try to promote it to users. > >> If your system is superior, it will at some point be seen and more users > >> will ask to properly include it into FriCAS. > >> Clearly, nobody can assume that his/her code will be included into the > >> "official" code base. But with open source it is terribly easy to create > >> your own fork and show that your stuff is better. Yes, with forking > >> comes maintenance and other costs, so one must decide whether to fork, > >> fight with the maintainers for inclusion or simply abandon the project. > >> > >> It's not an easy taskt to make the world a better place. > >> > >> > The problem is interactive graphics require multi-threading and I > >> > can't see anyone agreeing to a limitation that SPAD can only work on > >> > top of some specialised lisp with multi-threading. I suspect that is > >> > the reason for the C code to allow multi-threading. > >> > >> Hmmm... strangely enough we have jFriCAS, it was easier if FriCAS is > >> compiled with a lisp that has a webserver built-in. And, in fact, > >> jFriCAS is only properly working with SBCL (at least I haven't tested > >> with other lisps). > >> What I want to say is that your interactive graphics system can work on > >> a certain type of lisp. It just means that by default FriCAS provides > >> the old graphics system and your features would require the users to > >> compile with a specific lisp. Why should that be a problem. Your > >> graphics system would be optional and whether to compile it or not is > >> only a configure option away. That would reduce maintenance cost for > >> anybody else except you. You then must show that you are interested and > >> prove it by maintaining your code and fixing bugs. > >> Maybe Waldek would still be against, but having a better interactive > >> graphics system would get support from me for its includion as an > >> (optional) add-on. > >> > >> > People usually suggest using their favorite 3rd party graphical > >> > front end but I can't see Waldek making FriCAS totally reliant on > >> > some 3rd party software. > >> > >> Yes, that is dangerous. But allowing users to decide, is another. > >> > >> > Another problem is that graphic interfaces, hardware, file formats > >> > change rapidly and these interfaces need more maintainable code. > >> > >> Yes, of course, some people like old code more since they are used to it > >> and know how it works, the younger generation probably want newer system > >> and newer code. And surely, knowing all the newer graphics systems I > >> would be unwilling to support any weird old stuff and fight for > >> inclusion of newer technology. That's not a bad thing. > >> > >> > For example will FriCAS support X11 to wayland transition? > >> > >> Well, there are only two options. 1) It will. 2) FriCAS will lose it's > >> graphics capabilities. Which one would you choose if you were a > >> maintainer of FriCAS? > >> > >> 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 [email protected]. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/fricas-devel/4df02ef4-1b24-42f1-a68c-3cb122a162f8%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/AA56A632-E864-49D0-BA9C-31AE14C76F91%40gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAEnaMTFdeCn4OC9-GcEu4GYLLCVjggenT%2BNEM9vFnix2PFzyew%40mail.gmail.com.
