On 04/15/2014 07:11 PM, Martin Baker wrote: >> I doubt that Waldek wants backwards compatibility just for its own >> sake. > > True but the impression I get with boot code is not just that its got > minimum documentation and minimum typing written in an obscure > language that is hardly documented itself.
Martin, I think, by now you should know that boot code is about to be removed. The question is: How to do this. There is no good documentation, so the only option one has to understand what the system is doing, is to look at the source code. But unfortunately that is BOOT. :-( Now how can you replace the BOOT code by SPAD code (written from scratch) if you don't exactly know what specification the SPAD code should match. If you don't even have a lot of proper test cases, then it's even harder. Suppose, we simply remove i-output.boot and take something (in SPAD) that you give us. I'd be much in favour of that. You need not copy i-output.boot, but there is one condition for you: after removing that i-output.boot, FriCAS should still work at least as good as before. Can you give an estimate *when* you will have such a SPAD file? Note that the goal is to remove i-output.boot, not just adding a new SPAD file. > I get the impression there are parts (only parts) of the code where > it would be better to rewrite from scratch, it may break some old > stuff which relies on the anomalies but it would be a much firmer > foundation for the future. Nobody stops you from writing such code. No, honestly, there is nothing wrong with your approach. Do it. Show us the code and explain which part of FriCAS will be better and which boot files can be removed by your code. (Your patch can actually already contain the removal of that boot code.) Add sufficient test cases so that it would be easy for a reviewer of your code that (1) it does what it claims to do and (2) shows that the old system is only changed at deliberate places. > Also I find SExpressions and their associated pretends quite evil (I > know there are a few cases where we have to use them). There are always parts of the system that is relatively low-level. SExpression is such a domain. I would actually count it as not too far away from Lisp. So if you don't have to, then don't use SExpression. Go with Tree(S) instead. > One of the advantages of moving to SPAD is that it is more strongly > typed, but using SExpressions+pretends seems to turn it back into a > loosely typed language again. This may not be a problem for you guys, > if you know what types to expect, but for me it would lead to runtime > errors which are harder to find than compile time errors. I would > find it much easier to go directly to high level code and debug > that. Same for me. I neither like "pretend" nor SExpression nor InputForm and all that low-level stuff. But we don't yet have something cleaner. Why don't you just write your own abstraction layer on top of a few basic domains and then never ever again use "pretend" and low-level domains, but rather use your abstraction layer? That would give you nice types and wouldn't stop you from implementing stuff that you like to implement. I'd really be happy if we could replace our graphics engine with something better. I have the impression that you have the potential to write a new interactive system. It wouldn't matter if we have two systems. Your code does not even have to live in the SVN archive. I'm currently working on the book and all of that is just local on my laptop and partly on my github account. When Waldek commits new code, I often rebase my branch on top of the new trunk. That's usually not a problem and while compiling I immediately see whether Waldek's code breaks something in my branch. We are basically all working on orthogonal stuff. So what really stops you from doing what you want? Just because Waldek seemingly doesn't want big rewrites, there is no point in just doing what you want. If after some time (maybe several months) you show that your code is superior or your code simply helps *you* to do your work or to just be happy about it, then go on. > Perhaps but big projects can afford to waste resources, but > developers here seem so thin on the ground that it should be easier > to coordinate better. The code is there, start working on what your really like to do. You can even fork the code (actually with git, you (and me) have already done so) and be the master of your own fork. You can always include the code from FriCAS into your fork. Continue and don't wait for someone to tell you what you should do or whether your code will ever be included into FriCAS. That doesn't matter. If the code is good for your, that should suffice to write it. 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
