Hill Strong writes: "I have been investigating Maxima and Axiom/FriCAS and there are all sorts of peculiar edge cases in each of these systems that arise from unspecified language semantics. I am currently investigating a significant update (alterations/changes) to the FriCAS language because of these peculiarities. I suspect and have scheduled up to 5 years for the redevelopment of FriCAS language and to have a fully specified denotational semantics available. Now, I am doing this for my own purposes and it may well be of zero interest to anyone else. But since I am effectively retired and this is one of my interests and I have a longer term purpose for the more general use of such a system, I shall proceed along this path and see what results from it/"
I'd be very interested in your sematics efforts. Tim Daly On Thursday, November 9, 2023 at 8:55:21 AM UTC-5 [email protected] wrote: > On Thu, Nov 9, 2023 at 12:38 AM Waldek Hebisch <[email protected]> wrote: > >> On Wed, Nov 08, 2023 at 05:29:38PM +1100, Hill Strong wrote: >> > >> > On Wed, 8 Nov 2023, 2:28 pm Waldek Hebisch, <[email protected]> wrote: >> > >> > > On Wed, Nov 08, 2023 at 11:51:12AM +1100, Hill Strong wrote: >> > > > In terms of defining any kind of variable, the language and its >> > > associated >> > > > semantics should have a [bottom] value. Interestingly, FriCAS does >> have >> > > > such a value defined. However, what is not clear is whether this >> [bottom] >> > > > can serve for all domains. >> > > > >> > > > There are a couple of alternatives here. One is that every domain >> has its >> > > > own [bottom] value seperate from all other domains. Another is that >> all >> > > > domains inherit the same [bottom] value. >> > > > >> > > > I am in the process of looking at the FriCAS language to see where >> the >> > > > semantic definition is either problematic or not defined. There >> appears >> > > to >> > > > be quite a number of such things to fix. Reading the various threads >> > > shows >> > > > that some serious language definitions are required. >> > > >> > > Well, 'bottom' may be used in _description_ of semantics of a >> language. >> > > There are many approches to describing semantics. One approach that >> > > I like and I think fits well to FriCAS is axiomatic approach. >> > > >> > >> > This is a difference between us. I have found that the denotational >> > semantics is superior. Of course, trying to ensure that you have a >> > consistent model for the language in question via denotational semantics >> > can be quite time consuming. >> > >> > >> > In this approach we have logical formulas associated with states >> > > and each piece of code have two related formulas: precondition >> > > and postcondition with meaning that if precondition is satisfied >> > > then code will execite succesfuly and finish satisfying postcondition. >> > > >> > >> > However, this approach fails to define clearly what the code in >> question is >> > doing. This is especially true if you are dependent on the >> implementation >> > underlying that code. >> >> Each formalizm will abstract over (that is leave unspecified) some >> details. > > > I agree with you in regards to the abstraction provided by each formalism. > > >> In axiomatic approach you can define things in fine detail >> or leave them unspecified, that is your choice. > > > The problem here is: what kinds of things are left unspecified? In many of > the [language] standards available, those things that are left unspecified > actually give rise to significant problems between each of the > implementations trying to provide the spacified [standard]. I have spent > forty years designing, implementing and maintaining many different > real-life systems. The biggest problems have been involved in moving from > one implementation to another. We see this problem here in FricCAS when > moving from one implementation of Common Lisp to another. This very thread > about "qnew" and how this is implemented. > > In terms of the semantics for "qnew", this shows up with the discussion > seen far. This is where my point about [bottom] comes to the fore. In > effect, This is a logical value and just how a specific implementation > implements this [bottom] value becomes irrelevant as long as each > implementation provides a logically and semantically consistent value that > represents [bottom]. This will not affect any of the source code per se. > > >> Concerning clearly, >> that depends very much of familiarity with given formalizm. >> >> > > Fundamental part of this apprach is that when precondition is not >> > > satisfied, then there is no warranty, anything can happen: program >> > > may crash, computer may explode or something else bad may happen. >> > > >> > >> > This is precisely what is not wanted. >> > >> > Some people are unhappy about consequences of failed precondition >> > > and invent formalizms where everthing is "defined", such formalizms >> > > miss important property is real world languages and are not >> > > appropriate to describe FriCAS. >> > > >> > >> > Just because "real world" languages might do this, it does not mean that >> > this is the approach that should be followed. >> > >> > You want the least number of surprises and you want risky things to be >> > difficult and not something that just happens. >> >> Well, anybody wants to avoid bad things. In axiomatic approach >> it is "easy": ensire that preconditions are satisfied. > > > "Risky" things are quite different to "bad" things. You can have all the > "preconditions" that you want. However, if some action is left to the > implementation or is undefined, all of those preconditions amount to > nothing in terms of correctness. Correct code is hard enough to achieve > without trying to get code correct with undefined or unspecified behaviour > from each implementation. > > I have been investigating Maxima and Axiom/FriCAS and there are all sorts > of peculiar edge cases in each of these systems that arise from unspecified > language semantics. I am currently investigating a significant update > (alterations/changes) to the FriCAS language because of these > peculiarities. I suspect and have scheduled up to 5 years for the > redevelopment of FriCAS language and to have a fully specified denotational > semantics available. Now, I am doing this for my own purposes and it may > well be of zero interest to anyone else. But since I am effectively retired > and this is one of my interests and I have a longer term purpose for the > more general use of such a system, I shall proceed along this path and see > what results from it/ > > >> However, >> you can not "define away" problems. For example PL/I was early >> attempt to make everthing defined: it was hard to implement, >> and bad things could easily happen in user programs. Those >> bad things frequently were "well defined", but where not what >> users intended. >> > > I agree that PL/I was an attempt to be all things to all people but this > also applies to many languages that have been developed since the late > 50's. Being hard to implement is NOT a factor in designing and implementing > an appropriately defined semantics for any language. That is part and > parcel to those designing a language and building the infrastructure for > that language. > > A case in point here is my comment about failure being an option. This > requires of the implementation quite a few complexities in the > implementation. As far as the semantics for the language itself, as long as > these are clearly defined and logically explained, then a programming > language user can use this to good effect consistently. In addition, keep > your various language attributes orthogonal, don't conflate separate ideas > where they shouldn't be. > > In this discussion about "qnew", this should only be available in the > underlying implementation and should have no (as in zero) visibility to any > user of the FriCAS language, not a casual user nor somebody building any > category/domain/package. > > >> >> > > Concerning uninitialized variables: it is convenient to use >> > > special "bad" values (say 'bottom') to "mark" uninitialized >> > > variables. That way statement 'a is initialized' can be >> > > written as 'a \ne bottom'. >> > >> > > Some people want to eliminate uninitialized variables by >> > > providing default initialization, say to 0 or to 'botton'. >> > > >> > >> > In the vast majority of cases, the creation of a variable is immediately >> > followed by an initialisation. There should be very rare cases where the >> > creation of the variable is not followed by an initialisation. Looking >> > through the FriCAS code base, I have found few places that actually >> require >> > a definition of a variable without immediate initialisation. >> >> Yes. So in practice uninitialized variables are not big trouble: >> there is limited number of places where we need delayed initialization >> and with some effort we can make sure that initialization happens >> before use. >> > > Unfortunately, there are instances where they are [big trouble] and this > is one of those risky activities that should be very hard to do. I have > spent considerable time reading the code base and I am very suspicious as > to the veracity of different sections of the code base. Yes effort can be > put into making sure that initialisation does occur before use, but as > experience has shown me over forty years, this effort is often assumed to > have been done when it wasn't. What is interesting here though is that > sheer happenstance can occur where it doesn't appear to matter until a edge > case scenario occurs and then you are left scratching your head trying to > determine what has actually happened. > > >> >> > However, this replaces problem of uninitialized variables >> > > by problems of wrongly uninitialized variables. Wrong >> > > initialization is at least as bad as lack in initialization, >> > > >> > >> > Wrongly initialised variables are always a problem. What this means is >> that >> > the programmer has not thought through the problem carefully enough. >> > >> > It is one thing to have an uninitialised variable containing the >> [bottom] >> > value, it is another to having some unknown value sitting in the >> variable >> > coming from the underlying implementation. >> >> Well, in both cases program is wrong. Of course, when debugging >> it helps if implementation tells you about uninitialized variables. >> But reporting uninitialized variables has its cost, and it is not >> clear if it is worth paying this cost. >> > > Yes, both are wrong. But having a defined [bottom] value is far better > than some unknown value that has the appearance of being correct. The > latter is much more difficult to find, very much more difficult. > > As for the cost of reporting uninitialised variables, this is a compiler > function and not a runtime function and is worth the cost. If the compiler > is not able to determine this then you have a serious problem on your > hands. > > >> >> > so in practice this in not very useful. If variables are >> > > initialized to 'bottom' and attempts to use 'bottom' >> > > in computations are detected, then this may help in >> > > finding uses of uninitialized variables. >> > >> > >> > Having an uninitialised variable deliberately should be hard to do and >> not >> > something that can happen as a normal matter of writing your code. >> >> Well, deliberatly reading uninitialised variable does not happen >> as a normal matter of writing code. Having variable which is initialized >> some time after declaration while not frequent is quite normal. >> > > Deliberately reading an uninitialised variable is completely warped in any > case and is something that the compiler should already be picking up as it > is doing its semantic analysis and code generation. For all purposes, the > FriCAS language should be high level code and not delving into > implementation issues. > > >> OTOH tryning to prevent writing wrong code in many cases is >> futile: when programmer can not write useful code in natural >> way because some construct was forbiden as dangerous, then >> code would get written in less natural way which is freqently >> more error prone than natural way. >> > > You are conflating a couple of ideas here. The first idea is that wrong > code is always easy to write. The second idea is related to the allowable > constructs within the language. These are quite separate and should not be > conflated. The third idea is about wrong code due to semantic lacks in the > language. This is a quite separate issue to the available language > constructs and the ability to write wrong code using the available language. > > As I pointed out above in relation to Icon/Unicon, the use of failure > makes the writing of more natural code easier. The example I used was > related to range testing as in > > 0 < I < K < 10 > > where both I and K are between the limits 0 and 10 and I has to be less > than K > > But I could also use an alternate test such as comparing a variable to a > series of values as in > > currentStr == ("fair" | "good" | "better") > > where we are testing if the string value in currentStr is one of "fair" or > "good" or "better". > > The FriCAS language has some very good natural ways to express particular > ideas. But it also has some very awful examples as well and is not > consistent in how certain constructs are implemented. This kind of thing is > found in all languages, but can be improved over time. > > >> >> > Writing code takes a great deal thought and skill, this is where the >> > language in question should be not full of surprises. >> >> There is no surprise with uninitialized variables, reading them is >> clearly an error. And as you noticed it is not hard to avoid >> such errors. >> > > Actually, there are various places in the FriCAS code base where just > reading the code in front of you doesn't tell you anything about whether or > not a particular variable has been initialised. You have to go hunting > elsewhere to determine that and may have to read and analyse other sections > of the code. It is certainly not as easy as you make it out to be. > > >> >> > However, such >> > > approach is costly at runtime, so not appropriate for >> > > high perfomance software. >> > > >> > >> > With today's systems, this mindset is actually counter productive. The >> > algorithms used are far more important than worrying about trying to get >> > high performance from lesser "problems". >> > >> > It is far more important that the code is correct. >> >> Well, premature optimization is bad. > > > I am not talking about premature optimisation. I am talking about getting > the code correct. This includes making sure that edge cases don't bite you. > > >> But once you have good algoritm >> you may find out that speed is still lower than desired. > > > Honestly, for today's activities where you are using something like > FriCAS, speed will always be lower than desired. If this is a problem, you > get better equipment or look for better algorithms. > > >> Lower >> level implementation details can make a lot of difference. > > > Yes of course. But this is NOT your problem in terms of being a user to > something like FriCAS. This is a problem for the compiler maintainer and > should never ever intrude upon the language user. If you start down that > rabbit hole you are going to make a mess of things. There have been many > others who have gone down this path and the end results were not worth it. > > >> Already >> factor of 2 may be significant and factor of 1000 may easily happen >> when you compare optimizing compiler to "safe interpreter". >> > > For the vast majority, a factor of 2 is ridiculously insignificant, even a > factor of 100 or 1000 will not be significant for the majority. If it is > going to affect things significantly, then this is in the hands of the > compiler maintainer and still should not affect or be relevant to any user > of the system/language. The only thing they should see is a decrease in > runtime as the compiler is improved. Their usage or code writing should not > be affected. > > The last point here is that every language represents a virtual machine > that the user is writing for and anything that implements that virtual > machine is NOT in the domain (or should NOT be ) of things that concerns > the system/language user. If they are forced to have to take notice this > interferes with what they are trying to achieve and is seriously > detrimental to achieving their goals. Keep in mind that FriCAS (and all > such systems) is a tool for achieving certain purposes. For the user of > that system to have to understand the inner workings adds an additional > burden that should not be necessary unless they particularly want to get > involved. The analogy here is that FriCAS is a motor vehicle that gets you > from one place to another, as long as it does, you are not required and > should not be required to understand the workings of an internal combustion > engine or an automatic gearbox. > > >> >> -- >> 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 [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/fricas-devel/ZUuPRiOpurvawVUV%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/b2ddb26a-c3c5-455f-bc1d-8449fa1a2dd5n%40googlegroups.com.
