Re: [isabelle] Comparing Isabelle/Scala with scala-isabelle. Was: Isabelle code for getting in-memory representation (abstract syntax trees) for complete theory file (tree of loaded theories)

[Makarius <makarius at sketis.net>]

On 11/02/2021 12:53, Dominique Unruh wrote:
> 
>> Exactly. Over 10 years I have given many talks and written many papers about
>> Isabelle/Scala in contrast to Isabelle/ML. The main idea:
>>
>>   * Isabelle/Scala is for systems-programming / system integration
>>
>>   * Isabelle/ML is for mathematical logic
>>
>> Sometimes there is a bit of overlap, and some freedom to decide where things
>> happen. But when you start to do term operations in Isabelle/Scala it is
>> probably wrong.
> 
> Good. Then I got things right. So we have a clear separation of purposes
> between Isabelle/Scala and scala-isabelle.
> 
>   *
> 
>     Isabelle/Scala is for systems-programming / system integration
> 
>   *
> 
>     Isabelle/ML is for mathematical logic
> 
>   * scala-isabelle is also for mathematical logic (and for any other more
>     low-level inspection of Isabelle data)
> 
> Anythings that can be done in scala-isabelle can also be done in Isabelle/ML,
> of course. (And vice versa.) However, if due to the constraints of the
> project, we want to use Scala (or any other JVM language), then scala-isabelle
> would be the right choice.

The choice is up to you. Within the regular Isabelle ecosystem, the proper
language for heavy-duty symbolic logic is Isabelle/ML: it has been made
precisely for that over 35 years. We could not crunch the great things in AFP
without Isabelle/ML as it is today.


To conclude this overview of possibilities, here is a further NEWS entry from
Isabelle2021:

*** ML ***

* Antiquotations @{scala_function}, @{scala}, @{scala_thread} refer to
registered Isabelle/Scala functions (of type String => String):
invocation works via the PIDE protocol.

This means that Isabelle/ML programs can appeal to operations in Scala, if
that happens to be available on that side, e.g. for historical reaans or
existing Java implementations. Thus the order of control is straight-forward:
ML hands over to Scala like a regular function call, without any special
programming tricks exposed outside.


An example application is Nitpick/Kodkod, which works either as a heavy JVM
process or light Scala thread (both invoked from Isabelle/ML):

https://isabelle.sketis.net/repos/isabelle-release/file/Isabelle2021-RC5/src/HOL/Tools/Nitpick/kodkod.ML#l1003

https://isabelle.sketis.net/repos/isabelle-release/file/Isabelle2021-RC5/src/HOL/Tools/Nitpick/kodkod.scala

Side-remark: Originally I wanted to get rid of the JVM process for
Isabelle2021, but this has to wait for the next release, due to remaining
assumptions in the Kodkod implementation concerning the Java context
(interrupts, threads, exit).

> Scala is easier to debug and edit with
> modern IDEs. Isabelle/ML has some support
> (e.g., ctrl-click is useful), but imho it
> does not come close to the tool support
> that we have in modern IDEs.

The term "modern" sounds very old-fashioned to me. Modern times have ended
some decades ago; we now have the post-modern era.


For Isabelle projects, the Isabelle Prover IDE has very good integration of
everything: Isar, ML, other sub-languages. I know this best and like this
best. It is also quite easy to integrate your own sub-languages with PIDE
support (implemented all in Isabelle/ML).

Isabelle/Scala is an exception: it is not (yet?) integrated into
Isabelle/PIDE, but the "isabelle scala_project" tool allows to generate a
Gradle project for use in IntelliJ IDEA: I do like that IDE, but that alone
would never be a reason to disregard our fine Isabelle/ML working environment.

VSCode is another popular quasi-IDE option: Isabelle/VSCode is a minimal
experiment, much more could be done. Generally, I see a lot of IDE concepts
retrofitted into the VSCode editor project, but it might require 5-10 more
years to become a proper IDE.


	Makarius