Ralf Hemmecke wrote:
>
> Obviously, 'extend' is difficult to manage in a "session". In fact,
> although in the rest of your mail you spoke about "unloading", I think
> that this is a very dangerous thing, even now.
>
> Maybe, it's a non-issue, because nobody will do the following anyway,
> but suppose I modify integer.spad in such a way that it does not export
> Ring anymore. I can compile such Integer domain and it will be auto
> )lib'ed into my session and, of course, breaks everything.
Well, if you modify integer.spad you are supposed to know
what you are doing. In particular you should not play
with integer.spad when you have state which is difficult
to recreate. During developement, when session breaks
this is not a big problem: you hopefully learn something
and start new session. Note that without such feature
you would _always_ have to start new session.
>
> You might see this as a feature (maybe it is for development), but I
> don't (at least not for ordinary users) and would rather forbid ')lib'
> to destroy my session if it is recognized that the new (reloaded) code
> is in some way contradicting the values (including the category and
> domain hierarchy) that is currently in my session.
>
> I guess, it is even impossible to recognize whether the new code is
> compatible with my current session.
>
> So, although my first reaction to your idea of unloadable "extends" was
> like "Wow, that would be cool!", a second thought dismissed it as
> unnecessary.
>
> Why do we have )lib? It allows to extend the system with newly written
> user SPAD code. For my taste, I wouldn't want to modify existing
> (FriCAS-released) code (because that's that task of the FriCAS
> developers/maintainers).
Well, I think it is a feature that user can modify released domains
like their own. It is hard to do such modification by accident
and it is handy when for example you find a bug and want to fix it.
Main use of ')lib' is for user code. Normally code goes trough
several iterations. In static model (which you seem to advocate)
you go trough edit-compile-link cycle. While faster computers
tend to shorten compile times added language features and bigger
programs work in opposite direction. So length of edit-compile-link
cycle is still a problem. FriCAS approach of loading freshly
compiled domains leads to short cycle which is an advantage.
Concerning checking for consistency: it is natural that
intermediate states are inconsistent. When domain A depend on
B, then after modification to B you need to update A. Regardless
of order, doing it as two steps will lead to inconsistent state:
either you have modified B but old A or new A and old B (actually,
FriCAS is likely to detect type error if you want to modify A
before B, so normally one first modifies B and then A). Note
that such inconsistencies should be detected by runtime support:
if A expects that B provides some signature and this signature
is not present in B, then this will be detected when you attempt
to execute missing signature. So you perform series of compiles
going trough possibly inconsistent states. When you arrive
at hopefully consistent state you start testing. Testing may
discover that you have inconsistent state, then you fix this.
Or may discover ordinary bugs. IMO pure win: you can test
your code earlier than using alternative approaches. The
point is that when you compile "everything" (that is all newly
written code) you get full static checks. But during developement
you are allowed to test earlier (just after you recompile changed
part).
And BTW, we have user levels. At 'interpreter' user level you
are not allowed to compile anything, so no danger to your session.
Just is seems that nowbody uses this user level...
--
Waldek Hebisch
[email protected]
--
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.
