From gerwin.klein at nicta.com.au  Wed Oct  1 01:19:21 2008
From: gerwin.klein at nicta.com.au (Gerwin Klein)
Date: Wed, 01 Oct 2008 09:19:21 +1000
Subject: [isabelle-dev] [Fwd: SourceForge.net CVS Migration and Downtime
 Announcement]
In-Reply-To: <Pine.LNX.4.64.0809301255400.27911@macbroy20.informatik.tu-muenchen.de>
References: <48E14C9B.7080302@nicta.com.au>
	<Pine.LNX.4.64.0809301255400.27911@macbroy20.informatik.tu-muenchen.de>
Message-ID: <48E2B3F9.9060503@nicta.com.au>

Makarius wrote:
> On Tue, 30 Sep 2008, Gerwin Klein wrote:
> 
>> While we're at it: what is the general feeling towards migrating the AFP 
>> to svn?
>>
>> (Mercurial would be nicer, but sourceforge offers only CVS and SVN).
>>
>> pro: more flexible, renaming of directories, better handling of branches,
>>      "atomic" commits
>> con: we need to migrate
> 
> My feeling is that converting *to* SVN is about two years late.  Many 
> projects are already moving away *from* SVN, to Git or Mercurial.
> 
> Did you check 
> http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting ? The 
> Repository host need not coincide with the webspace, if you worry about 
> the afp.sf.net URL.  There are also some hacks to make it work with 
> SourceForge 
> http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge but 
> this is probably not quite what the hoster expects.

I'm not really comfortable with using repository hacks on the SF web space. 
They are more and more restricting access to it and we've already gotten a 
quota increase from them (making an even bigger one less likely).

Off-site hosting might be an idea, but one of the original reasons to choose 
SF was low admin overhead (adding new users etc), while still getting general 
accessibility, large-scale data replication, automated backups etc. If we 
start spreading out at least the overhead will increase.

The general feeling seems to range from "no need" (most) to "why not/keen" 
(some) to "let's do more".

Taking into account that I don't really have a lot of time at the moment to do 
the migration, I'd rather wait until they support Mercurial properly and then 
move there directly (unless we run into major hassles with CVS in the meantime).

Cheers,
Gerwin

From lp15 at cam.ac.uk  Wed Oct  1 10:21:45 2008
From: lp15 at cam.ac.uk (Lawrence Paulson)
Date: Wed, 1 Oct 2008 09:21:45 +0100
Subject: [isabelle-dev] Fwd: Broken link
References: <F67B1E01-422D-45FE-9427-FB25AA7638A4@cap-lore.com>
Message-ID: <2187399D-9731-407C-BC03-95C2566F4461@cam.ac.uk>

The error that he refers to concerns the relative links in the  
following HTML source code:

<ul> <li><a href="HOL/index.html">HOL (Higher-Order Logic)</a> is a  
version of classical higher-order logic resembling that of the <a  
href="http://www.cl.cam.ac.uk/Research/HVG/HOL/">HOL System</a>.</li>  
<li><a href="HOLCF/index.html">HOLCF (Higher-Order Logic of Computable  
Functions)</a> adds Scott's Logic for Computable Functions (domain  
theory) to HOL.</li> </ul>

In fact, all the links to logics in the theory library section are  
broken.

Larry

Begin forwarded message:

> From: Norman Hardy <norm at cap-lore.com>
> Date: 1 October 2008 01:30:42 BST
> To: Larry.Paulson at cl.cam.ac.uk
> Subject: Broken link
>
> The page at http://isabelle.in.tum.de/documentation.html
> has a link with URL http://isabelle.in.tum.de/HOL/index.html
> That URL returns "Not found".


From makarius at sketis.net  Wed Oct  1 10:36:40 2008
From: makarius at sketis.net (Makarius)
Date: Wed, 1 Oct 2008 10:36:40 +0200 (CEST)
Subject: [isabelle-dev] Fwd: Broken link
In-Reply-To: <2187399D-9731-407C-BC03-95C2566F4461@cam.ac.uk>
References: <F67B1E01-422D-45FE-9427-FB25AA7638A4@cap-lore.com>
	<2187399D-9731-407C-BC03-95C2566F4461@cam.ac.uk>
Message-ID: <Pine.LNX.4.64.0810011035120.22683@macbroy20.informatik.tu-muenchen.de>

On Wed, 1 Oct 2008, Lawrence Paulson wrote:

> In fact, all the links to logics in the theory library section are 
> broken.

I have fixed this problem of Isabelle2008 already, and said so recently in 
an answer to somebody on isabelle-users.


	Makarius

From florian.haftmann at informatik.tu-muenchen.de  Thu Oct  2 09:14:37 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Thu, 02 Oct 2008 09:14:37 +0200
Subject: [isabelle-dev] An ARBITRARY question
Message-ID: <48E474DD.9080304@informatik.tu-muenchen.de>

Some years ago two further constants were introduces into HOL.thy:
"undefined" and "default".  The idea then was to divide the role of
classical "arbitrary" on two shoulders:  "undefined" should be
unspecified an could be used to fake partiality, whereas "default" would
be overloaded and could be instantiated on arbitrary types, which is
useful e.g. for proof extraction.  Meanwhile the code dealing with
unspecified case clauses and missing primrec equations etc. has already
switched from "arbitrary" to "undefined".

I would suggest to walk through and drop any remaining occurence of
"arbitrary" by "undefined".

But perhaps "arbitrary" is too deep-rooted in HOL tradition to just get
rid of it.  Any further arguments against?

	Florian

-- 

PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailmanbroy.informatik.tu-muenchen.de/pipermail/isabelle-dev/attachments/20081002/0bf82e20/attachment.pgp>

From nipkow at in.tum.de  Thu Oct  2 19:44:47 2008
From: nipkow at in.tum.de (Tobias Nipkow)
Date: Thu, 02 Oct 2008 19:44:47 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E474DD.9080304@informatik.tu-muenchen.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
Message-ID: <48E5088F.8070002@in.tum.de>

"undefined" and "default" are used in a specific way. If you do not want
that functionality (and accidental equalities), "arbitrary" is a good
alternative.

Tobias

Florian Haftmann schrieb:
> Some years ago two further constants were introduces into HOL.thy:
> "undefined" and "default".  The idea then was to divide the role of
> classical "arbitrary" on two shoulders:  "undefined" should be
> unspecified an could be used to fake partiality, whereas "default" would
> be overloaded and could be instantiated on arbitrary types, which is
> useful e.g. for proof extraction.  Meanwhile the code dealing with
> unspecified case clauses and missing primrec equations etc. has already
> switched from "arbitrary" to "undefined".
> 
> I would suggest to walk through and drop any remaining occurence of
> "arbitrary" by "undefined".
> 
> But perhaps "arbitrary" is too deep-rooted in HOL tradition to just get
> rid of it.  Any further arguments against?
> 
> 	Florian
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Isabelle-dev mailing list
> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev

From lp15 at cam.ac.uk  Fri Oct  3 10:47:47 2008
From: lp15 at cam.ac.uk (Lawrence Paulson)
Date: Fri, 3 Oct 2008 09:47:47 +0100
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E5088F.8070002@in.tum.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
Message-ID: <0A5776E3-2519-4E7A-9BBD-57581BDA8CF4@cam.ac.uk>

What is the difference between  willundefined and arbitrary?
Larry

On 2 Oct 2008, at 18:44, Tobias Nipkow wrote:

> "undefined" and "default" are used in a specific way. If you do not  
> want
> that functionality (and accidental equalities), "arbitrary" is a good
> alternative.
>
> Tobias
>
> Florian Haftmann schrieb:
>> Some years ago two further constants were introduces into HOL.thy:
>> "undefined" and "default".  The idea then was to divide the role of
>> classical "arbitrary" on two shoulders:  "undefined" should be
>> unspecified an could be used to fake partiality, whereas "default"  
>> would
>> be overloaded and could be instantiated on arbitrary types, which is
>> useful e.g. for proof extraction.  Meanwhile the code dealing with
>> unspecified case clauses and missing primrec equations etc. has  
>> already
>> switched from "arbitrary" to "undefined".
>>
>> I would suggest to walk through and drop any remaining occurence of
>> "arbitrary" by "undefined".
>>
>> But perhaps "arbitrary" is too deep-rooted in HOL tradition to just  
>> get
>> rid of it.  Any further arguments against?
>>
>> 	Florian
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Isabelle-dev mailing list
>> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
>> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
> _______________________________________________
> Isabelle-dev mailing list
> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev


From lp15 at cam.ac.uk  Fri Oct  3 10:48:38 2008
From: lp15 at cam.ac.uk (Lawrence Paulson)
Date: Fri, 3 Oct 2008 09:48:38 +0100
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E5088F.8070002@in.tum.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
Message-ID: <E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>

Apologies for that garbled message. I meant,

	What is the difference between undefined and arbitrary?

Larry

On 2 Oct 2008, at 18:44, Tobias Nipkow wrote:

> "undefined" and "default" are used in a specific way. If you do not  
> want
> that functionality (and accidental equalities), "arbitrary" is a good
> alternative.
>
> Tobias
>
> Florian Haftmann schrieb:
>> Some years ago two further constants were introduces into HOL.thy:
>> "undefined" and "default".  The idea then was to divide the role of
>> classical "arbitrary" on two shoulders:  "undefined" should be
>> unspecified an could be used to fake partiality, whereas "default"  
>> would
>> be overloaded and could be instantiated on arbitrary types, which is
>> useful e.g. for proof extraction.  Meanwhile the code dealing with
>> unspecified case clauses and missing primrec equations etc. has  
>> already
>> switched from "arbitrary" to "undefined".
>>
>> I would suggest to walk through and drop any remaining occurence of
>> "arbitrary" by "undefined".
>>
>> But perhaps "arbitrary" is too deep-rooted in HOL tradition to just  
>> get
>> rid of it.  Any further arguments against?
>>
>> 	Florian
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Isabelle-dev mailing list
>> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
>> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
> _______________________________________________
> Isabelle-dev mailing list
> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev


From nipkow at in.tum.de  Fri Oct  3 10:58:20 2008
From: nipkow at in.tum.de (Tobias Nipkow)
Date: Fri, 03 Oct 2008 10:58:20 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
	<E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>
Message-ID: <48E5DEAC.9090907@in.tum.de>

You can prove "hd [] = undefined" and in fact "hd [] = last []", just as
an example. This is a feature of primrec and function. But you cannot
prove "hd [] = arbitrary".

Tobias

Lawrence Paulson schrieb:
> Apologies for that garbled message. I meant,
> 
>     What is the difference between undefined and arbitrary?
> 
> Larry
> 
> On 2 Oct 2008, at 18:44, Tobias Nipkow wrote:
> 
>> "undefined" and "default" are used in a specific way. If you do not want
>> that functionality (and accidental equalities), "arbitrary" is a good
>> alternative.
>>
>> Tobias
>>
>> Florian Haftmann schrieb:
>>> Some years ago two further constants were introduces into HOL.thy:
>>> "undefined" and "default".  The idea then was to divide the role of
>>> classical "arbitrary" on two shoulders:  "undefined" should be
>>> unspecified an could be used to fake partiality, whereas "default" would
>>> be overloaded and could be instantiated on arbitrary types, which is
>>> useful e.g. for proof extraction.  Meanwhile the code dealing with
>>> unspecified case clauses and missing primrec equations etc. has already
>>> switched from "arbitrary" to "undefined".
>>>
>>> I would suggest to walk through and drop any remaining occurence of
>>> "arbitrary" by "undefined".
>>>
>>> But perhaps "arbitrary" is too deep-rooted in HOL tradition to just get
>>> rid of it.  Any further arguments against?
>>>
>>>     Florian
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Isabelle-dev mailing list
>>> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
>>> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
>>>
>> _______________________________________________
>> Isabelle-dev mailing list
>> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
>> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
>>

From makarius at sketis.net  Fri Oct  3 14:12:48 2008
From: makarius at sketis.net (Makarius)
Date: Fri, 3 Oct 2008 14:12:48 +0200 (CEST)
Subject: [isabelle-dev] NEWS
Message-ID: <Pine.LNX.4.64.0810031411340.5398@macbroy20.informatik.tu-muenchen.de>

* Wrapper script for remote SystemOnTPTP service allows to use
sledgehammer without local ATP installation (Vampire etc.).  See also
ISABELLE_HOME/contrib/SystemOnTPTP and the VAMPIRE_HOME setting
variable. (By Fabian Immler, TUM)

(CVS note: need to move Distribution/contrib/ out of the way, if it exists 
already locally.)

From florian.haftmann at informatik.tu-muenchen.de  Fri Oct  3 14:14:23 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Fri, 03 Oct 2008 14:14:23 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E5E023.7020607@in.tum.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
	<E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>
	<48E5DEAC.9090907@in.tum.de>
	<6AB830AE-2736-4E98-A37C-77C8D4590F77@cam.ac.uk>
	<48E5E023.7020607@in.tum.de>
Message-ID: <48E60C9F.9060302@informatik.tu-muenchen.de>

>> I wonder whether it is wise to have three of these. People are going to
>> attach more significance to them than they deserve. I am inclined to
>> think that we should get rid of arbitrary.
>> Larry

I also think that two would be better than three;  technically
"undefined" is the same as "arbitrary", and IMHO only one one variant
should persist.

	Florian

-- 

PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailmanbroy.informatik.tu-muenchen.de/pipermail/isabelle-dev/attachments/20081003/99ecb587/attachment.pgp>

From tjark.weber at gmx.de  Fri Oct  3 16:25:52 2008
From: tjark.weber at gmx.de (Tjark Weber)
Date: Fri, 03 Oct 2008 16:25:52 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E60C9F.9060302@informatik.tu-muenchen.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
	<E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>
	<48E5DEAC.9090907@in.tum.de>
	<6AB830AE-2736-4E98-A37C-77C8D4590F77@cam.ac.uk>
	<48E5E023.7020607@in.tum.de>
	<48E60C9F.9060302@informatik.tu-muenchen.de>
Message-ID: <1223043952.22664.3.camel@weber>

On Fri, 2008-10-03 at 14:14 +0200, Florian Haftmann wrote: 
> I also think that two would be better than three;  technically
> "undefined" is the same as "arbitrary"

Then what is the point of

  undefined_fun: "undefined x = undefined"

in HOL.thy?

Best,
Tjark


From florian.haftmann at informatik.tu-muenchen.de  Fri Oct  3 14:28:50 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Fri, 03 Oct 2008 14:28:50 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <1223043952.22664.3.camel@weber>
References: <48E474DD.9080304@informatik.tu-muenchen.de>	
	<48E5088F.8070002@in.tum.de>	
	<E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>	
	<48E5DEAC.9090907@in.tum.de>	
	<6AB830AE-2736-4E98-A37C-77C8D4590F77@cam.ac.uk>	
	<48E5E023.7020607@in.tum.de>
	<48E60C9F.9060302@informatik.tu-muenchen.de>
	<1223043952.22664.3.camel@weber>
Message-ID: <48E61002.3050800@informatik.tu-muenchen.de>

> Then what is the point of
> 
>   undefined_fun: "undefined x = undefined"
> 
> in HOL.thy?

This is essentially pointless and is so soon to be dropped that I didn't
 take the effort to even point out to it in my emails, taking the risk
that somebody would have a look a the source ;-)

	Florian

-- 

PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailmanbroy.informatik.tu-muenchen.de/pipermail/isabelle-dev/attachments/20081003/577547fb/attachment.pgp>

From makarius at sketis.net  Sat Oct  4 17:54:26 2008
From: makarius at sketis.net (Makarius)
Date: Sat, 4 Oct 2008 17:54:26 +0200 (CEST)
Subject: [isabelle-dev] NEWS
Message-ID: <Pine.LNX.4.64.0810041753100.6627@macbroy20.informatik.tu-muenchen.de>

* Simplified main Isabelle executables, with less surprises on
case-insensitive file-systems (such as Mac OS).

  - The main Isabelle tool wrapper is now called "isabelle" instead of
    "isatool."

  - The former "isabelle" alias for "isabelle-process" has been
    removed (should rarely occur to regular users).

  - The "Isabelle" alias for "isabelle-interface" has been removed.

Within scripts and make files, the Isabelle environment variables
ISABELLE_TOOL and ISABELLE_PROCESS replace old ISATOOL and ISABELLE,
respectively.  (The latter are still available as legacy feature.)

Also note that user interfaces are now better wrapped as regular
Isabelle tools instead of using the special isabelle-interface wrapper
(which can be confusing if the interface is uninstalled or changed
otherwise).  See "isabelle tty" and "isabelle emacs" for contemporary
examples.

INCOMPATIBILITY, need to adapt derivative scripts.  Users may need to
purge installed copies of Isabelle executables and re-run "isabelle
install -p ...", or use symlinks.

From florian.haftmann at informatik.tu-muenchen.de  Fri Oct 10 06:49:13 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Fri, 10 Oct 2008 06:49:13 +0200
Subject: [isabelle-dev] NEWS
Message-ID: <48EEDEC9.2030801@informatik.tu-muenchen.de>

* Unified theorem tables for both code code generators.  Thus [code
func] has disappeared and only [code] remains.  INCOMPATIBILITY.

--=20

PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_in=
formatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailmanbroy.informatik.tu-muenchen.de/pipermail/isabelle-dev/attachments/20081010/d1c766ac/attachment.pgp>

From ballarin at in.tum.de  Wed Oct 15 10:36:17 2008
From: ballarin at in.tum.de (Clemens Ballarin)
Date: Wed, 15 Oct 2008 10:36:17 +0200
Subject: [isabelle-dev] includes
Message-ID: <16F3CE02-DE1C-4CF2-9616-A5E559A2B303@in.tum.de>

Dear all,

I'm planning a major revision of the locale implementation and  
consider removing "includes" altogether.  Please get in touch if you  
have an application (outside the repository and afp) that depends on  
includes in a critical way.

Clemens



From immler at in.tum.de  Thu Oct 16 12:48:50 2008
From: immler at in.tum.de (Fabian Immler)
Date: Thu, 16 Oct 2008 12:48:50 +0200
Subject: [isabelle-dev]  NEWS
In-Reply-To: <Pine.LNX.4.64.0810041753100.6627@macbroy20.informatik.tu-muenchen.de>
References: <Pine.LNX.4.64.0810041753100.6627@macbroy20.informatik.tu-muenchen.de>
Message-ID: <48F71C12.8070107@in.tum.de>

* Generic ATP manager for Sledgehammer, based on ML threads instead of 
Posix processes. Avoids potentially expensive forking of the ML process. 
New thread-based implementation also works on non-Unix platforms 
(Cygwin). Provers are no longer hardwired, but defined within the theory 
via plain ML wrapper functions.

Basic sledgehammer commands:

- 'sledgehammer prover_1 ... prover_n' invokes the specified automated 
theorem provers on the first subgoal. Provers are run in parallel, the 
first successful result is displayed, and the other attempts are 
terminated. Provers are defined in the theory context, see also 
'print_atps'.

If no provers are given as arguments to sledgehammer, the system refers 
to the default defined as "ATP provers" preference by the user 
interface. There are additional preferences for timeout (default: 60 
seconds), and the maximum number of independent prover processes 
(default: 5); excessive provers are automatically terminated.

- 'print_atps' prints the list of automated theorem provers available to 
the sledgehammer command.

- 'atp_info' prints information about presently running provers

- 'atp_kill' terminates all presently running provers.


From ballarin at in.tum.de  Thu Oct 16 14:04:14 2008
From: ballarin at in.tum.de (Clemens Ballarin)
Date: Thu, 16 Oct 2008 14:04:14 +0200
Subject: [isabelle-dev] Duplications in AFP
Message-ID: <10A6C627-3614-4E26-BD06-5E5ACB158249@in.tum.de>

[This message is mainly directed to the AFP programme committee.]

The AFP contains clones and duplications of theory files and even  
entire directories between the entries.  For example, I recently  
discovered that JinjaThreads/DFA is an identical copy of Jinja/DFA  
(see the diff below).

While cloning cannot always be avoided, duplicates are a nuisance.   
They put additional burden on maintainers.  I suggest to change the  
AFP review policy so that clones will only be accepted in justified  
cases and duplicates (as the one above) will not be admitted altogether.

Clemens

----
lapbroy72:~/isabelle/afp-devel/thys/Jinja/DFA ballarin$ for n in  
*.thy; do diff $n ../../JinjaThreads/DFA/$n; done
2c2
<     ID:         $Id: Abstract_BV.thy,v 1.4 2008/07/25 15:07:14  
fhaftmann Exp $
---
 >     ID:         $Id: Abstract_BV.thy,v 1.4 2008/07/25 08:22:52  
fhaftmann Exp $
2c2
<     ID:         $Id: Err.thy,v 1.12 2008/10/16 07:59:45 ballarin Exp $
---
 >     ID:         $Id: Err.thy,v 1.7 2008/10/16 07:59:46 ballarin Exp $
2c2
<     ID:         $Id: Kildall.thy,v 1.12 2008/10/16 07:59:46  
ballarin Exp $
---
 >     ID:         $Id: Kildall.thy,v 1.6 2008/10/16 07:59:46  
ballarin Exp $
2c2
<     ID:         $Id: LBVComplete.thy,v 1.9 2008/07/25 15:07:15  
fhaftmann Exp $
---
 >     ID:         $Id: LBVComplete.thy,v 1.4 2008/07/25 08:22:53  
fhaftmann Exp $
2c2
<     ID:         $Id: LBVCorrect.thy,v 1.7 2008/07/25 15:07:15  
fhaftmann Exp $
---
 >     ID:         $Id: LBVCorrect.thy,v 1.4 2008/07/25 08:22:54  
fhaftmann Exp $
2c2
<     ID:         $Id: LBVSpec.thy,v 1.7 2008/07/25 15:07:16  
fhaftmann Exp $
---
 >     ID:         $Id: LBVSpec.thy,v 1.4 2008/07/25 08:22:54  
fhaftmann Exp $
2c2
<     ID:         $Id: Listn.thy,v 1.9 2008/10/16 07:59:46 ballarin  
Exp $
---
 >     ID:         $Id: Listn.thy,v 1.6 2008/10/16 07:59:46 ballarin  
Exp $
2c2
<     ID:         $Id: Opt.thy,v 1.6 2008/07/25 15:07:16 fhaftmann Exp $
---
 >     ID:         $Id: Opt.thy,v 1.3 2008/06/12 06:57:21 lsf37 Exp $
2c2
<     ID:         $Id: Product.thy,v 1.10 2008/07/25 15:07:16  
fhaftmann Exp $
---
 >     ID:         $Id: Product.thy,v 1.6 2008/07/25 08:22:54  
fhaftmann Exp $
2c2
<     ID:         $Id: Semilat.thy,v 1.10 2008/07/25 15:07:17  
fhaftmann Exp $
---
 >     ID:         $Id: Semilat.thy,v 1.6 2008/07/25 08:22:55  
fhaftmann Exp $
2c2
<     ID:         $Id: SemilatAlg.thy,v 1.7 2008/10/16 07:59:46  
ballarin Exp $
---
 >     ID:         $Id: SemilatAlg.thy,v 1.5 2008/10/16 07:59:46  
ballarin Exp $
2c2
<     ID:         $Id: Semilattices.thy,v 1.4 2008/07/25 15:07:17  
fhaftmann Exp $
---
 >     ID:         $Id: Semilattices.thy,v 1.4 2008/07/25 07:12:11  
fhaftmann Exp $
2c2
<     ID:         $Id: Typing_Framework.thy,v 1.4 2008/07/25 15:07:17  
fhaftmann Exp $
---
 >     ID:         $Id: Typing_Framework.thy,v 1.3 2008/06/12  
06:57:22 lsf37 Exp $
2c2
<     ID:         $Id: Typing_Framework_err.thy,v 1.4 2008/07/25  
15:07:17 fhaftmann Exp $
---
 >     ID:         $Id: Typing_Framework_err.thy,v 1.3 2008/06/12  
06:57:22 lsf37 Exp $



From makarius at sketis.net  Thu Oct 16 23:46:34 2008
From: makarius at sketis.net (Makarius)
Date: Thu, 16 Oct 2008 23:46:34 +0200 (CEST)
Subject: [isabelle-dev] NEWS
Message-ID: <Pine.LNX.4.64.0810162345040.25444@macbroy20.informatik.tu-muenchen.de>

* Goal-directed proof now enforces strict proof irrelevance wrt. sort
hypotheses.  Sorts required in the course of reasoning need to be
covered by the constraints in the initial statement, completed by the
type instance information of the background theory.  Non-trivial sort
hypotheses, which rarely occur in practice, may be specified via
vacuous propositions of the form SORT_CONSTRAIN('a::c).  For example:

  lemma assumes "SORT_CONSTRAINT('a::empty)" shows False ...

The result contains an implicit sort hypotheses as before --
SORT_CONSTRAINT premises are eliminated as part of the canonical
rule normalization.


From makarius at sketis.net  Tue Oct 21 20:09:53 2008
From: makarius at sketis.net (Makarius)
Date: Tue, 21 Oct 2008 20:09:53 +0200 (CEST)
Subject: [isabelle-dev] Multicore performance preview
Message-ID: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>

Here are some numbers of the next stage of parallelism in Isabelle, where 
both the theory graph structure and the inherent irrelevance of proofs is 
taken into account.  The hardware is a Mac Pro with 4 cores (i.e. 2 plain 
old dual-core Xeons); times are for isabelle usedir -M 4 vs. -M 1 in 
alternating lines:

Finished HOL (0:03:30 elapsed time, 0:06:17 cpu time, factor 1.79)
Finished HOL (0:05:05 elapsed time, 0:05:04 cpu time, factor 0.99)
Finished HOL-Algebra (0:01:36 elapsed time, 0:03:09 cpu time, factor 1.96)
Finished HOL-Algebra (0:02:46 elapsed time, 0:02:44 cpu time, factor 0.98)
Finished HOL-Auth (0:02:11 elapsed time, 0:06:44 cpu time, factor 3.08)
Finished HOL-Auth (0:06:08 elapsed time, 0:06:08 cpu time, factor 1.00)
Finished HOL-Bali (0:02:31 elapsed time, 0:04:12 cpu time, factor 1.66)
Finished HOL-Bali (0:03:39 elapsed time, 0:03:46 cpu time, factor 1.03)
Finished HOL-HoareParallel (0:01:35 elapsed time, 0:04:15 cpu time, factor 2.68)
Finished HOL-HoareParallel (0:03:56 elapsed time, 0:03:57 cpu time, factor 1.00)
Finished HOL-Library (0:01:10 elapsed time, 0:02:55 cpu time, factor 2.50)
Finished HOL-Library (0:02:25 elapsed time, 0:02:29 cpu time, factor 1.02)
Finished HOL-Main (0:01:52 elapsed time, 0:03:10 cpu time, factor 1.69)
Finished HOL-Main (0:02:34 elapsed time, 0:02:34 cpu time, factor 1.00)
Finished HOL-MetisExamples (0:00:17 elapsed time, 0:00:42 cpu time, factor 2.47)
Finished HOL-MetisExamples (0:00:36 elapsed time, 0:00:35 cpu time, factor 0.97)
Finished HOL-MicroJava (0:02:09 elapsed time, 0:05:18 cpu time, factor 2.46)
Finished HOL-MicroJava (0:04:52 elapsed time, 0:04:54 cpu time, factor 1.00)
Finished HOL-Nominal (0:00:21 elapsed time, 0:00:26 cpu time, factor 1.23)
Finished HOL-Nominal (0:00:24 elapsed time, 0:00:22 cpu time, factor 0.91)
Finished HOL-Nominal-Examples (0:05:25 elapsed time, 0:13:42 cpu time, factor 2.52)
Finished HOL-Nominal-Examples (0:11:39 elapsed time, 0:12:31 cpu time, factor 1.07)
Finished HOL-Plain (0:00:53 elapsed time, 0:01:24 cpu time, factor 1.58)
Finished HOL-Plain (0:01:09 elapsed time, 0:01:07 cpu time, factor 0.97)
Finished HOL-SET-Protocol (0:00:51 elapsed time, 0:02:07 cpu time, factor 2.49)
Finished HOL-SET-Protocol (0:01:58 elapsed time, 0:01:58 cpu time, factor 1.00)
Finished HOL-UNITY (0:01:17 elapsed time, 0:02:29 cpu time, factor 1.93)
Finished HOL-UNITY (0:02:11 elapsed time, 0:02:09 cpu time, factor 0.98)
...
0:37:28 elapsed time, 1:17:00 cpu time, factor 2.05
1:06:14 elapsed time, 1:07:10 cpu time, factor 1.01

In order to try it yourself you need to enable the future_scheduler option 
in src/Pure/Concurrent/ROOT.ML; those with 8 core Macs should get slightly 
better numbers.  Does anybody have 12 or 16 cores around?

You will need the latest Poly/ML 5.2.1 version to prevent a strange GC 
deadlock problem in 5.1/5.2.

Apart from that the main reason why the new scheduler is still inactive by 
default are a couple of legacy features in Isabelle/HOL packages. The 
struggle to get rid of legacy stuff will continue ...


	Makarius

From berghofe at in.tum.de  Tue Oct 21 22:31:57 2008
From: berghofe at in.tum.de (Stefan Berghofer)
Date: Tue, 21 Oct 2008 22:31:57 +0200
Subject: [isabelle-dev] Multicore performance preview
In-Reply-To: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>
References: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>
Message-ID: <48FE3C3D.7000604@in.tum.de>

Makarius wrote:
> You will need the latest Poly/ML 5.2.1 version to prevent a strange GC 
> deadlock problem in 5.1/5.2.

Where can I get the latest version? The latest version offered for download
on the Sourceforge page

  http://sourceforge.net/project/showfiles.php?group_id=148318&package_id=163589

is still 5.2....

Greetings,
Stefan

-- 
Dr. Stefan Berghofer               E-Mail: berghofe at in.tum.de
Institut fuer Informatik           Phone: +49 89 289 17328
Technische Universitaet Muenchen   Fax:   +49 89 289 17307
Boltzmannstr. 3                    Room: 01.11.059
85748 Garching, GERMANY            http://www.in.tum.de/~berghofe

From makarius at sketis.net  Tue Oct 21 22:36:36 2008
From: makarius at sketis.net (Makarius)
Date: Tue, 21 Oct 2008 22:36:36 +0200 (CEST)
Subject: [isabelle-dev] Multicore performance preview
In-Reply-To: <48FE3C3D.7000604@in.tum.de>
References: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>
	<48FE3C3D.7000604@in.tum.de>
Message-ID: <Pine.LNX.4.64.0810212234230.31553@macbroy20.informatik.tu-muenchen.de>

On Tue, 21 Oct 2008, Stefan Berghofer wrote:

> Makarius wrote:
> > You will need the latest Poly/ML 5.2.1 version to prevent a strange GC 
> > deadlock problem in 5.1/5.2.
> 
> Where can I get the latest version? The latest version offered for download
> on the Sourceforge page
> 
>   http://sourceforge.net/project/showfiles.php?group_id=148318&package_id=163589
> 
> is still 5.2....

You are right, 5.2.1 has not been published yet.  The present CVS version 
is more or less at the same state, see e.g. our /home/polyml/polyml-cvs/.


	Makarius

From makarius at sketis.net  Wed Oct 22 22:55:28 2008
From: makarius at sketis.net (Makarius)
Date: Wed, 22 Oct 2008 22:55:28 +0200 (CEST)
Subject: [isabelle-dev] [polyml] Release 5.2.1 (fwd)
Message-ID: <Pine.LNX.4.64.0810222252290.23310@macbroy20.informatik.tu-muenchen.de>

Our usual packages for use with Isabelle are available here: 
http://isabelle.in.tum.de/polyml-5.2.1/

For any serious use of multithreading in recent development snapshots 
Poly/ML 5.2.1 is really required, but there is no immediate need to 
recompile the official Isabelle2008.


	Makarius

---------- Forwarded message ----------
Date: Wed, 22 Oct 2008 20:10:34 +0100
From: David Matthews <David.Matthews at prolingua.co.uk>
To: PolyML mailing list <polyml at inf.ed.ac.uk>
Subject: [polyml] Release 5.2.1

I've now released version 5.2.1 of Poly/ML on the SourceForge site. This is
largely a bug-fix release of 5.2 and incorporates various fixes to the run-time
system and basis library.  I'll update the release notes on the web site with
details of the bug fixes.  The functional IO library has been largely rewritten
to be much more efficient.

One change that may affect a few people is that X-Windows/Motif support is now
turned off by default in the configure script.  To include support for
X-Windows/Motif specify --with-x when running "configure"

Note: Since the compiler has not changed when you run Poly/ML 5.2.1 the start-up
line will still say "Poly/ML 5.2 Release".  However poly -v will say something
like
Poly/ML 5.2 Release    RTS version: I386-5.2.1

David

_______________________________________________
polyml mailing list
polyml at inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

From David.Matthews at prolingua.co.uk  Wed Oct 22 21:16:08 2008
From: David.Matthews at prolingua.co.uk (David Matthews)
Date: Wed, 22 Oct 2008 20:16:08 +0100
Subject: [isabelle-dev] Multicore performance preview
In-Reply-To: <Pine.LNX.4.64.0810212234230.31553@macbroy20.informatik.tu-muenchen.de>
References: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>	<48FE3C3D.7000604@in.tum.de>
	<Pine.LNX.4.64.0810212234230.31553@macbroy20.informatik.tu-muenchen.de>
Message-ID: <48FF7BF8.6040006@prolingua.co.uk>

Makarius wrote:
> On Tue, 21 Oct 2008, Stefan Berghofer wrote:
> 
>> Makarius wrote:
>>> You will need the latest Poly/ML 5.2.1 version to prevent a strange GC 
>>> deadlock problem in 5.1/5.2.
>> Where can I get the latest version? The latest version offered for download
>> on the Sourceforge page
>>
>>   http://sourceforge.net/project/showfiles.php?group_id=148318&package_id=163589
>>
>> is still 5.2....
> 
> You are right, 5.2.1 has not been published yet.  The present CVS version 
> is more or less at the same state, see e.g. our /home/polyml/polyml-cvs/.

Makarius was being slightly premature by announcing it yesterday. 
Poly/ML 5.2.1 has now been released and you should find it on 
SourceForge.  It's nice to see the speed-ups, though.

David

From makarius at sketis.net  Thu Oct 23 15:32:07 2008
From: makarius at sketis.net (Makarius)
Date: Thu, 23 Oct 2008 15:32:07 +0200 (CEST)
Subject: [isabelle-dev] NEWS (update)
Message-ID: <Pine.LNX.4.64.0810231531410.30759@macbroy20.informatik.tu-muenchen.de>

* Multithreading for Poly/ML 5.1/5.2 is no longer supported, only for
Poly/ML 5.2.1 or later.


From nipkow at in.tum.de  Fri Oct 24 08:38:52 2008
From: nipkow at in.tum.de (Tobias Nipkow)
Date: Fri, 24 Oct 2008 08:38:52 +0200
Subject: [isabelle-dev] [Fwd: Fwd: E Equational Theorem Prover 1.0 "Temi"
	released]
Message-ID: <49016D7C.7090207@in.tum.de>

In case anybody feels like trying the latest Version of E (via
sledgehammer).

Tobias

-------- Original Message --------

> From: Stephan Schulz <schulz at informatik.tu-muenchen.de>
> Date: 23 October 2008 00:41:54 BST
> To: undisclosed-recipients: ;
> Subject: E Equational Theorem Prover 1.0 "Temi" released
>
>
> E 1.0 "Temi" is the latest version of the successful automated theorem
> prover.
>
> E is a theorem prover for full first order logic with equality. It has
> successfully competed in several CASC competitions and is generally
> considered a friendly and powerful system (as theorem provers go).
>
> The new version improves clausification, has a more GNU-like
> installation system, and has been updated to comply with the latest
> TPTP-3 syntax.
>
> E is available as a source distribution for UNIX-variants. It installs
> cleanly under all UNIX variants I could get my hands on: Various
> versions of GNU/Linux for Intel and SPARC, Solaris, HPUX and
> MacOS-X. Users have reported successful builds on a large number of
> other systems, including Windows/Cygwin.
>
> The system is distributed under the GNU General Public License.
>
> You can find the source distribution and additional information at
> http://www.eprover.org
>
>
> Have fun!
>
>
> Stephan
>
> -- 
> -------------------------- It can be done!  
> ---------------------------------
>      Please email me as schulz at eprover.org (Stephan Schulz)
> ----------------------------------------------------------------------------

From ac638 at cam.ac.uk  Mon Oct 27 16:50:35 2008
From: ac638 at cam.ac.uk (Amine Chaieb)
Date: Mon, 27 Oct 2008 15:50:35 +0000
Subject: [isabelle-dev] instantiation
Message-ID: <4905E34B.3050701@cam.ac.uk>

Dear all,

(How) Can I perform an instantiation of a type-constructor with two 
arguments, an thereby restricting them to be the same?

Concrete problem:

instantiation "fun" (type, type) power
begin
....

end


but I want only to raise functions of type 'a => 'a to powers.

Thank you for any hint!

best wishes,
Amine.

From florian.haftmann at informatik.tu-muenchen.de  Mon Oct 27 16:53:17 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Mon, 27 Oct 2008 16:53:17 +0100
Subject: [isabelle-dev] instantiation
In-Reply-To: <4905E34B.3050701@cam.ac.uk>
References: <4905E34B.3050701@cam.ac.uk>
Message-ID: <4905E3ED.4010800@informatik.tu-muenchen.de>

Amine Chaieb schrieb:
> Dear all,
> 
> (How) Can I perform an instantiation of a type-constructor with two
> arguments, an thereby restricting them to be the same?

This is beyond the type class system of Isabelle.  A pity.

	Florian

-- 

http://isabelle.in.tum.de/~haftmann
PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailmanbroy.informatik.tu-muenchen.de/pipermail/isabelle-dev/attachments/20081027/20ef8c26/attachment.pgp>

From ac638 at cam.ac.uk  Mon Oct 27 17:03:07 2008
From: ac638 at cam.ac.uk (Amine Chaieb)
Date: Mon, 27 Oct 2008 16:03:07 +0000
Subject: [isabelle-dev] instantiation
In-Reply-To: <4905E3ED.4010800@informatik.tu-muenchen.de>
References: <4905E34B.3050701@cam.ac.uk>
	<4905E3ED.4010800@informatik.tu-muenchen.de>
Message-ID: <4905E63B.1000006@cam.ac.uk>

:( I also failed a few weeks ago to instantiate the fold combinator to 
iterate function composition ...

But is this restriction fundamental or does it happen to be there?

Amine.

Florian Haftmann wrote:
> Amine Chaieb schrieb:
>> Dear all,
>>
>> (How) Can I perform an instantiation of a type-constructor with two
>> arguments, an thereby restricting them to be the same?
> 
> This is beyond the type class system of Isabelle.  A pity.
> 
> 	Florian
> 

From florian.haftmann at informatik.tu-muenchen.de  Tue Oct 28 08:12:53 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Tue, 28 Oct 2008 08:12:53 +0100
Subject: [isabelle-dev] instantiation
In-Reply-To: <4905E63B.1000006@cam.ac.uk>
References: <4905E34B.3050701@cam.ac.uk>	<4905E3ED.4010800@informatik.tu-muenchen.de>
	<4905E63B.1000006@cam.ac.uk>
Message-ID: <4906BB75.7090408@informatik.tu-muenchen.de>

> :( I also failed a few weeks ago to instantiate the fold combinator to
> iterate function composition ...

Hmmm... perhaps "fold (op o) id id" is what you want in that case.

> But is this restriction fundamental or does it happen to be there?

Well, the type classes in Isabelle are an instance of order-sorted
algebra which demands type arguments to be free.  Perhaps it is possible
to relax this without smashing the meta theory (I don't know the
answer).  Anyway, this would mean a lot of work...

	Florian

-- 

http://isabelle.in.tum.de/~haftmann
PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailmanbroy.informatik.tu-muenchen.de/pipermail/isabelle-dev/attachments/20081028/7432aca0/attachment.pgp>

From lp15 at cam.ac.uk  Tue Oct 28 11:06:41 2008
From: lp15 at cam.ac.uk (Lawrence Paulson)
Date: Tue, 28 Oct 2008 10:06:41 +0000
Subject: [isabelle-dev] NEWS
Message-ID: <EC67EEB8-2B45-41D1-AAB5-2BFE6E3F391C@cam.ac.uk>

* The metis method no longer fails because the theorem is too trivial
(contains the empty clause).

Larry


From webertj at in.tum.de  Wed Oct 29 06:46:44 2008
From: webertj at in.tum.de (Tjark Weber)
Date: Wed, 29 Oct 2008 13:46:44 +0800
Subject: [isabelle-dev] instantiation
In-Reply-To: <4905E3ED.4010800@informatik.tu-muenchen.de>
References: <4905E34B.3050701@cam.ac.uk>
	<4905E3ED.4010800@informatik.tu-muenchen.de>
Message-ID: <1225259204.3025.6.camel@weber>

On Mon, 2008-10-27 at 16:53 +0100, Florian Haftmann wrote:
> Amine Chaieb schrieb:
> > (How) Can I perform an instantiation of a type-constructor with two
> > arguments, an thereby restricting them to be the same?
> 
> This is beyond the type class system of Isabelle.  A pity.

While this may not give you what you wanted, you can of course state
(and trivially prove)

  lemma "OFCLASS('a => 'a, power_class)"
  by intro_classes

Best,
Tjark


From ballarin at in.tum.de  Thu Oct 30 11:02:11 2008
From: ballarin at in.tum.de (Clemens Ballarin)
Date: Thu, 30 Oct 2008 11:02:11 +0100
Subject: [isabelle-dev] NEWS
Message-ID: <733181BA-E4D4-4E23-9C25-C3892F07A619@in.tum.de>

* Dropped locale element "includes".  This is a major INCOMPATIBILITY.

In existing theorem specifications replace the includes element by the
respective context elements of the included locale, omitting those that
are already present in the theorem specification.  Multiple assume
elements of a locale should be replaced by a single one involving the
locale predicate.  In the proof body, declarations (most notably
theorems) may be regained by interpreting the respective locales in the
proof context as required (command "interpret").

If using "includes" in replacement of a target solely because the
parameter types in the theorem are not as general as in the target,
consider declaring a new locale with additional type constraints on the
parameters (context element "constrains").

Clemens


From gerwin.klein at nicta.com.au  Wed Oct  1 01:19:21 2008
From: gerwin.klein at nicta.com.au (Gerwin Klein)
Date: Wed, 01 Oct 2008 09:19:21 +1000
Subject: [isabelle-dev] [Fwd: SourceForge.net CVS Migration and Downtime
 Announcement]
In-Reply-To: <Pine.LNX.4.64.0809301255400.27911@macbroy20.informatik.tu-muenchen.de>
References: <48E14C9B.7080302@nicta.com.au>
	<Pine.LNX.4.64.0809301255400.27911@macbroy20.informatik.tu-muenchen.de>
Message-ID: <48E2B3F9.9060503@nicta.com.au>

Makarius wrote:
> On Tue, 30 Sep 2008, Gerwin Klein wrote:
> 
>> While we're at it: what is the general feeling towards migrating the AFP 
>> to svn?
>>
>> (Mercurial would be nicer, but sourceforge offers only CVS and SVN).
>>
>> pro: more flexible, renaming of directories, better handling of branches,
>>      "atomic" commits
>> con: we need to migrate
> 
> My feeling is that converting *to* SVN is about two years late.  Many 
> projects are already moving away *from* SVN, to Git or Mercurial.
> 
> Did you check 
> http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting ? The 
> Repository host need not coincide with the webspace, if you worry about 
> the afp.sf.net URL.  There are also some hacks to make it work with 
> SourceForge 
> http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge but 
> this is probably not quite what the hoster expects.

I'm not really comfortable with using repository hacks on the SF web space. 
They are more and more restricting access to it and we've already gotten a 
quota increase from them (making an even bigger one less likely).

Off-site hosting might be an idea, but one of the original reasons to choose 
SF was low admin overhead (adding new users etc), while still getting general 
accessibility, large-scale data replication, automated backups etc. If we 
start spreading out at least the overhead will increase.

The general feeling seems to range from "no need" (most) to "why not/keen" 
(some) to "let's do more".

Taking into account that I don't really have a lot of time at the moment to do 
the migration, I'd rather wait until they support Mercurial properly and then 
move there directly (unless we run into major hassles with CVS in the meantime).

Cheers,
Gerwin


From lp15 at cam.ac.uk  Wed Oct  1 10:21:45 2008
From: lp15 at cam.ac.uk (Lawrence Paulson)
Date: Wed, 1 Oct 2008 09:21:45 +0100
Subject: [isabelle-dev] Fwd: Broken link
References: <F67B1E01-422D-45FE-9427-FB25AA7638A4@cap-lore.com>
Message-ID: <2187399D-9731-407C-BC03-95C2566F4461@cam.ac.uk>

The error that he refers to concerns the relative links in the  
following HTML source code:

<ul> <li><a href="HOL/index.html">HOL (Higher-Order Logic)</a> is a  
version of classical higher-order logic resembling that of the <a  
href="http://www.cl.cam.ac.uk/Research/HVG/HOL/">HOL System</a>.</li>  
<li><a href="HOLCF/index.html">HOLCF (Higher-Order Logic of Computable  
Functions)</a> adds Scott's Logic for Computable Functions (domain  
theory) to HOL.</li> </ul>

In fact, all the links to logics in the theory library section are  
broken.

Larry

Begin forwarded message:

> From: Norman Hardy <norm at cap-lore.com>
> Date: 1 October 2008 01:30:42 BST
> To: Larry.Paulson at cl.cam.ac.uk
> Subject: Broken link
>
> The page at http://isabelle.in.tum.de/documentation.html
> has a link with URL http://isabelle.in.tum.de/HOL/index.html
> That URL returns "Not found".



From makarius at sketis.net  Wed Oct  1 10:36:40 2008
From: makarius at sketis.net (Makarius)
Date: Wed, 1 Oct 2008 10:36:40 +0200 (CEST)
Subject: [isabelle-dev] Fwd: Broken link
In-Reply-To: <2187399D-9731-407C-BC03-95C2566F4461@cam.ac.uk>
References: <F67B1E01-422D-45FE-9427-FB25AA7638A4@cap-lore.com>
	<2187399D-9731-407C-BC03-95C2566F4461@cam.ac.uk>
Message-ID: <Pine.LNX.4.64.0810011035120.22683@macbroy20.informatik.tu-muenchen.de>

On Wed, 1 Oct 2008, Lawrence Paulson wrote:

> In fact, all the links to logics in the theory library section are 
> broken.

I have fixed this problem of Isabelle2008 already, and said so recently in 
an answer to somebody on isabelle-users.


	Makarius


From florian.haftmann at informatik.tu-muenchen.de  Thu Oct  2 09:14:37 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Thu, 02 Oct 2008 09:14:37 +0200
Subject: [isabelle-dev] An ARBITRARY question
Message-ID: <48E474DD.9080304@informatik.tu-muenchen.de>

Some years ago two further constants were introduces into HOL.thy:
"undefined" and "default".  The idea then was to divide the role of
classical "arbitrary" on two shoulders:  "undefined" should be
unspecified an could be used to fake partiality, whereas "default" would
be overloaded and could be instantiated on arbitrary types, which is
useful e.g. for proof extraction.  Meanwhile the code dealing with
unspecified case clauses and missing primrec equations etc. has already
switched from "arbitrary" to "undefined".

I would suggest to walk through and drop any remaining occurence of
"arbitrary" by "undefined".

But perhaps "arbitrary" is too deep-rooted in HOL tradition to just get
rid of it.  Any further arguments against?

	Florian

-- 

PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailman46.in.tum.de/pipermail/isabelle-dev/attachments/20081002/0bf82e20/attachment.sig>

From nipkow at in.tum.de  Thu Oct  2 19:44:47 2008
From: nipkow at in.tum.de (Tobias Nipkow)
Date: Thu, 02 Oct 2008 19:44:47 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E474DD.9080304@informatik.tu-muenchen.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
Message-ID: <48E5088F.8070002@in.tum.de>

"undefined" and "default" are used in a specific way. If you do not want
that functionality (and accidental equalities), "arbitrary" is a good
alternative.

Tobias

Florian Haftmann schrieb:
> Some years ago two further constants were introduces into HOL.thy:
> "undefined" and "default".  The idea then was to divide the role of
> classical "arbitrary" on two shoulders:  "undefined" should be
> unspecified an could be used to fake partiality, whereas "default" would
> be overloaded and could be instantiated on arbitrary types, which is
> useful e.g. for proof extraction.  Meanwhile the code dealing with
> unspecified case clauses and missing primrec equations etc. has already
> switched from "arbitrary" to "undefined".
> 
> I would suggest to walk through and drop any remaining occurence of
> "arbitrary" by "undefined".
> 
> But perhaps "arbitrary" is too deep-rooted in HOL tradition to just get
> rid of it.  Any further arguments against?
> 
> 	Florian
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Isabelle-dev mailing list
> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev


From lp15 at cam.ac.uk  Fri Oct  3 10:47:47 2008
From: lp15 at cam.ac.uk (Lawrence Paulson)
Date: Fri, 3 Oct 2008 09:47:47 +0100
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E5088F.8070002@in.tum.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
Message-ID: <0A5776E3-2519-4E7A-9BBD-57581BDA8CF4@cam.ac.uk>

What is the difference between  willundefined and arbitrary?
Larry

On 2 Oct 2008, at 18:44, Tobias Nipkow wrote:

> "undefined" and "default" are used in a specific way. If you do not  
> want
> that functionality (and accidental equalities), "arbitrary" is a good
> alternative.
>
> Tobias
>
> Florian Haftmann schrieb:
>> Some years ago two further constants were introduces into HOL.thy:
>> "undefined" and "default".  The idea then was to divide the role of
>> classical "arbitrary" on two shoulders:  "undefined" should be
>> unspecified an could be used to fake partiality, whereas "default"  
>> would
>> be overloaded and could be instantiated on arbitrary types, which is
>> useful e.g. for proof extraction.  Meanwhile the code dealing with
>> unspecified case clauses and missing primrec equations etc. has  
>> already
>> switched from "arbitrary" to "undefined".
>>
>> I would suggest to walk through and drop any remaining occurence of
>> "arbitrary" by "undefined".
>>
>> But perhaps "arbitrary" is too deep-rooted in HOL tradition to just  
>> get
>> rid of it.  Any further arguments against?
>>
>> 	Florian
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Isabelle-dev mailing list
>> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
>> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
> _______________________________________________
> Isabelle-dev mailing list
> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev



From lp15 at cam.ac.uk  Fri Oct  3 10:48:38 2008
From: lp15 at cam.ac.uk (Lawrence Paulson)
Date: Fri, 3 Oct 2008 09:48:38 +0100
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E5088F.8070002@in.tum.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
Message-ID: <E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>

Apologies for that garbled message. I meant,

	What is the difference between undefined and arbitrary?

Larry

On 2 Oct 2008, at 18:44, Tobias Nipkow wrote:

> "undefined" and "default" are used in a specific way. If you do not  
> want
> that functionality (and accidental equalities), "arbitrary" is a good
> alternative.
>
> Tobias
>
> Florian Haftmann schrieb:
>> Some years ago two further constants were introduces into HOL.thy:
>> "undefined" and "default".  The idea then was to divide the role of
>> classical "arbitrary" on two shoulders:  "undefined" should be
>> unspecified an could be used to fake partiality, whereas "default"  
>> would
>> be overloaded and could be instantiated on arbitrary types, which is
>> useful e.g. for proof extraction.  Meanwhile the code dealing with
>> unspecified case clauses and missing primrec equations etc. has  
>> already
>> switched from "arbitrary" to "undefined".
>>
>> I would suggest to walk through and drop any remaining occurence of
>> "arbitrary" by "undefined".
>>
>> But perhaps "arbitrary" is too deep-rooted in HOL tradition to just  
>> get
>> rid of it.  Any further arguments against?
>>
>> 	Florian
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Isabelle-dev mailing list
>> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
>> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
> _______________________________________________
> Isabelle-dev mailing list
> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev



From nipkow at in.tum.de  Fri Oct  3 10:58:20 2008
From: nipkow at in.tum.de (Tobias Nipkow)
Date: Fri, 03 Oct 2008 10:58:20 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
	<E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>
Message-ID: <48E5DEAC.9090907@in.tum.de>

You can prove "hd [] = undefined" and in fact "hd [] = last []", just as
an example. This is a feature of primrec and function. But you cannot
prove "hd [] = arbitrary".

Tobias

Lawrence Paulson schrieb:
> Apologies for that garbled message. I meant,
> 
>     What is the difference between undefined and arbitrary?
> 
> Larry
> 
> On 2 Oct 2008, at 18:44, Tobias Nipkow wrote:
> 
>> "undefined" and "default" are used in a specific way. If you do not want
>> that functionality (and accidental equalities), "arbitrary" is a good
>> alternative.
>>
>> Tobias
>>
>> Florian Haftmann schrieb:
>>> Some years ago two further constants were introduces into HOL.thy:
>>> "undefined" and "default".  The idea then was to divide the role of
>>> classical "arbitrary" on two shoulders:  "undefined" should be
>>> unspecified an could be used to fake partiality, whereas "default" would
>>> be overloaded and could be instantiated on arbitrary types, which is
>>> useful e.g. for proof extraction.  Meanwhile the code dealing with
>>> unspecified case clauses and missing primrec equations etc. has already
>>> switched from "arbitrary" to "undefined".
>>>
>>> I would suggest to walk through and drop any remaining occurence of
>>> "arbitrary" by "undefined".
>>>
>>> But perhaps "arbitrary" is too deep-rooted in HOL tradition to just get
>>> rid of it.  Any further arguments against?
>>>
>>>     Florian
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Isabelle-dev mailing list
>>> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
>>> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
>>>
>> _______________________________________________
>> Isabelle-dev mailing list
>> Isabelle-dev at mailbroy.informatik.tu-muenchen.de
>> https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
>>


From makarius at sketis.net  Fri Oct  3 14:12:48 2008
From: makarius at sketis.net (Makarius)
Date: Fri, 3 Oct 2008 14:12:48 +0200 (CEST)
Subject: [isabelle-dev] NEWS
Message-ID: <Pine.LNX.4.64.0810031411340.5398@macbroy20.informatik.tu-muenchen.de>

* Wrapper script for remote SystemOnTPTP service allows to use
sledgehammer without local ATP installation (Vampire etc.).  See also
ISABELLE_HOME/contrib/SystemOnTPTP and the VAMPIRE_HOME setting
variable. (By Fabian Immler, TUM)

(CVS note: need to move Distribution/contrib/ out of the way, if it exists 
already locally.)


From florian.haftmann at informatik.tu-muenchen.de  Fri Oct  3 14:14:23 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Fri, 03 Oct 2008 14:14:23 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E5E023.7020607@in.tum.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
	<E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>
	<48E5DEAC.9090907@in.tum.de>
	<6AB830AE-2736-4E98-A37C-77C8D4590F77@cam.ac.uk>
	<48E5E023.7020607@in.tum.de>
Message-ID: <48E60C9F.9060302@informatik.tu-muenchen.de>

>> I wonder whether it is wise to have three of these. People are going to
>> attach more significance to them than they deserve. I am inclined to
>> think that we should get rid of arbitrary.
>> Larry

I also think that two would be better than three;  technically
"undefined" is the same as "arbitrary", and IMHO only one one variant
should persist.

	Florian

-- 

PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailman46.in.tum.de/pipermail/isabelle-dev/attachments/20081003/99ecb587/attachment.sig>

From tjark.weber at gmx.de  Fri Oct  3 16:25:52 2008
From: tjark.weber at gmx.de (Tjark Weber)
Date: Fri, 03 Oct 2008 16:25:52 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <48E60C9F.9060302@informatik.tu-muenchen.de>
References: <48E474DD.9080304@informatik.tu-muenchen.de>
	<48E5088F.8070002@in.tum.de>
	<E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>
	<48E5DEAC.9090907@in.tum.de>
	<6AB830AE-2736-4E98-A37C-77C8D4590F77@cam.ac.uk>
	<48E5E023.7020607@in.tum.de>
	<48E60C9F.9060302@informatik.tu-muenchen.de>
Message-ID: <1223043952.22664.3.camel@weber>

On Fri, 2008-10-03 at 14:14 +0200, Florian Haftmann wrote: 
> I also think that two would be better than three;  technically
> "undefined" is the same as "arbitrary"

Then what is the point of

  undefined_fun: "undefined x = undefined"

in HOL.thy?

Best,
Tjark



From florian.haftmann at informatik.tu-muenchen.de  Fri Oct  3 14:28:50 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Fri, 03 Oct 2008 14:28:50 +0200
Subject: [isabelle-dev] An ARBITRARY question
In-Reply-To: <1223043952.22664.3.camel@weber>
References: <48E474DD.9080304@informatik.tu-muenchen.de>	
	<48E5088F.8070002@in.tum.de>	
	<E6E1883A-5026-4261-977A-9416A8D246A3@cam.ac.uk>	
	<48E5DEAC.9090907@in.tum.de>	
	<6AB830AE-2736-4E98-A37C-77C8D4590F77@cam.ac.uk>	
	<48E5E023.7020607@in.tum.de>
	<48E60C9F.9060302@informatik.tu-muenchen.de>
	<1223043952.22664.3.camel@weber>
Message-ID: <48E61002.3050800@informatik.tu-muenchen.de>

> Then what is the point of
> 
>   undefined_fun: "undefined x = undefined"
> 
> in HOL.thy?

This is essentially pointless and is so soon to be dropped that I didn't
 take the effort to even point out to it in my emails, taking the risk
that somebody would have a look a the source ;-)

	Florian

-- 

PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailman46.in.tum.de/pipermail/isabelle-dev/attachments/20081003/577547fb/attachment.sig>

From makarius at sketis.net  Sat Oct  4 17:54:26 2008
From: makarius at sketis.net (Makarius)
Date: Sat, 4 Oct 2008 17:54:26 +0200 (CEST)
Subject: [isabelle-dev] NEWS
Message-ID: <Pine.LNX.4.64.0810041753100.6627@macbroy20.informatik.tu-muenchen.de>

* Simplified main Isabelle executables, with less surprises on
case-insensitive file-systems (such as Mac OS).

  - The main Isabelle tool wrapper is now called "isabelle" instead of
    "isatool."

  - The former "isabelle" alias for "isabelle-process" has been
    removed (should rarely occur to regular users).

  - The "Isabelle" alias for "isabelle-interface" has been removed.

Within scripts and make files, the Isabelle environment variables
ISABELLE_TOOL and ISABELLE_PROCESS replace old ISATOOL and ISABELLE,
respectively.  (The latter are still available as legacy feature.)

Also note that user interfaces are now better wrapped as regular
Isabelle tools instead of using the special isabelle-interface wrapper
(which can be confusing if the interface is uninstalled or changed
otherwise).  See "isabelle tty" and "isabelle emacs" for contemporary
examples.

INCOMPATIBILITY, need to adapt derivative scripts.  Users may need to
purge installed copies of Isabelle executables and re-run "isabelle
install -p ...", or use symlinks.


From florian.haftmann at informatik.tu-muenchen.de  Fri Oct 10 06:49:13 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Fri, 10 Oct 2008 06:49:13 +0200
Subject: [isabelle-dev] NEWS
Message-ID: <48EEDEC9.2030801@informatik.tu-muenchen.de>

* Unified theorem tables for both code code generators.  Thus [code
func] has disappeared and only [code] remains.  INCOMPATIBILITY.

--=20

PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_in=
formatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailman46.in.tum.de/pipermail/isabelle-dev/attachments/20081010/d1c766ac/attachment.sig>

From ballarin at in.tum.de  Wed Oct 15 10:36:17 2008
From: ballarin at in.tum.de (Clemens Ballarin)
Date: Wed, 15 Oct 2008 10:36:17 +0200
Subject: [isabelle-dev] includes
Message-ID: <16F3CE02-DE1C-4CF2-9616-A5E559A2B303@in.tum.de>

Dear all,

I'm planning a major revision of the locale implementation and  
consider removing "includes" altogether.  Please get in touch if you  
have an application (outside the repository and afp) that depends on  
includes in a critical way.

Clemens




From immler at in.tum.de  Thu Oct 16 12:48:50 2008
From: immler at in.tum.de (Fabian Immler)
Date: Thu, 16 Oct 2008 12:48:50 +0200
Subject: [isabelle-dev]  NEWS
In-Reply-To: <Pine.LNX.4.64.0810041753100.6627@macbroy20.informatik.tu-muenchen.de>
References: <Pine.LNX.4.64.0810041753100.6627@macbroy20.informatik.tu-muenchen.de>
Message-ID: <48F71C12.8070107@in.tum.de>

* Generic ATP manager for Sledgehammer, based on ML threads instead of 
Posix processes. Avoids potentially expensive forking of the ML process. 
New thread-based implementation also works on non-Unix platforms 
(Cygwin). Provers are no longer hardwired, but defined within the theory 
via plain ML wrapper functions.

Basic sledgehammer commands:

- 'sledgehammer prover_1 ... prover_n' invokes the specified automated 
theorem provers on the first subgoal. Provers are run in parallel, the 
first successful result is displayed, and the other attempts are 
terminated. Provers are defined in the theory context, see also 
'print_atps'.

If no provers are given as arguments to sledgehammer, the system refers 
to the default defined as "ATP provers" preference by the user 
interface. There are additional preferences for timeout (default: 60 
seconds), and the maximum number of independent prover processes 
(default: 5); excessive provers are automatically terminated.

- 'print_atps' prints the list of automated theorem provers available to 
the sledgehammer command.

- 'atp_info' prints information about presently running provers

- 'atp_kill' terminates all presently running provers.



From ballarin at in.tum.de  Thu Oct 16 14:04:14 2008
From: ballarin at in.tum.de (Clemens Ballarin)
Date: Thu, 16 Oct 2008 14:04:14 +0200
Subject: [isabelle-dev] Duplications in AFP
Message-ID: <10A6C627-3614-4E26-BD06-5E5ACB158249@in.tum.de>

[This message is mainly directed to the AFP programme committee.]

The AFP contains clones and duplications of theory files and even  
entire directories between the entries.  For example, I recently  
discovered that JinjaThreads/DFA is an identical copy of Jinja/DFA  
(see the diff below).

While cloning cannot always be avoided, duplicates are a nuisance.   
They put additional burden on maintainers.  I suggest to change the  
AFP review policy so that clones will only be accepted in justified  
cases and duplicates (as the one above) will not be admitted altogether.

Clemens

----
lapbroy72:~/isabelle/afp-devel/thys/Jinja/DFA ballarin$ for n in  
*.thy; do diff $n ../../JinjaThreads/DFA/$n; done
2c2
<     ID:         $Id: Abstract_BV.thy,v 1.4 2008/07/25 15:07:14  
fhaftmann Exp $
---
 >     ID:         $Id: Abstract_BV.thy,v 1.4 2008/07/25 08:22:52  
fhaftmann Exp $
2c2
<     ID:         $Id: Err.thy,v 1.12 2008/10/16 07:59:45 ballarin Exp $
---
 >     ID:         $Id: Err.thy,v 1.7 2008/10/16 07:59:46 ballarin Exp $
2c2
<     ID:         $Id: Kildall.thy,v 1.12 2008/10/16 07:59:46  
ballarin Exp $
---
 >     ID:         $Id: Kildall.thy,v 1.6 2008/10/16 07:59:46  
ballarin Exp $
2c2
<     ID:         $Id: LBVComplete.thy,v 1.9 2008/07/25 15:07:15  
fhaftmann Exp $
---
 >     ID:         $Id: LBVComplete.thy,v 1.4 2008/07/25 08:22:53  
fhaftmann Exp $
2c2
<     ID:         $Id: LBVCorrect.thy,v 1.7 2008/07/25 15:07:15  
fhaftmann Exp $
---
 >     ID:         $Id: LBVCorrect.thy,v 1.4 2008/07/25 08:22:54  
fhaftmann Exp $
2c2
<     ID:         $Id: LBVSpec.thy,v 1.7 2008/07/25 15:07:16  
fhaftmann Exp $
---
 >     ID:         $Id: LBVSpec.thy,v 1.4 2008/07/25 08:22:54  
fhaftmann Exp $
2c2
<     ID:         $Id: Listn.thy,v 1.9 2008/10/16 07:59:46 ballarin  
Exp $
---
 >     ID:         $Id: Listn.thy,v 1.6 2008/10/16 07:59:46 ballarin  
Exp $
2c2
<     ID:         $Id: Opt.thy,v 1.6 2008/07/25 15:07:16 fhaftmann Exp $
---
 >     ID:         $Id: Opt.thy,v 1.3 2008/06/12 06:57:21 lsf37 Exp $
2c2
<     ID:         $Id: Product.thy,v 1.10 2008/07/25 15:07:16  
fhaftmann Exp $
---
 >     ID:         $Id: Product.thy,v 1.6 2008/07/25 08:22:54  
fhaftmann Exp $
2c2
<     ID:         $Id: Semilat.thy,v 1.10 2008/07/25 15:07:17  
fhaftmann Exp $
---
 >     ID:         $Id: Semilat.thy,v 1.6 2008/07/25 08:22:55  
fhaftmann Exp $
2c2
<     ID:         $Id: SemilatAlg.thy,v 1.7 2008/10/16 07:59:46  
ballarin Exp $
---
 >     ID:         $Id: SemilatAlg.thy,v 1.5 2008/10/16 07:59:46  
ballarin Exp $
2c2
<     ID:         $Id: Semilattices.thy,v 1.4 2008/07/25 15:07:17  
fhaftmann Exp $
---
 >     ID:         $Id: Semilattices.thy,v 1.4 2008/07/25 07:12:11  
fhaftmann Exp $
2c2
<     ID:         $Id: Typing_Framework.thy,v 1.4 2008/07/25 15:07:17  
fhaftmann Exp $
---
 >     ID:         $Id: Typing_Framework.thy,v 1.3 2008/06/12  
06:57:22 lsf37 Exp $
2c2
<     ID:         $Id: Typing_Framework_err.thy,v 1.4 2008/07/25  
15:07:17 fhaftmann Exp $
---
 >     ID:         $Id: Typing_Framework_err.thy,v 1.3 2008/06/12  
06:57:22 lsf37 Exp $




From makarius at sketis.net  Thu Oct 16 23:46:34 2008
From: makarius at sketis.net (Makarius)
Date: Thu, 16 Oct 2008 23:46:34 +0200 (CEST)
Subject: [isabelle-dev] NEWS
Message-ID: <Pine.LNX.4.64.0810162345040.25444@macbroy20.informatik.tu-muenchen.de>

* Goal-directed proof now enforces strict proof irrelevance wrt. sort
hypotheses.  Sorts required in the course of reasoning need to be
covered by the constraints in the initial statement, completed by the
type instance information of the background theory.  Non-trivial sort
hypotheses, which rarely occur in practice, may be specified via
vacuous propositions of the form SORT_CONSTRAIN('a::c).  For example:

  lemma assumes "SORT_CONSTRAINT('a::empty)" shows False ...

The result contains an implicit sort hypotheses as before --
SORT_CONSTRAINT premises are eliminated as part of the canonical
rule normalization.



From makarius at sketis.net  Tue Oct 21 20:09:53 2008
From: makarius at sketis.net (Makarius)
Date: Tue, 21 Oct 2008 20:09:53 +0200 (CEST)
Subject: [isabelle-dev] Multicore performance preview
Message-ID: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>

Here are some numbers of the next stage of parallelism in Isabelle, where 
both the theory graph structure and the inherent irrelevance of proofs is 
taken into account.  The hardware is a Mac Pro with 4 cores (i.e. 2 plain 
old dual-core Xeons); times are for isabelle usedir -M 4 vs. -M 1 in 
alternating lines:

Finished HOL (0:03:30 elapsed time, 0:06:17 cpu time, factor 1.79)
Finished HOL (0:05:05 elapsed time, 0:05:04 cpu time, factor 0.99)
Finished HOL-Algebra (0:01:36 elapsed time, 0:03:09 cpu time, factor 1.96)
Finished HOL-Algebra (0:02:46 elapsed time, 0:02:44 cpu time, factor 0.98)
Finished HOL-Auth (0:02:11 elapsed time, 0:06:44 cpu time, factor 3.08)
Finished HOL-Auth (0:06:08 elapsed time, 0:06:08 cpu time, factor 1.00)
Finished HOL-Bali (0:02:31 elapsed time, 0:04:12 cpu time, factor 1.66)
Finished HOL-Bali (0:03:39 elapsed time, 0:03:46 cpu time, factor 1.03)
Finished HOL-HoareParallel (0:01:35 elapsed time, 0:04:15 cpu time, factor 2.68)
Finished HOL-HoareParallel (0:03:56 elapsed time, 0:03:57 cpu time, factor 1.00)
Finished HOL-Library (0:01:10 elapsed time, 0:02:55 cpu time, factor 2.50)
Finished HOL-Library (0:02:25 elapsed time, 0:02:29 cpu time, factor 1.02)
Finished HOL-Main (0:01:52 elapsed time, 0:03:10 cpu time, factor 1.69)
Finished HOL-Main (0:02:34 elapsed time, 0:02:34 cpu time, factor 1.00)
Finished HOL-MetisExamples (0:00:17 elapsed time, 0:00:42 cpu time, factor 2.47)
Finished HOL-MetisExamples (0:00:36 elapsed time, 0:00:35 cpu time, factor 0.97)
Finished HOL-MicroJava (0:02:09 elapsed time, 0:05:18 cpu time, factor 2.46)
Finished HOL-MicroJava (0:04:52 elapsed time, 0:04:54 cpu time, factor 1.00)
Finished HOL-Nominal (0:00:21 elapsed time, 0:00:26 cpu time, factor 1.23)
Finished HOL-Nominal (0:00:24 elapsed time, 0:00:22 cpu time, factor 0.91)
Finished HOL-Nominal-Examples (0:05:25 elapsed time, 0:13:42 cpu time, factor 2.52)
Finished HOL-Nominal-Examples (0:11:39 elapsed time, 0:12:31 cpu time, factor 1.07)
Finished HOL-Plain (0:00:53 elapsed time, 0:01:24 cpu time, factor 1.58)
Finished HOL-Plain (0:01:09 elapsed time, 0:01:07 cpu time, factor 0.97)
Finished HOL-SET-Protocol (0:00:51 elapsed time, 0:02:07 cpu time, factor 2.49)
Finished HOL-SET-Protocol (0:01:58 elapsed time, 0:01:58 cpu time, factor 1.00)
Finished HOL-UNITY (0:01:17 elapsed time, 0:02:29 cpu time, factor 1.93)
Finished HOL-UNITY (0:02:11 elapsed time, 0:02:09 cpu time, factor 0.98)
...
0:37:28 elapsed time, 1:17:00 cpu time, factor 2.05
1:06:14 elapsed time, 1:07:10 cpu time, factor 1.01

In order to try it yourself you need to enable the future_scheduler option 
in src/Pure/Concurrent/ROOT.ML; those with 8 core Macs should get slightly 
better numbers.  Does anybody have 12 or 16 cores around?

You will need the latest Poly/ML 5.2.1 version to prevent a strange GC 
deadlock problem in 5.1/5.2.

Apart from that the main reason why the new scheduler is still inactive by 
default are a couple of legacy features in Isabelle/HOL packages. The 
struggle to get rid of legacy stuff will continue ...


	Makarius


From berghofe at in.tum.de  Tue Oct 21 22:31:57 2008
From: berghofe at in.tum.de (Stefan Berghofer)
Date: Tue, 21 Oct 2008 22:31:57 +0200
Subject: [isabelle-dev] Multicore performance preview
In-Reply-To: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>
References: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>
Message-ID: <48FE3C3D.7000604@in.tum.de>

Makarius wrote:
> You will need the latest Poly/ML 5.2.1 version to prevent a strange GC 
> deadlock problem in 5.1/5.2.

Where can I get the latest version? The latest version offered for download
on the Sourceforge page

  http://sourceforge.net/project/showfiles.php?group_id=148318&package_id=163589

is still 5.2....

Greetings,
Stefan

-- 
Dr. Stefan Berghofer               E-Mail: berghofe at in.tum.de
Institut fuer Informatik           Phone: +49 89 289 17328
Technische Universitaet Muenchen   Fax:   +49 89 289 17307
Boltzmannstr. 3                    Room: 01.11.059
85748 Garching, GERMANY            http://www.in.tum.de/~berghofe


From makarius at sketis.net  Tue Oct 21 22:36:36 2008
From: makarius at sketis.net (Makarius)
Date: Tue, 21 Oct 2008 22:36:36 +0200 (CEST)
Subject: [isabelle-dev] Multicore performance preview
In-Reply-To: <48FE3C3D.7000604@in.tum.de>
References: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>
	<48FE3C3D.7000604@in.tum.de>
Message-ID: <Pine.LNX.4.64.0810212234230.31553@macbroy20.informatik.tu-muenchen.de>

On Tue, 21 Oct 2008, Stefan Berghofer wrote:

> Makarius wrote:
> > You will need the latest Poly/ML 5.2.1 version to prevent a strange GC 
> > deadlock problem in 5.1/5.2.
> 
> Where can I get the latest version? The latest version offered for download
> on the Sourceforge page
> 
>   http://sourceforge.net/project/showfiles.php?group_id=148318&package_id=163589
> 
> is still 5.2....

You are right, 5.2.1 has not been published yet.  The present CVS version 
is more or less at the same state, see e.g. our /home/polyml/polyml-cvs/.


	Makarius


From makarius at sketis.net  Wed Oct 22 22:55:28 2008
From: makarius at sketis.net (Makarius)
Date: Wed, 22 Oct 2008 22:55:28 +0200 (CEST)
Subject: [isabelle-dev] [polyml] Release 5.2.1 (fwd)
Message-ID: <Pine.LNX.4.64.0810222252290.23310@macbroy20.informatik.tu-muenchen.de>

Our usual packages for use with Isabelle are available here: 
http://isabelle.in.tum.de/polyml-5.2.1/

For any serious use of multithreading in recent development snapshots 
Poly/ML 5.2.1 is really required, but there is no immediate need to 
recompile the official Isabelle2008.


	Makarius

---------- Forwarded message ----------
Date: Wed, 22 Oct 2008 20:10:34 +0100
From: David Matthews <David.Matthews at prolingua.co.uk>
To: PolyML mailing list <polyml at inf.ed.ac.uk>
Subject: [polyml] Release 5.2.1

I've now released version 5.2.1 of Poly/ML on the SourceForge site. This is
largely a bug-fix release of 5.2 and incorporates various fixes to the run-time
system and basis library.  I'll update the release notes on the web site with
details of the bug fixes.  The functional IO library has been largely rewritten
to be much more efficient.

One change that may affect a few people is that X-Windows/Motif support is now
turned off by default in the configure script.  To include support for
X-Windows/Motif specify --with-x when running "configure"

Note: Since the compiler has not changed when you run Poly/ML 5.2.1 the start-up
line will still say "Poly/ML 5.2 Release".  However poly -v will say something
like
Poly/ML 5.2 Release    RTS version: I386-5.2.1

David

_______________________________________________
polyml mailing list
polyml at inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml


From David.Matthews at prolingua.co.uk  Wed Oct 22 21:16:08 2008
From: David.Matthews at prolingua.co.uk (David Matthews)
Date: Wed, 22 Oct 2008 20:16:08 +0100
Subject: [isabelle-dev] Multicore performance preview
In-Reply-To: <Pine.LNX.4.64.0810212234230.31553@macbroy20.informatik.tu-muenchen.de>
References: <Pine.LNX.4.64.0810211953360.27569@macbroy20.informatik.tu-muenchen.de>	<48FE3C3D.7000604@in.tum.de>
	<Pine.LNX.4.64.0810212234230.31553@macbroy20.informatik.tu-muenchen.de>
Message-ID: <48FF7BF8.6040006@prolingua.co.uk>

Makarius wrote:
> On Tue, 21 Oct 2008, Stefan Berghofer wrote:
> 
>> Makarius wrote:
>>> You will need the latest Poly/ML 5.2.1 version to prevent a strange GC 
>>> deadlock problem in 5.1/5.2.
>> Where can I get the latest version? The latest version offered for download
>> on the Sourceforge page
>>
>>   http://sourceforge.net/project/showfiles.php?group_id=148318&package_id=163589
>>
>> is still 5.2....
> 
> You are right, 5.2.1 has not been published yet.  The present CVS version 
> is more or less at the same state, see e.g. our /home/polyml/polyml-cvs/.

Makarius was being slightly premature by announcing it yesterday. 
Poly/ML 5.2.1 has now been released and you should find it on 
SourceForge.  It's nice to see the speed-ups, though.

David


From makarius at sketis.net  Thu Oct 23 15:32:07 2008
From: makarius at sketis.net (Makarius)
Date: Thu, 23 Oct 2008 15:32:07 +0200 (CEST)
Subject: [isabelle-dev] NEWS (update)
Message-ID: <Pine.LNX.4.64.0810231531410.30759@macbroy20.informatik.tu-muenchen.de>

* Multithreading for Poly/ML 5.1/5.2 is no longer supported, only for
Poly/ML 5.2.1 or later.



From nipkow at in.tum.de  Fri Oct 24 08:38:52 2008
From: nipkow at in.tum.de (Tobias Nipkow)
Date: Fri, 24 Oct 2008 08:38:52 +0200
Subject: [isabelle-dev] [Fwd: Fwd: E Equational Theorem Prover 1.0 "Temi"
	released]
Message-ID: <49016D7C.7090207@in.tum.de>

In case anybody feels like trying the latest Version of E (via
sledgehammer).

Tobias

-------- Original Message --------

> From: Stephan Schulz <schulz at informatik.tu-muenchen.de>
> Date: 23 October 2008 00:41:54 BST
> To: undisclosed-recipients: ;
> Subject: E Equational Theorem Prover 1.0 "Temi" released
>
>
> E 1.0 "Temi" is the latest version of the successful automated theorem
> prover.
>
> E is a theorem prover for full first order logic with equality. It has
> successfully competed in several CASC competitions and is generally
> considered a friendly and powerful system (as theorem provers go).
>
> The new version improves clausification, has a more GNU-like
> installation system, and has been updated to comply with the latest
> TPTP-3 syntax.
>
> E is available as a source distribution for UNIX-variants. It installs
> cleanly under all UNIX variants I could get my hands on: Various
> versions of GNU/Linux for Intel and SPARC, Solaris, HPUX and
> MacOS-X. Users have reported successful builds on a large number of
> other systems, including Windows/Cygwin.
>
> The system is distributed under the GNU General Public License.
>
> You can find the source distribution and additional information at
> http://www.eprover.org
>
>
> Have fun!
>
>
> Stephan
>
> -- 
> -------------------------- It can be done!  
> ---------------------------------
>      Please email me as schulz at eprover.org (Stephan Schulz)
> ----------------------------------------------------------------------------


From ac638 at cam.ac.uk  Mon Oct 27 16:50:35 2008
From: ac638 at cam.ac.uk (Amine Chaieb)
Date: Mon, 27 Oct 2008 15:50:35 +0000
Subject: [isabelle-dev] instantiation
Message-ID: <4905E34B.3050701@cam.ac.uk>

Dear all,

(How) Can I perform an instantiation of a type-constructor with two 
arguments, an thereby restricting them to be the same?

Concrete problem:

instantiation "fun" (type, type) power
begin
....

end


but I want only to raise functions of type 'a => 'a to powers.

Thank you for any hint!

best wishes,
Amine.


From florian.haftmann at informatik.tu-muenchen.de  Mon Oct 27 16:53:17 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Mon, 27 Oct 2008 16:53:17 +0100
Subject: [isabelle-dev] instantiation
In-Reply-To: <4905E34B.3050701@cam.ac.uk>
References: <4905E34B.3050701@cam.ac.uk>
Message-ID: <4905E3ED.4010800@informatik.tu-muenchen.de>

Amine Chaieb schrieb:
> Dear all,
> 
> (How) Can I perform an instantiation of a type-constructor with two
> arguments, an thereby restricting them to be the same?

This is beyond the type class system of Isabelle.  A pity.

	Florian

-- 

http://isabelle.in.tum.de/~haftmann
PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailman46.in.tum.de/pipermail/isabelle-dev/attachments/20081027/20ef8c26/attachment.sig>

From ac638 at cam.ac.uk  Mon Oct 27 17:03:07 2008
From: ac638 at cam.ac.uk (Amine Chaieb)
Date: Mon, 27 Oct 2008 16:03:07 +0000
Subject: [isabelle-dev] instantiation
In-Reply-To: <4905E3ED.4010800@informatik.tu-muenchen.de>
References: <4905E34B.3050701@cam.ac.uk>
	<4905E3ED.4010800@informatik.tu-muenchen.de>
Message-ID: <4905E63B.1000006@cam.ac.uk>

:( I also failed a few weeks ago to instantiate the fold combinator to 
iterate function composition ...

But is this restriction fundamental or does it happen to be there?

Amine.

Florian Haftmann wrote:
> Amine Chaieb schrieb:
>> Dear all,
>>
>> (How) Can I perform an instantiation of a type-constructor with two
>> arguments, an thereby restricting them to be the same?
> 
> This is beyond the type class system of Isabelle.  A pity.
> 
> 	Florian
> 


From florian.haftmann at informatik.tu-muenchen.de  Tue Oct 28 08:12:53 2008
From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann)
Date: Tue, 28 Oct 2008 08:12:53 +0100
Subject: [isabelle-dev] instantiation
In-Reply-To: <4905E63B.1000006@cam.ac.uk>
References: <4905E34B.3050701@cam.ac.uk>	<4905E3ED.4010800@informatik.tu-muenchen.de>
	<4905E63B.1000006@cam.ac.uk>
Message-ID: <4906BB75.7090408@informatik.tu-muenchen.de>

> :( I also failed a few weeks ago to instantiate the fold combinator to
> iterate function composition ...

Hmmm... perhaps "fold (op o) id id" is what you want in that case.

> But is this restriction fundamental or does it happen to be there?

Well, the type classes in Isabelle are an instance of order-sorted
algebra which demands type arguments to be free.  Perhaps it is possible
to relax this without smashing the meta theory (I don't know the
answer).  Anyway, this would mean a lot of work...

	Florian

-- 

http://isabelle.in.tum.de/~haftmann
PGP available:
http://home.informatik.tu-muenchen.de/haftmann/pgp/florian_haftmann_at_informatik_tu_muenchen_de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://mailman46.in.tum.de/pipermail/isabelle-dev/attachments/20081028/7432aca0/attachment.sig>

From lp15 at cam.ac.uk  Tue Oct 28 11:06:41 2008
From: lp15 at cam.ac.uk (Lawrence Paulson)
Date: Tue, 28 Oct 2008 10:06:41 +0000
Subject: [isabelle-dev] NEWS
Message-ID: <EC67EEB8-2B45-41D1-AAB5-2BFE6E3F391C@cam.ac.uk>

* The metis method no longer fails because the theorem is too trivial
(contains the empty clause).

Larry



From webertj at in.tum.de  Wed Oct 29 06:46:44 2008
From: webertj at in.tum.de (Tjark Weber)
Date: Wed, 29 Oct 2008 13:46:44 +0800
Subject: [isabelle-dev] instantiation
In-Reply-To: <4905E3ED.4010800@informatik.tu-muenchen.de>
References: <4905E34B.3050701@cam.ac.uk>
	<4905E3ED.4010800@informatik.tu-muenchen.de>
Message-ID: <1225259204.3025.6.camel@weber>

On Mon, 2008-10-27 at 16:53 +0100, Florian Haftmann wrote:
> Amine Chaieb schrieb:
> > (How) Can I perform an instantiation of a type-constructor with two
> > arguments, an thereby restricting them to be the same?
> 
> This is beyond the type class system of Isabelle.  A pity.

While this may not give you what you wanted, you can of course state
(and trivially prove)

  lemma "OFCLASS('a => 'a, power_class)"
  by intro_classes

Best,
Tjark



From ballarin at in.tum.de  Thu Oct 30 11:02:11 2008
From: ballarin at in.tum.de (Clemens Ballarin)
Date: Thu, 30 Oct 2008 11:02:11 +0100
Subject: [isabelle-dev] NEWS
Message-ID: <733181BA-E4D4-4E23-9C25-C3892F07A619@in.tum.de>

* Dropped locale element "includes".  This is a major INCOMPATIBILITY.

In existing theorem specifications replace the includes element by the
respective context elements of the included locale, omitting those that
are already present in the theorem specification.  Multiple assume
elements of a locale should be replaced by a single one involving the
locale predicate.  In the proof body, declarations (most notably
theorems) may be regained by interpreting the respective locales in the
proof context as required (command "interpret").

If using "includes" in replacement of a target solely because the
parameter types in the theorem are not as general as in the target,
consider declaring a new locale with additional type constraints on the
parameters (context element "constrains").

Clemens