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/CAEnaMTE%3D9Jc0sqsQMCmGs4JqU1x4hi%3DMhipC%2BJRMj8L-7FNmog%40mail.gmail.com.
