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. In axiomatic approach you can define things in fine detail
or leave them unspecified, that is your choice. 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. 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.
> > 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.
> 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.
> 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.
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.
> 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.
> 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. But once you have good algoritm
you may find out that speed is still lower than desired. Lower
level implementation details can make a lot of difference. Already
factor of 2 may be significant and factor of 1000 may easily happen
when you compare optimizing compiler to "safe interpreter".
--
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.
