Release 8.0 of ParaSail Interpreter, Compiler, and Debugger

[Tuck]

Finally, at long last a new release of ParaSail.  This new release incorporates an interactive debugger that is automatically invoked when the interpreter encounters an assertion, precondition, or postcondition that fails at run-time.  This is also the first release where pre- and postconditions are fully analyzed, and checked at run-time.  Finally, this has one modest enhancement to the ParaSail syntax -- "interpolation" of the value of an expression directly into a string literal.  For example:

   Println("The value of X + Y is `(X + Y).");

The back-quote character followed by a parenthesized expression may now appear within a string literal, and the value of the expression is "interpolated" into the middle of the string, in place of the back-quoted expression.  Hence, presume X is 31 and Y is 11, the above will print:

   The value of X + Y is 42.

In any case, here is the new release:

     http://bit.ly/psl8rel

It is a "zip" archive of sources and binaries for Mac, Linux, and Windows.  Mac and Linux include executable binaries for a bootstrapped LLVM-generating ParaSail compiler.  Windows only contains the executable binaries for the ParaSail interpreter.

The web page for ParaSail has also been updated:

   http://parasail-lang.org

From a documentation point of view, the most exciting news is that we have just published a full description of the ParaSail language in the new academic "Programming Journal":

   http://programming-journal.org/2019/3/7/

Please take a look at this article to see a comprehensive description of ParaSail, and how it fits into the world of programming language design.

Here is the latest reference manual (which is also linked from the ParaSail web page, and included in the "zip" archive for release 8.0):

   https://adacore.github.io/ParaSail/images/parasail_ref_manual.pdf

Enjoy!

[Joakim Strandberg]

Thanks for the release Tuck. I suggest removing "-gnat95" from the gpr-files in order to be able to build the code with the latest GNAT Community Edition (2018).

joakim@joakim-N8xEJEK:~/Downloads/parasail_release_8_0$ make all_no_gtk
cd interpreter; ./config.sh
Config: PO locks enabled
make -C parser/build
make[1]: Går till katalogen ”/home/joakim/Downloads/parasail_release_8_0/parser/build”
cd ayacc; gnatmake -I../../../aflex_ayacc/ayacc ../../../aflex_ayacc/ayacc/ayacc.adb -o ../bin/ayacc
gcc -c -I../../../aflex_ayacc/ayacc/ -I../../../aflex_ayacc/ayacc -I- ../../../aflex_ayacc/ayacc/ayacc.adb
...

gprbuild -p -c -P build/compiled_main -largs -lm
Setup
   [mkdir]        object directory for project Compiled_Main
Compile
   [Ada]          call_compiled_main.adb
gnat1: invalid switch: -gnat95

   compilation of call_compiled_main.adb failed

gprbuild: *** compilation phase failed
Makefile:145: recipe for target 'check_compiled_main' failed
make: *** [check_compiled_main] Error 4

Best regards,

Joakim

[dpt]

Thank you for the new release!

[dpt]

Hi Joakim

does GNAT 2018 still support Ada95 code?

Regards

[Joakim Strandberg]

Hi Dpt,

does GNAT 2018 still support Ada95 code?

 

Yes, of course it is possible to compile Ada95 code except that in the latest release of GNAT Community Edition it is no longer possible to specify that one wishes to develop Ada code in a specific version of the Ada language for example Ada83, Ada95, Ada2005 or Ada2012. The idea is that it is always one version of the Ada language that the GNAT compiler supports and it is the latest official ISO version of the language. That is currently the Ada 2012 version with corrections (from year 2015). And next year the latest version of the Ada language will be the Ada2020 standard. Therefore the GNAT compiler no longer supports the compiler flags -gnat83, -gnat95, -gnat2005 nor -gnat2012. Since the "-gnat95" compiler flag is still part of the gpr-files and Makefile in the parasail sources they do not build out of the box with GNAT Community Edition 2018.

Not going into details but there are some small differences between Ada95 and later editions of the language but I believe Tuck has stayed within those parts of Ada that hasn't changed since 1995. Therefore it should be no issue with removing that -gnat95 flag from the parasail sources and still be able to build the sources with an older compiler. The parasail sources are built using the Ada95 standard and Tuck uses another compiler except for GNAT to make sure it's the Ada95 standard that is used and therefore the -gnat95 compiler flags are not essential., We'll see which way forward Tuck decides is best to handle the situation.

Best regards,

Joakim

[Tuck]

Thanks for clarifying the situation.  Yes, the -gnat95 flag can just be deleted.  We use it to ensure we remain within the Ada 95 subset when maintaining the ParaSail interpreter, as that subset is the most widely supported version of Ada.  We also compile regularly with an Ada95-only compiler to ensure portability.  It sounds like we should also compile with the -gnat2012 flag to be sure we are compilable by all later versions as well.  About the only incompatibilities of note between Ada 2012 and Ada 95 are the presence of a handful of new reserved words, and a changed model for returning objects of a limited type from a function.  The ParaSail interpreter should not bump into any of those incompatibilities.  Please let us know if you find a problem!

Take care,

-Tuck

[Anton Lobach]

Hi Tuck,

Thank you very much for the new release!

I was wondering if Sparkel also have an LLVM-based compiler and if the development of Sparkel is still active?

Best,

Anton

--
You received this message because you are subscribed to the Google Groups "ParaSail Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parasail-programming...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Yours sincerely,

Anton Lobach

[Tucker Taft]

We have not been actively working on Sparkel recently.  In my "day" job at AdaCore I have been working on SPARK 2014 itself, where we are in the process of adding support for ownership-based pointers, analogous to the Sparkel/ParaSail model where objects "own" their subobjects, and also analogous to the pointer model in the Rust language.  It would be possible to connect the LLVM-based compiler up to the Sparkel front end, if there were sufficient interest.  The Sparkel front end is essentially the ParaSail front end with a different parser.  It generates the same "PSVM" internally, and that is what the LLVM-based compiler starts from.

Take care,

-Tuck

[Anton Lobach]

Ok, got it.

I was also wondering if there are any plans to implement a REPL with a full support of the ParaSail language similar to Scala's and python's ones? It would also be nice if the ParaSail's compiler could use GPUs (when possible) for parallelization.

Just some minor thing about the syntax. Why should the "main" function be written lower case as apposed to "Main" for consistency with the conventional ParaSail's source representation style? At first, I thought that the "main" is a reserved word, but it seems that it is not the case as it is not in the list of the reserved words.

Anton Lobach

[Tucker Taft]

On Sun, Feb 10, 2019 at 12:24 PM Anton Lobach <entru...@gmail.com> wrote:

Ok, got it.

I was also wondering if there are any plans to implement a REPL with a full support of the ParaSail language similar to Scala's and python's ones?

There is a simple-minded REPL right now.  A more complete one would be nice.  We have also included a prototype interactive debugger in release 8.0.  It would make sense to integrate a more complete REPL with the debugger, and we will be looking into that.

It would also be nice if the ParaSail's compiler could use GPUs (when possible) for parallelization.

The ParaSail compiler generates LLVM instructions, and I believe there is some LLVM support for GPUs.   I'll have to investigate a bit further. 

Just some minor thing about the syntax. Why should the "main" function be written lower case as apposed to "Main" for consistency with the conventional ParaSail's source representation style? At first, I thought that the "main" is a reserved word, but it seems that it is not the case as it is not in the list of the reserved words.

There is nothing particularly special about "main," except that the compiler looks for something called main.  It could easily be altered to also allow Main.   If you search for the quoted string "main" within lib/compiler.psl, you will find the two places where it special-cases "main."  You could change those two places from X == "main" to X in ["main" | "Main"] and you would probably have just what you want (after bootstrapping the compiler ;-).

Anton Lobach

Take care,

-Tuck

[Anton Lobach]

There is a simple-minded REPL right now.  A more complete one would be nice. We have also included a prototype interactive debugger in release 8.0.  It would make sense to integrate a more complete REPL with the debugger, and we will be looking into that.

Having a REPL would be also nice for scripting purposes in data science domain and numerical computing.

The ParaSail compiler generates LLVM instructions, and I believe there is some LLVM support for GPUs. I'll have to investigate a bit further.

Yep, it does.

There is nothing particularly special about "main," except that the compiler looks for something called main.  It could easily be altered to also allow Main.   If you search for the quoted string "main" within lib/compiler.psl, you will find the two places where it special-cases "main."  You could change those two places from X == "main" to X in ["main" | "Main"] and you would probably have just what you want (after bootstrapping the compiler ;-).

Ok. :)

If I am not mistaken, the current compiler checks pre and post conditions at run time but, if my understanding is correct, the ultimate goal is to check them at compile time, is this right?

Best,

Anton

[Tucker Taft]

On Sun, Feb 10, 2019 at 3:52 PM Anton Lobach <entru...@gmail.com> wrote:

There is a simple-minded REPL right now.  A more complete one would be nice. We have also included a prototype interactive debugger in release 8.0.  It would make sense to integrate a more complete REPL with the debugger, and we will be looking into that.

Having a REPL would be also nice for scripting purposes in data science domain and numerical computing.

Agreed.

The ParaSail compiler generates LLVM instructions, and I believe there is some LLVM support for GPUs. I'll have to investigate a bit further.

Yep, it does.

Thanks for the link.

If I am not mistaken, the current compiler checks pre and post conditions at run time but, if my understanding is correct, the ultimate goal is to check them at compile time, is this right?

There is a separate tool, "ParaScope" which checks all assertions and null-ness checks statically.  We did not make a new release of ParaScope this time, though the older release is included, and should work for simple programs (available as bin/scope.csh).

The way pre- and postconditions are handled is that the front end inserts them into the PSVM representation (where they look the same as assertions -- using the PSVM Check_Nested_Block_Op), and from there they are available to the interpreter, ParaScope, and the LLVM-generating compiler.   By default these "assertions" are omitted in the generated LLVM when you specify an optimization level above "-O0" to the compiler, though you can request they be generated even when optimizing, by giving the "-a" switch.  In the interpreter, a failing assertion causes the interactive debugging console to be invoked (presuming you loaded the interpreter, which happens automatically if you use the new "bin/interp.csh" script).  One limitation, at the moment, is that preconditions are implemented by generating implicit assertions inside the code for the "body" of the operation.  For static analysis, they are better if they appear at each point of call.  Our next release will focus more attention on statically verifying pre- and postconditions.

Best,

Anton

Take care,

-Tuck

[Anton Lobach]

Hi Tuck,

Thanks for the link.   

You are very welcome!

There is a separate tool, "ParaScope" which checks all assertions and null-ness checks statically.  We did not make a new release of ParaScope this time, though the older release is included, and should work for simple programs (available as bin/scope.csh).
The way pre- and postconditions are handled is that the front end inserts them into the PSVM representation (where they look the same as assertions -- using the PSVM Check_Nested_Block_Op), and from there they are available to the interpreter, ParaScope, and the LLVM-generating compiler.   By default these "assertions" are omitted in the generated LLVM when you specify an optimization level above "-O0" to the compiler, though you can request they be generated even when optimizing, by giving the "-a" switch.  In the interpreter, a failing assertion causes the interactive debugging console to be invoked (presuming you loaded the interpreter, which happens automatically if you use the new "bin/interp.csh" script).  One limitation, at the moment, is that preconditions are implemented by generating implicit assertions inside the code for the "body" of the operation.  For static analysis, they are better if they appear at each point of call.  Our next release will focus more attention on statically verifying pre- and postconditions.

Ok, got it. I guess ParaScope will become a part of the compiler eventually?

I also have some questions regarding the design.

1) If I understand correctly, in ParaSail there is no equivalent of Ada's "with" statements, so what is the reason for such decision?

2) I've also noticed that type annotations of variables can be optional in some cases like, for example, in kmeans_fast "benchmark" file "var R := Random::Start(11)" or "const Clusters := KMeans::Run(...)". Can this hurt readability? Would such feature be dangerous in safety-critical applications? 

P. S. 

As an Ada fan, I hope Sparkel will stay alive ;)

Best,

Anton

--

You received this message because you are subscribed to the Google Groups "ParaSail Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parasail-programming...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tucker Taft]

On Sat, Feb 16, 2019 at 5:29 PM Anton Lobach <entru...@gmail.com> wrote:

...

Ok, got it. I guess ParaScope will become a part of the compiler eventually?

Yes, it will be an option to run it when the compiler is run.

I also have some questions regarding the design.

1) If I understand correctly, in ParaSail there is no equivalent of Ada's "with" statements, so what is the reason for such decision?

There is an "import" clause that acts very much like the Ada "with" statement.  There are some "implicit" imports for PSL::Core::* and PSL::Containers::*, essentially the modules in lib/aaa.psi, so you get things like Vector and Array and Integer without having to explicitly import them.  This is somewhat similar to Ada package Standard, I suppose.

2) I've also noticed that type annotations of variables can be optional in some cases like, for example, in kmeans_fast "benchmark" file "var R := Random::Start(11)" or "const Clusters := KMeans::Run(...)". Can this hurt readability? Would such feature be dangerous in safety-critical applications? 

This is a simple notion of type inference, where the type of the new object is based on the type of its initial value.   But that requires the type of the initial value to be unambiguous, so I wouldn't consider it dangerous.  There is no implicit conversion happening here.  Implicit conversion I believe could be somewhat more dangerous if the implicit conversion were losing precision, for example, but that isn't happening with type inference.  The new object has exactly the same type as the initializing expression.

P. S. 

As an Ada fan, I hope Sparkel will stay alive ;)

I always make sure that Sparkel compiles and builds.  I am also working actively on the "real" SPARK to add some ParaSail-like features there, including a number of fine-grained parallelism and some of the "ownership"-based storage management used in ParaSail.

[Vernon Brown]

I've been using Parasail on Windows, and was very happy to get a new release, in the hopes that some of the issues I've been having are resolved.

The good news is that v8.0 of parasail_main doesn't have the memory limitations I was getting with release 7.0.

But, when I tried v8.0 of the Windows binaries for sparkel_main, parython_main, and javallel_main they all have the same issue as they did in release 7.0.

So, rather than stay silent and hope for a fix, I realized I should report this issue, since there probably aren't very many Windows users of Parasail.  (I'm guessing the Unix binaries don't have this issue)

Below are the errors I get for each:

>..\bin\sparkel_main aaa.ski drinking_phils.skl

G:\parasail_release_8_0\sparkel_examples\aaa.ski:6495:27: Error: Hiding of Val at line 6492 not permitted:

G:\parasail_release_8_0\sparkel_examples\aaa.ski:6495:27: Info:   [Lit => Val] of Literals

 

>..\bin\parython_main aaa.pri drinking_phils.pry

aaa.pri:6449:27: Error: Hiding of Val at line 6446 not permitted:

aaa.pri:6449:27: Info:   [Lit => Val] of Literals

aaa.pri:5830:5: Error: Hiding of par_5830_5 at line 5830 not permitted:

aaa.pri:5830:5: Info:   Println("About to delay 4.0 seconds"); ...

>..\bin\javallel_main aaa.jli hippo_game.jll

aaa.jli:5540:5: Error: Hiding of par_5540_5 at line 5540 not permitted:

aaa.jli:5540:5: Info:   println("About to delay 4.0 seconds"); ...

[Tucker Taft]

Glad to hear 8.0 is working better for you.  Thanks for the report of problems with the other executables.  They clearly haven't been tested in a while!  We will try to make the necessary fixes before the next release.

Take care,

-Tuck

[Vernon Brown]

Hi Tuck,

I've been trying to get the ParaSail compiler to build on Windows.

I've managed to get everything to work up until the final link step, then I get:

Link

   [link]         compiled_main_with_interp.adb

c:/gnat/2018/bin/../libexec/gcc/x86_64-pc-mingw32/7.3.1/ld.exe: i386 architecture of input file `G:/parasail_release_8_0/lib/aaa.psi.o' is incompatible with i386:x86-64 output

I've tried both changing the -mcpu=<target> option to llc and the -b<target> option to ld and I can't find any combination that works.  There's an overwhelming number of choices for <target> on both the llc and ld side, so maybe I just haven't tried the right combo yet.  Or, it could be something else I haven't thought of yet.

Can you give me a clue what needs to be changed?

[Tucker Taft]

I am guessing the aaa.psi.o you have might be for the wrong target.  I suggest you recreate that as well using "pslc.csh -i -b3 ..." which will recompile everything using the interpreter.

-Tuck

--

[Vernon Brown]

I am running pslc.csh -i -b3.  That's what I'm trying to get to work.  It recompiles all the sources with the interpreter, then runs llc on the *.psl.ll files and clang on the *.psl.s files that llc created to generate the .o's.  And yes, I also think the .o files may be for the wrong target.  I'm just not sure what options to use to fix that.

The default target for the llc that I built (since the llvm distribution doesn't supply a prebuilt binary for llc) is:

>llc -version

LLVM (http://llvm.org/):

  LLVM version 3.9.

  DEBUG build with assertions.

  Default target: i686-pc-windows-msvc

  Host CPU: skylake

One of the "Registered targets" listed by this command is: 

x86-64     - 64-bit X86: EM64T and AMD64

which seems to match the target that the error message from ld is wanting: "i386:x86-64".

So, I tried adding -mcpu=x86-64 to the llc command line, but that didn't seem to change anything, so then I tried -march=x86-64, which then does cause llc to generate 64 bit code, but then clang complains: "error: instruction requires: 64-bit mode".

So, I added -march=x86-64 to the clang command line as well, but clang still gives me the same errors.

clang (which comes from llvm as a prebuilt binary for Windows) also says it's target is: i686-pc-windows-msvc.

I don't see any other way to change the target for clang except to rebuild it for the x86-64 target.

Is this what you would suggest?  Or is there another way?

 

[Tucker Taft]

We have not encountered this problem before.  We will try to reproduce the problem here, to see if we can come up with a solution.

Take care,

-Tuck

--

[Tucker Taft]

Unfortunately we are do not have today ready access to a Windows machine with the appropriate version of LLVM installed, which is one reason we don't provide a pre-built ParaSail compiler on Windows, so here are some ideas based on reading documentation:

I think the error message you are getting "instruction requires: 64-bit mode" is probably coming from the assembler which is invoked indirectly by "clang -c XX.s -o XX.o".  According to "man clang" you can pass parameters to the assembler with "-Xassembler".  It also mentions the "-arch" command-line parameter in addition to -mcpu and -march.  Finally, most tools accept the "-m64" parameter.  You might try to figure out what assembler "clang" is invoking, and see what options it accepts.

Hopefully some part of the above is helpful...

-Tuck

--

[Martin Vahi]

A citation from ParaSail 6.5 release announcement:

Actually there is no GPL copyright notice on the ParaSail standard
library.  I'll see what words need to be added to the copyright notice
to make it clearer that the ParaSail standard library can be freely
re-used.

A citation from ./lib/aaa.psi of the ParaSail 8.0 release:

// ParaSail Prototype Standard Library

// Copyright (C) 2011-2015, AdaCore, New York, NY
// This program is provided "as is" with no warranty.
// Report errors at http://groups.google.com/group/parasail-programming-language

interface PSL<> is
end interface PSL

interface PSL::Core<> is

The ./documentation/COPYING3 of the ParaSail 8.0 release seems to be pure GPL_v3 without any linking/code_generation exceptions.

Is there any chance that the AdaCore will upgrade their business model from old fashioned licensing based business model to something that allows the ParaSail to be used in closed source commercial projects without needing to pay the AdaCore or some other licensing party? It's kind of funny that even the Micro$oft allows its C# to be used without paid licenses, the Mozilla Corporation offers its Rust, the Google offers its Go, the Apple offers its various languages without requiring paid licenses and the

https://minix3.org/

has received literally millions of € for development with an intention of making the MINIX3 freely available for closed source commercial projects, to the extent that it has been used even in ways that the original MINIX3 author finds appalling

https://www.cs.vu.nl/~ast/intel/

yet the AdaCore with the knowledge of the Ada historical failures sticks to the old business model. I guess the 2 well fitting examples of huge failures are the Nokia Symbian operating system and the 80-ties TRON

https://www.tron.org/

which both failed to take over the world simply due to DUMB LICENSING. The Google made its Linux-Android available to manufacturers for free as "free beer" and the rest is history. Just imagine, what the world would look like, if in stead of Linux the Japanese TRON had been readily available, for free, to all manufacturers. It was developed with Japanese supermafia/government money, just sitting on their hard-drives or tapes or whatever they had back then, and they just FAILED TO USE IT. I suspect that probably the Linux-Android might have been TRON-Android and the Google data centers might have ran TRON servers in stead of Linux servers. What regards to the popularity of a programming language, then the more developers use the given programming language, the more 3. party libraries are available for that programming language and that in turn makes it possible for other, new, developers adopt the programming language. An Internet classic:

https://www.youtube.com/watch?v=d_AP3SGMxxM

The Symbian case was that at some point the Android had far more Apps than Symbian had and that in turn was a strong argument for the end consumers to buy an Android phone in stead of a Symbian phone. Yet the Nokia made it really hard/expensive to poor students, small companies, freelancers to develop applications for the Symbian operating system. What is the monetary rational behind the decision to make ParaSail expensive for commercial software developers? Why can't the ParaSail development costs be covered with EU or DARPA money, if no private company is willing to finance it? I suspect that if the ParaSail were to be presented to Apple or Mozilla Corporation or even Google, then even those companies might have been willing to pay for the development of the ParaSail tools, a lot like the Apple currently pays for the development of the LLVM, which is free to use for closed source commercial projects. Even the RedHat has its own language development project going on, or at least had one in the past, and there are also other giants, who want to have a fine language and can probably afford to pay for a team of 10 people to work on some ParaSail like project. Even the IBM might have some money for it, specially given how much it has spent on Linux kernel and Eclipse IDE. I do not believe that the IBM takes it lightly that they could be sued by the Oracle for what ever reason just like the Google currently is being sued.

https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.

The ParaSail development costs would be PEANUTS for IBM even as just a probabilistic technology risk mitigation measure, but how can AdaCore sell ParaSail trademark to IBM for billions like the Sun sold Java 2 Oracle, if the ParaSail does not have a properly sized CLOSED SOURCE COMMERCIAL SOFTWARE developer community?

https://en.wikipedia.org/wiki/Sun_acquisition_by_Oracle

I do not understand the AdaCore such decisions. In my opinion, if the licensing issue does not get resolved, the ParaSail is just a fancy "research paper with executable code", a nice beauty to learn from, not a tool for real, paid, work. Anyways, thank You for reading my comment and thank You for the answers.

[Vernon Brown]

Thanks Tuck!

Just adding -m64 to the clang command line is all it took!

Well, almost...   There was one more small challenge in trying to find the source for __chkstk (which LLVM insists on adding calls to on a Windows target), and now I have a fully functioning ParaSail compiler on Windows.  Tested it with the N_Queens example and everything worked as expected.  Woohoo!

[Tucker Taft]

Excellent!

-Tuck

[Tucker Taft]

On Thu, Feb 28, 2019 at 3:30 AM Martin Vahi <sininet...@gmail.com> wrote:

A citation from ParaSail 6.5 release announcement:

Actually there is no GPL copyright notice on the ParaSail standard
library.  I'll see what words need to be added to the copyright notice
to make it clearer that the ParaSail standard library can be freely
re-used.

A citation from ./lib/aaa.psi of the ParaSail 8.0 release:

// ParaSail Prototype Standard Library

// Copyright (C) 2011-2015, AdaCore, New York, NY
// This program is provided "as is" with no warranty.
// Report errors at http://groups.google.com/group/parasail-programming-language

interface PSL<> is
end interface PSL

interface PSL::Core<> is

The ./documentation/COPYING3 of the ParaSail 8.0 release seems to be pure GPL_v3 without any linking/code_generation exceptions.

This is only relevant to files where the copyright actually mentions GPL3.  None of the ParaSail library mentions GPL3.

Is there any chance that the AdaCore will upgrade their business model from old fashioned licensing based business model to something that allows the ParaSail to be used in closed source commercial projects without needing to pay the AdaCore or some other licensing party?

There was no intent to prevent this, but it seems that probably some of the Ada source files that make up the interpreter may need the exception.  It was an oversight that it wasn't there, so thanks for mentioning this.  This has actually been true since 2012, so this wasn't new for release 8.0.  We'll make sure the exception is present in the next release in code that might be linked into user executables.

As far as the overall AdaCore business model, the FSF versions of GNAT have this exception.  AdaCore is also in the process of revamping its "Community" editions, so I believe there are ongoing discussions relating to those.  AdaCore is a company where all products are open source, supported only by subscription fees.  This is somewhat different from companies where much of the software is closed source, and many products are sold using a more conventional "pay-up-front" model.  So licensing is one way to make the open-source, subscription-based business model work, but AdaCore is also investigating alternative approaches for "Community" editions.

...

In any case, thanks for bringing up this issue.  As mentioned, five years ago we removed any mention of GPL3 from all of the (ParaSail) source code for the ParaSail library, but at that time the LLVM-based compiler was still very new.  I suppose it is nice to have reached the stage where the LLVM-based compiler is more mature, and it matters what is the licensing relating to executables built using it.

Take care,

-Tuck

[Martin Vahi]

>...

The ./documentation/COPYING3 of the ParaSail 8.0 release seems to be pure GPL_v3 without any linking/code_generation exceptions.

This is only relevant to files where the copyright actually mentions GPL3.  None of the ParaSail library mentions GPL3.

Is there any chance that the AdaCore will upgrade their business model from old fashioned licensing based business model to something that allows the ParaSail to be used in closed source commercial projects without needing to pay the AdaCore or some other licensing party?

There was no intent to prevent this, but ...

>...

Thank You for the nice and thorough answer. 

I do not want to sound grumpy, but I suspect that there might be differences, how intellectual property law is interpreted in the U.S. and in Estonia. It seems to me that You use a construct, "If it is not explicitly forbidden, then it is allowed.", but my understanding of Estonian copyright law is that by default the copyright owner has restrictions on all use cases, except citation of small portions, and the general rule is: "If it is not explicitly allowed, then it is forbidden." From that perspective a situation, where GPLv3 is not explicitly mentioned at stdlib files, but the documentation folder has GPLv3 as the main license for the project, has an Estonian interpretation that all of the stdlib is under the GPLv3 by default, UNLESS it is explicitly spelled out that the stdlib has some more permissive license. 

I understand that Chinese or Russian military contractors could not care less about some Western World intellectual property licenses and I also understand that the academic circles are fine with full fledged GPLv3, they get their money from grants, not software that is intended to be run by paying clients, but could the AdaCore please add an explicit note about the ParaSail stdlib licensing terms to the ParaSail main copyright file so that people from regions that have a more stringent interpretation of copyright than the U.S. has, can also use the ParaSail for commercial, closed source, projects?

Philosophically speaking, I'm actually very much in favor of The Pirate Bay approach and I think that the movie industry should just ask the money up front in some form of crowd-funding and then not enforce any of that ill-fated nonsense like the "copyright law". I also believe that the whole patent system should be abolished, for all industries, including the pharma industry. Many software projects tend to cost far more than drug research projects and the software projects get funded without software patents. The open source software movement has taken over the most complex and tedious parts of the software development. Yet, the pharma industry uses that LIE that they need patents to fund research and product development. Back in the day, when they wanted to introduce software patents in Europe I even fought against the Micro$oft effort to introduce software patents to Europe:

https://longterm.softf1.com/biased_history/2005_microsoft_hired_inorek_and_grey_to_lobby_for_software_patents/

That is to say, I am certainly not someone, who demands more stringent "intellectual property" limitations (supermafia social demands that the Public Relations people call "laws"), but that does not mean that I do not try to be careful or that I do not try to choose my battles. Hence this meticulosity here with the GPLv3 and the ParaSail stdlib.

Thank You for reading my comment and

thank You for the answers :-)