Comments below. On Wed, 8 Nov 2023, 2:28 pm Waldek Hebisch, <de...@fricas.org> 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. Theoretically, only precondition is neccesay, as one can replace > postcondition by appropriate code. Also, theory is nicer when > using infinitary logic, but practical approach uses clasical > (finite) logic. > Since I am not a mathematician, my approach is from the computer language position. I have used Icon/Unicorn languages for many decades and SNOBOL 4 prior to that. The feature of these languages that has been essential to me has been the idea that failure is an option. Intriguingly, this idea appears in FriCAS but in a very kludgy manner. Within the above languages, failure drives all testing, irrespective of whether this is found in if/then/else or the different types of loops or even assignments. Certain kinds of mathematical expressions are significantly clearer in Icon/Unicon than in the normal kinds of languages. A couple of examples: 0 < I < K < 10 tests that both I and K are between the endpoints 0 and 10 and that I is less than K. This is contrast to the following normal formulation: 0 < I and I < K and K < 0. If any one of these is not true then failure is signalled. > 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. > 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'. Better is to have an operator that can fail if a variable is uninitialised and returns the variable if initialised. The dual to that is an operator that fails if the variable is initialised and returns the variable if it is uninitialised. But note that such 'bottom' by neccessity is _not_ a valid value of variable: initialized > variable can not have 'bottom' as its value. So here > 'bottom' is purely virtual: does not exist in reality and > can not be value of any type. > Yet the study of lattices with denotational semantics does allow for [bottom] to have a meaningful existence. Of course, in the context of domains, the use of such a value doesn't produce anything other than [bottom]. Its purpose is to indicate uninitialised variables. > 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. 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. 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. Writing code takes a great deal thought and skill, this is where the language in question should be not full of surprises. 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. > -- > 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 fricas-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/ZUsAUrV8%2BSI51M3K%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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAEnaMTF19J1zF%2BCUZUmxrzjXdnH6zaavrU4xt%2B4ok3C-MJGRsg%40mail.gmail.com.
