AdaCore has introduced a patch in FSF GCC to remove ASIS support.
Does anybody know the procedures set by the FSF to challenge a patch?
AdaCore has introduced a patch in FSF GCC to remove ASIS support.
AdaCore is free to do what they want with their own version of
GCC. However, removing a useful feature from the FSF version with the
goal to promote their own, in-house tool is clearly against the spirit
of free software.
Does anybody know the procedures set by the FSF to challenge a patch?
Le 27/09/2021 à 12:06, J-P. Rosen a écrit :
AdaCore has introduced a patch in FSF GCC to remove ASIS support.
This is all the more surprising since it seems to me that ASIS is still
in GNAT Pro. What a lack of fairness.
"J-P. Rosen" <rosen@adalog.fr> writes:
AdaCore has introduced a patch in FSF GCC to remove ASIS support.
AdaCore is free to do what they want with their own version of
GCC. However, removing a useful feature from the FSF version with the
goal to promote their own, in-house tool is clearly against the spirit
of free software.
Does anybody know the procedures set by the FSF to challenge a patch?
It's not just the patch(es), it's any subsequent changes to affected
parts of the compiler.
Le 27/09/2021 à 12:06, J-P. Rosen a écrit :
AdaCore has introduced a patch in FSF GCC to remove ASIS support.This is all the more surprising since it seems to me that ASIS is still
in GNAT Pro. What a lack of fairness.
Le 27/09/2021 à 14:48, Simon Wright a écrit :
"J-P. Rosen" <rosen@adalog.fr> writes:Right, if they want to contribute further patches, they'll have to keep
AdaCore has introduced a patch in FSF GCC to remove ASIS support.
AdaCore is free to do what they want with their own version of
GCC. However, removing a useful feature from the FSF version with the
goal to promote their own, in-house tool is clearly against the spirit
of free software.
Does anybody know the procedures set by the FSF to challenge a patch?
It's not just the patch(es), it's any subsequent changes to affected
parts of the compiler.
it ASIS compatible. That's not a reason to divert gcc to support their
own private interest.
Why is this at all surprising? AdaCore was created off the backs of
U.S. taxpayers via grants Robert Dewar used to fund development of
GNAT.
https://en.wikipedia.org/wiki/GNAT
https://en.wikipedia.org/wiki/Robert_Dewar
This has been a questionable racket from Day 1.
On 29/09/2021 11:03, Simon Wright wrote:
nobody in particular <nobody@devnull.org> writes:
Why is this at all surprising? AdaCore was created off the backs of(a) Boeing
U.S. taxpayers via grants Robert Dewar used to fund development of
GNAT.
https://en.wikipedia.org/wiki/GNAT
https://en.wikipedia.org/wiki/Robert_Dewar
This has been a questionable racket from Day 1.
(b) :plonk:
Que?
nobody in particular <nobody@devnull.org> writes:
Why is this at all surprising? AdaCore was created off the backs of
U.S. taxpayers via grants Robert Dewar used to fund development of
GNAT.
https://en.wikipedia.org/wiki/GNAT
https://en.wikipedia.org/wiki/Robert_Dewar
This has been a questionable racket from Day 1.
(a) Boeing
(b) :plonk:
We have removed ASIS support first in our own trunk of GNAT, and then 6 months later we have removed it from the GCC FSF trunk, so talking about lack of fairness is, well, unfair.
Why? Because ASIS is no longer maintained as an internal standard and hasn't evolved beyond Ada 95 because there was not enough support in the community and among
The lack of 'fairness' (my apologies if you find that word a bit strong)
is that GNAT pro users are suddenly the only ones who can use ASIS,
while a unique tool like Adacontrol (for code control quality) has
always been available equally to the Free and Pro communities...
Perhaps Adacore could help the community and Jean-Pierre in this
process? (targeted help, improved documentation, etc.)?
Le 27/09/2021 à 14:48, Simon Wright a écrit :
"J-P. Rosen" <ro...@adalog.fr> writes:
AdaCore has introduced a patch in FSF GCC to remove ASIS support.
AdaCore is free to do what they want with their own version of
GCC. However, removing a useful feature from the FSF version with the
goal to promote their own, in-house tool is clearly against the spirit
of free software.
Does anybody know the procedures set by the FSF to challenge a patch?
It's not just the patch(es), it's any subsequent changes to affected
parts of the compiler.
Right, if they want to contribute further patches, they'll have to keep
it ASIS compatible. That's not a reason to divert gcc to support their
own private interest.
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr
I suggested in an early message that perhaps the community could build an ASIS API on top of libadalang, if there is a need for that.
I also suggested that libadalang documentation should be improved, I definitely agree with that one !
We have removed ASIS support first in our own trunk of GNAT, and thenThe ASIS standard has not been updated, but AdaCore did a great job of
6 months later we have removed it from the GCC FSF trunk, so talking
about lack of fairness is, well, unfair.It is unfair because asis-gcc is not distributed to the community
Why? Because ASIS is no longer maintained as an internal standard and
hasn't evolved beyond Ada 95 because there was not enough support in
the community and among vendors,
so we've ended up maintaining it on our own for many years, whichcustomers who pay a support contract for ASIS.
lately has become too large a burden.This is plain wrong. You don't maintain ASIS "on your own", there are
In addition, maintaining ASIS tree generation in GNAT has been also a challenge and a resource drain because each time we make a change inWe are talking about FSF-GNAT here. AFAIK, asis-gcc has not been pushed
the GNAT front-end, this may break ASIS and we may have to make
difficult investigation and changes and sometimes almost impossible
changes because there are conflicts between the need of a code
generator (GNAT for GCC or LLVM) and the need of an Ada analysis
library (ASIS).
So we've decided to address this burden by moving tree generation for
ASIS in a separate branch, so that this maintenance burden on GCC
trunk would disappear.
This has been done both in AdaCore's tree where ASIS now resides on a separate branch, and in GCC FSF where the tree generation is
available in GCC 10.x and works well here, and is available for the
community to contribute and maintain for as long as needed.
On 29/09/2021 20:04, Emmanuel Briot wrote:Actually, it is. Apart from ISO verbiage, all the interesting parts of
I suggested in an early message that perhaps the community could build
an ASIS API on top of libadalang, if there is a need for that.
I also suggested that libadalang documentation should be improved, I
definitely agree with that one !
Freely available iso asis spec would help here.
I might have misunderstood Arno's point, but my understanding is that AdaCore no longer makes any patch for ASIS.No, ASIS is still maintained (although as LTM) for paying customers.
So whatever pro customers have access to (and ASIS was always a paying addon), the community also has access to by downloading the latest available sources.No, asis-gcc is not distributed by AdaCore.
The GNAT Pro compiler apparently is losing the capability to generate the tree information, just like the free version of the compiler.generates at the same time). Then you can run ASIS tools.
If you want to use ASIS, my understanding is that you would have to do a separate "compilation" pass using the compiler from the dedicated branch just for the purpose of generating the tree files (and you can discard all the object files it perhaps
This is for sure a pain for AdaControl maintainers and users, no one disputes that. On the other hand, if tree generation was indeed getting in the way of compiler improvements that benefit every one, I, for one, am happy to see the change.I'm afraid this is a red herring. I think rather that AdaCore has a hard
Perhaps Adacore could help the community and Jean-Pierre in this
process? (targeted help, improved documentation, etc.)?
I suggested in an early message that perhaps the community could build an ASIS API on top of libadalang, if there is a need for that.In the beginning of LibAdalang, AdaCore suggested doing that, but they abandonned it.
I also suggested that libadalang documentation should be improved, I definitely agree with that one !
I must admit I fail to see your point in this thread: as far as I know, ASIS has never worked for recent versions of the language (standard was never updated), and AdaCore doesn't not evolve it anymore.Your information is not up-to-date. AdaCore has evolved its ASIS
Yes, that unfortunately means that tools like AdaControl will stop working at some point (you can certainly distribute prebuilt binaries for a while, but for anyone using new language constructs, what happens ?).AdaControl fully supports Ada 2012. Many new features of Ada 202x use
This being open-source software, you could adopt the maintenance of ASIS yourself (or ask other people in the Ada community to help with that). But this is of course a significant endeavor (then again, if you are not ready to do that yourself, whywould you expect a commercial company like AdaCore to do it on your behalf ?) Because that commercial company has customers who pay for that.
Going to back to a more technical discussion, would you highlight why a library like libadalang is not appropriate for AdaControl. I have developed a few code-generation tools based on it. To me, the main issue is the bad documentation, which leaves alot of trial-and-error to find which nodes are relevant when. Besides that, it seems to be fine with any code I have sent its way.
So to recap: you are asking for a Community version of "asis-gcc
Pro": this version is available, it's GCC 10.x (10.3 being the latest available to date). And yes, it's a different version to generate
trees than to compile Ada: the same is true for Pro users and they do
not have specific issues with that.
We are talking about FSF-GNAT here. AFAIK, asis-gcc has not been pushed
to FSF-GNAT.
But this means that users of ASIS will be stuck to GCC 10.x, or will
have to handle two versions of gcc at the same time, which is an endless source of burden.
Le 30/09/2021 à 01:29, Luke A. Guest a écrit :
Actually, it is. Apart from ISO verbiage, all the interesting parts of
On 29/09/2021 20:04, Emmanuel Briot wrote:
I suggested in an early message that perhaps the community could
build an ASIS API on top of libadalang, if there is a need for that.
I also suggested that libadalang documentation should be improved, I
definitely agree with that one !
Freely available iso asis spec would help here.
the ASIS standard is put as comments in the corresponding ASIS packages.
Moreover, AdaCore kept this good habit for all the newly introduced
features that support up to Ada 2012, which would make retrofitting them
into an updated ASIS standard quite easy.
On 30/09/2021 07:23, J-P. Rosen wrote:Yes. Here is a copy of the copyright notice of every ASIS module:
Le 30/09/2021 à 01:29, Luke A. Guest a écrit :
Actually, it is. Apart from ISO verbiage, all the interesting parts of
On 29/09/2021 20:04, Emmanuel Briot wrote:
I suggested in an early message that perhaps the community could
build an ASIS API on top of libadalang, if there is a need for that.
I also suggested that libadalang documentation should be improved, I
definitely agree with that one !
Freely available iso asis spec would help here.
the ASIS standard is put as comments in the corresponding ASIS packages.
Moreover, AdaCore kept this good habit for all the newly introduced
features that support up to Ada 2012, which would make retrofitting
them into an updated ASIS standard quite easy.
Are they gpl'd?
But it's not available from AdaCore's community page. For most users, downloading and building from an FSF site is way too complicated. Call
it asis-gcc or not, what is needed is a simple way to install ASIS support.
(Making a tree generator separate from the compiler is for me another
error, although I can live with it. One of the main benefits of ASIS is
that the ASIS program has the same view of the code as the compiler -
but that's a separate issue).
But it's not available from AdaCore's community page. For most users, downloading and building from an FSF site is way too complicated. Call
it asis-gcc or not, what is needed is a simple way to install ASIS support.
Le 30/09/2021 à 09:53, Luke A. Guest a écrit :
On 30/09/2021 07:23, J-P. Rosen wrote:Yes. Here is a copy of the copyright notice of every ASIS module:
Le 30/09/2021 à 01:29, Luke A. Guest a écrit :
Actually, it is. Apart from ISO verbiage, all the interesting parts
On 29/09/2021 20:04, Emmanuel Briot wrote:
I suggested in an early message that perhaps the community could
build an ASIS API on top of libadalang, if there is a need for that. >>>>> I also suggested that libadalang documentation should be improved,
I definitely agree with that one !
Freely available iso asis spec would help here.
of the ASIS standard is put as comments in the corresponding ASIS
packages.
Moreover, AdaCore kept this good habit for all the newly introduced
features that support up to Ada 2012, which would make retrofitting
them into an updated ASIS standard quite easy.
Are they gpl'd?
On 30/09/2021 07:23, J-P. Rosen wrote:
Freely available iso asis spec would help here.Actually, it is. Apart from ISO verbiage, all the interesting parts of
the ASIS standard is put as comments in the corresponding ASIS packages.
Moreover, AdaCore kept this good habit for all the newly introduced
features that support up to Ada 2012, which would make retrofitting
them into an updated ASIS standard quite easy.
Are they GPL'd and where are they?
Le 30/09/2021 à 09:53, Luke A. Guest a écrit :
On 30/09/2021 07:23, J-P. Rosen wrote:
Freely available iso asis spec would help here.Actually, it is. Apart from ISO verbiage, all the interesting parts
of the ASIS standard is put as comments in the corresponding ASIS
packages.
Moreover, AdaCore kept this good habit for all the newly introduced
features that support up to Ada 2012, which would make retrofitting
them into an updated ASIS standard quite easy.
Are they GPL'd and where are they?
You can find them in the specifications of the various packages, with sentinels (as indicated in my previous message). Another excerpt:
-- Suggestions related to changing this specification to accept new Ada -- features as defined in incoming revision of the Ada Standard (ISO 8652) -- are marked by following comment sentinels:
--
-- --|A2005 start
-- ... the suggestion goes here ...
-- --|A2005 end
--
-- and the discussion items are marked by the comment sentinels of teh form:
--
-- --|D2005 start
-- ... the discussion item goes here ...
-- --|D2005 end
(and the same goes for 2012).
I wanted to know where they are. I once found the entire directory of
asis specs from the iso doc, I think I have them somewhere still.
Where are the updated ones for post 95? There should be archive or
directory with them with no restrictive licensing comments.
Yes. Here is a copy of the copyright notice of every ASIS module:
And that's an issue, why not release them PD or BSD? I've seen the asis
specs before and I'm certain they are not GPL'd, just like the packages
in the Ada RM.
Le 30/09/2021 à 10:28, Luke A. Guest a écrit :
I wanted to know where they are. I once found the entire directory of
asis specs from the iso doc, I think I have them somewhere still.
Where are the updated ones for post 95? There should be archive or
directory with them with no restrictive licensing comments.
Just download ASIS for gnat CE 2019.
On 30/09/2021 11:56, J-P. Rosen wrote:
Le 30/09/2021 à 10:28, Luke A. Guest a écrit :
I wanted to know where they are. I once found the entire directory of
asis specs from the iso doc, I think I have them somewhere still.
Where are the updated ones for post 95? There should be archive or
directory with them with no restrictive licensing comments.
Just download ASIS for gnat CE 2019.
No. See my other message.
If you are talking about the official ASIS specs ("like the packages
in the Ada RM"), they are part of an ISO standard, and as such under
ISO copyright. However, in the case of APIs, ISO allows their use by
any implementation (otherwise, they would be useless).
Exactly, same as the ARM packages.
This has of course nothing common with the GPL or any other open license.
But the issue is, if the specs for the extended ASIS have only been
released under GPL, they are useless to any non-gpl language
implementations as their use infects that implementation causing further issues.
I'm afraid this is a red herring. I think rather that AdaCore has a hard
time convincing people of moving from the well defined, carefully designed ASIS to the terrible mess of LibAdalang.
-- This specification is adapted from the Ada Semantic
Interface --
-- Specification Standard (ISO/IEC 15291) for use with GNAT. In
accordance --
-- with the copyright of that document, you can freely copy and modify
this --
-- specification, provided that if you redistribute a modified version,
any --
-- changes that you have made are clearly
--
Actually, it is. Apart from ISO verbiage, all the interesting parts of
the ASIS standard is put as comments in the corresponding ASIS packages.
Moreover, AdaCore kept this good habit for all the newly introduced
features that support up to Ada 2012, which would make retrofitting them
into an updated ASIS standard quite easy.
If you are talking about the official ASIS specs ("like the packages in
the Ada RM"), they are part of an ISO standard, and as such under ISO copyright. However, in the case of APIs, ISO allows their use by any implementation (otherwise, they would be useless).
On 30/09/2021 11:54, J-P. Rosen wrote:...
If you are talking about the official ASIS specs ("like the packages in
the Ada RM"), they are part of an ISO standard, and as such under ISO
copyright. However, in the case of APIs, ISO allows their use by any
implementation (otherwise, they would be useless).
Exactly, same as the ARM packages.
Umm, someone is confusing the original ASIS drafts with the ISO Standard (which has an ISO copyright with no exceptions). I would definitely not reference the ISO Standard in anything you are freely giving away -- there are copyright trolls out there that could easily decide to get your material banned from the Internet.
"J-P. Rosen" <rosen@adalog.fr> wrote in messageThat was mainly an attempt to introduce more static and tagged typing,
The ASIS design and definition is a mess (at least from the perspective of explaining what is expected). We tried to clean it up in the previous ASIS standardization update, but that was a lot of work and we probably didn't match implementations very well.
The entire model of ASIS doesn't make much sense for static analysis purposes, it's way too focused on syntax rather than semantics.It is a exact image of the program, from which you can derive all
And itOn the contrary. There is no semantic you can analyze in a
doesn't work well for syntax analysis because it requires a compilable program. So it really has a very narrow use case (if any).
Your tool mainly proves that one can use anything with heroic enoughI'm afraid you are confused here. It is very easy to check whether a
efforts. But the effort that your tools goes through to determine basic semantics like whether a type is tagged demonstrates it's hardly a practical way to build a tool.
As far as I know, you're the only one that ever managedFor years, AdaCore tools (gnatelim, gnatstub) used ASIS, not counting
to do anything beyond proof-of-concepts with ASIS.
I can certainly see why
AdaCore might not want to support something solely for one usage.
I can easily believe that Libadalang is even more poorly defined than ASIS (most vendor-generated things are, regardless of the vendor involved). I would guess that the only way to build a tool like yours is to do your own analysis (certainly, that is how I'd approach it). A true Ada Semantic Interface would be a good thing, but ASIS isn't it.
We have decided in any case to stop creating and distributing GNAT Community binaries, since this was causing too much confusion and misunderstanding wrt the license, so doing in the end more harm than good to the community, which we care very muchabout.
So in the future, GNAT will be available directly and only from the FSF versions, and Alire will make that easy.
Alire (https://alire.ada.dev/) already provides GCC 10.3 today, see e.g. "alr toolchain --select"
Alire (https://alire.ada.dev/) already provides GCC 10.3 today, see e.g. "alr toolchain --select"And does it provide a matching version of ASIS?
Le 01/10/2021 02:30, Randy Brukardt a crit :
Umm, someone is confusing the original ASIS drafts with the ISO StandardStrangely enough, my copy of ISO 15291 has no copyright statement at all; might be a "last draft" version.
(which has an ISO copyright with no exceptions). I would definitely not
reference the ISO Standard in anything you are freely giving away --
there
are copyright trolls out there that could easily decide to get your
material
banned from the Internet.
However, the headers of every ASIS-for-Gnat package state:
"This specification is adapted from the Ada Semantic
Interface Specification Standard (ISO/IEC 15291) for use with GNAT. In accordance with the copyright of that document, you can freely copy and modify this specification, provided that if you redistribute a modified version, any changes that you have made are clearly indicated."
(and since that statement dates back to Robert Dewar's times, I'm pretty certain it is reliable).
My memory is that all "interesting" part of the standard was deliberatly
put as comments in the specification, precisely to circumvent the ISO copyright, and allow the use of ASIS without paying an outrageous price to ISO.
Le 01/10/2021 02:18, Randy Brukardt a crit :
"J-P. Rosen" <rosen@adalog.fr> wrote in messageThat was mainly an attempt to introduce more static and tagged typing, and
The ASIS design and definition is a mess (at least from the perspective
of
explaining what is expected). We tried to clean it up in the previous
ASIS
standardization update, but that was a lot of work and we probably didn't
match implementations very well.
it failed due to the complexity involved (and that AdaCore said they would never implement it). LibAdalang made the same error, and got the same unnecessary complexity.
The entire model of ASIS doesn't make much sense for static analysisIt is a exact image of the program, from which you can derive all
purposes, it's way too focused on syntax rather than semantics.
information you need. Some higher level queries are needed, but they can
be provided as secondary queries or added to the standard.
And itOn the contrary. There is no semantic you can analyze in a non-compilable program. And since it analyzes the output of a validated compiler, you can trust it better than any custom analyzer without known pedigree.
doesn't work well for syntax analysis because it requires a compilable
program. So it really has a very narrow use case (if any).
But you didn't use it. True, a first approach or a casual reading of the interface is not very friendly. But the more you use it, the more you
realize that it is very consistently defined, and allows you to do
whatever you need.
My memory is that all "interesting" part of the standard was deliberatlyI don't see how using comments helps anything. The Oracle case makes it pretty clear an API iteself can be covered by a copyright, and surely the comments are covered by the copyright. And the ISO version has no copyright statement other than the usual "All rights reserved".
put as comments in the specification, precisely to circumvent the ISO
copyright, and allow the use of ASIS without paying an outrageous price to >> ISO.
No, the existing part also had major problems. Many of the terms were never defined, many possible effects were missing from the various lists of results, and loads of other things as well.Huh? ASIS uses the terms of, and as defined in, the LRM. And I never hit
Yes, it is a description of the syntactic. Where else can you start from?The entire model of ASIS doesn't make much sense for static analysis
purposes, it's way too focused on syntax rather than semantics.
The liaison to the source is not fundamental to any serious analysis,It is a exact image of the program, from which you can derive all
information you need. Some higher level queries are needed, but they can
be provided as secondary queries or added to the standard.
That's exactly the problem. You start with the source code, which is way too low a level for any useful analysis. At most, you want a simple connection
to the source in the semantic information, not trying to preserve every punctuation mark and comment. (Janus/Ada discards all of that stuff as soon as parsing succeeds.) If you need to refer to the original source, say for error handling purposes, then do that, but don't waste vast amounts of space and time trying to keep loads of irrelevant material.
No sane compiler (validated or not) keeps all of the irrelevant syntactic detail required by ASIS. It ends up getting reconstructed solely for the use of ASIS, and how a rarely used interface is somehow more reliable escapesExcept for the not-required text interface, I see very few of these
me.
A true semantic interface on the lines of the one proposed for ASIS would make good sense (design of types), but the vast majority of the existingSays someone who didn't use or implement ASIS. BTW, I understand that
ASIS belongs in a rubbish bin. Good riddance.
True, the design was based on ideas from Diana. But it was designed with[...] (I think it is a fairly closerepresentation of the internals of early Rational compilers
I've assumed most people used it because it was there and because someIt allowed me to build a very sophisticated tool, valued at 1.24M$ (see https://www.adacontrol.fr), and used by very serious customers. Seems
people had spent a lot of time trying to define it as some sort of Standard. Just because people put a lot of work into something doesn't mean that it is a useful thing.
Le 02/10/2021 11:14, Randy Brukardt a crit :
My memory is that all "interesting" part of the standard was deliberatly >>> put as comments in the specification, precisely to circumvent the ISOI don't see how using comments helps anything. The Oracle case makes it
copyright, and allow the use of ASIS without paying an outrageous price
to
ISO.
pretty clear an API iteself can be covered by a copyright, and surely the
comments are covered by the copyright. And the ISO version has no
copyright
statement other than the usual "All rights reserved".
1) It seems to me that you are confusing the copyright owner with the
right to use the interface. Undoubtedly, ISO is the copyright owner. But
they may authorize unlimited use of the specification, otherwise NO
standard would make sense. Do you infringe copyright if you build an electrical plug that conforms to you electrical standard?
2) Comments help, because they describe precisely what is expected by
every function, and what it provides. Actually, I never open the ASIS standard, everything I need is detailed in the comments.
Le 02/10/2021 11:34, Randy Brukardt a crit :
No, the existing part also had major problems. Many of the terms wereHuh? ASIS uses the terms of, and as defined in, the LRM. And I never hit a "missing result". Curious to see what you are aluding too.
never
defined, many possible effects were missing from the various lists of
results, and loads of other things as well.
Yes, it is a description of the syntactic. Where else can you start from?The entire model of ASIS doesn't make much sense for static analysis
purposes, it's way too focused on syntax rather than semantics.
The liaison to the source is not fundamental to any serious analysis, and anyway you are not required to provide it.It is a exact image of the program, from which you can derive all
information you need. Some higher level queries are needed, but they can >>> be provided as secondary queries or added to the standard.
That's exactly the problem. You start with the source code, which is way
too
low a level for any useful analysis. At most, you want a simple
connection
to the source in the semantic information, not trying to preserve every
punctuation mark and comment. (Janus/Ada discards all of that stuff as
soon
as parsing succeeds.) If you need to refer to the original source, say
for
error handling purposes, then do that, but don't waste vast amounts of
space
and time trying to keep loads of irrelevant material.
No sane compiler (validated or not) keeps all of the irrelevant syntacticExcept for the not-required text interface, I see very few of these "irrelevant syntactic details". OK, you have to keep a boolean to remember
detail required by ASIS. It ends up getting reconstructed solely for the
use
of ASIS, and how a rarely used interface is somehow more reliable escapes
me.
if "end" is followed by a name. Big deal...
It's my (semi-informed) opinion that API Standards are useless, because you have to violate the ISO copyright to use them (or buy a license).Standards are meant to be used. Therefore my not-better-informed opinion
Exactly. Someone copied 90% of the ASIS standard without permission, and *that* is what you are using. And that is depriving ISO of possible revenue.Not at all. The exact specification of ASIS packages is part of the
The semantics, of course. You have a list of entities in a scope. The only interesting thing from the source code is the line/position of the declaration and/or use. The details of the source are irrelevant (such as whether optional keywords are given).If you want to write a program that checks coding standards, you need
[...]
You have to keep nonsense such as whether someone specified
"in" or a matching id after "end".
On the rest, we're going to agree to disagree. Don't expect any support from me for doing anything with ASIS in the ARG.I understand that the structure of Janus makes it inappropriate to
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 379 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 44:28:51 |
| Calls: | 8,141 |
| Calls today: | 4 |
| Files: | 13,085 |
| Messages: | 5,858,054 |