66 \begin{description} |
66 \begin{description} |
67 \item[The Isabelle sources.] They are the ultimate reference for how |
67 \item[The Isabelle sources.] They are the ultimate reference for how |
68 things really work. Therefore you should not hesitate to look at the |
68 things really work. Therefore you should not hesitate to look at the |
69 way things are actually implemented. More importantly, it is often |
69 way things are actually implemented. More importantly, it is often |
70 good to look at code that does similar things as you want to do and |
70 good to look at code that does similar things as you want to do and |
71 learn from it. The UNIX command \mbox{@{text "grep -R"}} is |
71 learn from it. This tutorial contains frequently pointers to the |
|
72 Isabelle sources. Still, the UNIX command \mbox{@{text "grep -R"}} is |
72 often your best friend while programming with Isabelle, or |
73 often your best friend while programming with Isabelle, or |
73 hypersearch if you program using jEdit under MacOSX. To understand the sources, |
74 hypersearch if you program using jEdit under MacOSX. To understand the sources, |
74 it is often also necessary to track the change history of a file or |
75 it is often also necessary to track the change history of a file or |
75 files. The Mercurial repository\footnote{\url{http://isabelle.in.tum.de/repos/isabelle/}} |
76 files. The Mercurial repository\footnote{\url{http://isabelle.in.tum.de/repos/isabelle/}} |
76 for Isabelle provides convenient interfaces to query the history of |
77 for Isabelle provides convenient interfaces to query the history of |
131 |
132 |
132 section {* Aaaaargh! My Code Does not Work Anymore *} |
133 section {* Aaaaargh! My Code Does not Work Anymore *} |
133 |
134 |
134 text {* |
135 text {* |
135 One unpleasant aspect of any code development inside a larger system is that |
136 One unpleasant aspect of any code development inside a larger system is that |
136 one has to aim at a ``moving target''. The Isabelle system is no exception. Every |
137 one has to aim at a ``moving target''. Isabelle is no exception. Every |
137 update lets potentially all hell break loose, because other developers have |
138 update lets potentially all hell break loose, because other developers have |
138 changed code you are relying on. Cursing is somewhat helpful in such situations, |
139 changed code you are relying on. Cursing is somewhat helpful in such situations, |
139 but taking the view that incompatible code changes are a fact of life |
140 but taking the view that incompatible code changes are a fact of life |
140 might be more gratifying. Isabelle is a research project. In most circumstances |
141 might be more gratifying. Isabelle is a research project. In most circumstances |
141 it is just impossible to make research backward compatible (imagine Darwin |
142 it is just impossible to make research backward compatible (imagine Darwin |
142 attempting to make the Theory of Evolution backward compatible). |
143 attempting to make the Theory of Evolution backward compatible). |
143 |
144 |
144 However, there are a few steps you can take to mitigate unwanted interferences |
145 However, there are a few steps you can take to mitigate unwanted |
145 with code changes from other developers. First, you can base your code on the latest |
146 interferences with code changes from other developers. First, you can base |
146 stable release of Isabelle (it is aimed to have one such release at least |
147 your code on the latest stable release of Isabelle (it is aimed to have one |
147 once every year). This |
148 such release at least once every year). This might cut you off from the |
148 might cut you off from the latest feature |
149 latest feature implemented in Isabelle, but at least you do not have to |
149 implemented in Isabelle, but at least you do not have to track side-steps |
150 track side-steps or dead-ends in the Isabelle development. Of course this |
150 or dead-ends in the Isabelle development. Of course this means also you have |
151 means also you have to synchronise your code at the next stable release. If |
151 to synchronise your code at the next stable release. Another possibility |
152 you do not synchronise, be warned that code seems to ``rot'' very |
152 is to get your code into the Isabelle distribution. For this you have |
153 quickly. Another possibility is to get your code into the Isabelle |
153 to convince other developers that your code or project is of general interest. |
154 distribution. For this you have to convince other developers that your code |
154 If you managed to do this, then the problem of the moving target goes |
155 or project is of general interest. If you managed to do this, then the |
155 away, because when checking in new code, developers are strongly urged to |
156 problem of the moving target goes away, because when checking in new code, |
156 test it against Isabelle's code base. If your project is part of that code base, |
157 developers are strongly urged to test it against Isabelle's code base. If |
157 then maintenance is done by others. Unfortunately, this might not |
158 your project is part of that code base, then maintenance is done by |
158 be a helpful advice for all types of projects. A lower threshold for inclusion has the |
159 others. Unfortunately, this might not be a helpful advice for all types of |
159 Archive of Formalised Proofs, short AFP.\footnote{\url{http://afp.sourceforge.net/}} |
160 projects. A lower threshold for inclusion has the Archive of Formalised |
160 This archive has been created mainly for formalisations that are |
161 Proofs, short AFP.\footnote{\url{http://afp.sourceforge.net/}} This archive |
161 interesting but not necessarily of general interest. If you have ML-code as |
162 has been created mainly for formalisations that are interesting but not |
162 part of a formalisation, then this might be the right place for you. There |
163 necessarily of general interest. If you have ML-code as part of a |
163 is no problem with updating your code after submission. At the moment |
164 formalisation, then this might be the right place for you. There is no |
164 developers are not as diligent with checking their code against the AFP than |
165 problem with updating your code after submission. At the moment developers |
165 with checking agains the distribution, but generally problems will be caught |
166 are not as diligent with checking their code against the AFP than with |
166 and the developer, who caused them, is expected to fix them. So also |
167 checking agains the distribution, but generally problems will be caught and |
167 in this case code maintenance is done for you. |
168 the developer, who caused them, is expected to fix them. So also in this |
168 |
169 case code maintenance is done for you. |
169 *} |
170 *} |
170 |
171 |
171 section {* Some Naming Conventions in the Isabelle Sources *} |
172 section {* Some Naming Conventions in the Isabelle Sources *} |
172 |
173 |
173 text {* |
174 text {* |