Re: ANN: Kickstarter for beginning work on a new open-source Compiler

[Shark8 <onewingedshark@gmail.com>]

[I'm trying Thunderbird as a news-reader; I believe it sent Mr. Leake an email reply rather than the desired public-posting here.]

On 19-Mar-14 07:25, Stephen Leake wrote:
> Shark8 <onewingedshark@gmail.com> writes:
>
>> The working-copy of the proposal is here:
>> https://drive.google.com/file/d/0BwQVNNshW39cTXVOdWxQaVJ5WjA/edit?usp=sharing
>
> You have clearly put a lot of thought into this.
>
> I have a few comments/questions.
>
> 1) Why write the new tool in Delphi and not Ada?
>
>      The Rationale section "Why implement in Delphi 2007" provides a
>      rationale for implementing in dotnet, not Delphi. There is an Ada
>      compiler for dotnet (I think it needs work, but you are already
>      proposing a huge amount of work, so what's a little more?).
>
>      And even that rationale is not convincing. Emacs, Eclipse, GPS are
>      all portable to Linux and Windows; in what other environments do you
>      require running the IDE?

Good points; very good.
I'll try to address them in the next update, right now I have no good 
and articulable reasons.

One reason to use Delphi rather than Ada is licensing; IIUC the license 
for GNAT would prohibit development of a commercial product and 
[probably] the development of something that /would be/ used in a 
commercial product -- I simply do not wish to burden users of this 
system in that manner.

I do need to elaborate on that [the rationale] to flesh it out, which is 
why the proposal is a "working copy" -- I was afraid that failing to 
commit to publishing it would lead to an "endless planning" circuit in 
myself.

> 2) The Rationale section "Why Write an Ada Compiler?" provides a
>     justification for writing an IDE plugin, not an Ada compiler.
>
>     You can easily extract text from the database and feed it to gnat, or
>     any other Ada compiler.

True.
But storing it as unprocessed text means that you [well, your 
computer/tools] have to repeat a lot of work (e.g. parsing) again and 
again. "Moving that processing to the outer loop" can reduce that, and 
given the advantages of working w/ meaningful-data vs. generalized-text 
it seems like a reasonable thing to do.

> 3) Storing text as correct, structured data:
>
>      a) has been tried before; in Rational R1000
>         (http://en.wikipedia.org/wiki/R1000 - not a very informative
>         link, unfortunately). Did you review any lessons learned from
>         that?

I've heard some good things about the R1000, but haven't seen a lot of 
information on it -- I did find a PDF on a review of it, which I still 
need to read, I'm currently working on the Ada 83 Rationale (for a 
better understanding of the language's roots/ideologies).

Evaluation of the Rational Environment
URL: http://www.sei.cmu.edu/reports/88tr015.pdf

>
>      b) Prevents people checking in code so colleagues can answer the
>         question "why doesn't this compile"?
>

Non-working code should be kept out of the [main] code-base; this 
situation can be handled with a chat/message-board (or similar) sort of 
functionality -- There's *no* need to pollute your revisions with code 
that cannot work. (i.e. Don't compromise your secure communication 
network by forcing acceptance of unsecured components. // In-band 
communication [of metadata] is a Bad-Thing(tm).)

>      c) Prevents writing skeletons; something I do when starting a
>         totally new project.

Howso?
You can still have the procedure's "is null" spec; and Delphi itself has 
been generating empty subprograms forever.

>
> 4) You don't address "Why write a new IDE rather than a plugin for an
>     existing one?"
>
>      IDEs are huge, complex beasts. What you propose to do can be
>      accommodated as a plugin for Eclipse, Emacs, or GPS.

So?
That argument would preclude development of new OSes; which would be 
detrimental, especially considering that we are right-now at the cusp of 
real need for formally validated/verified (and therefore [more] secure 
and stable) OSes.

>      GPS from AdaCore is a nice Ada IDE, but it lacks many features that
>      I find essential on a daily basis, which is why I use Emacs instead.
>      Any new tool you start will be even more limited.

Agreed (that GPS is pretty nice, yet missing a lot).

> 5) Current IDEs (GPS, Eclipse, less so Emacs) use a parsed
>     representation of the source for refactoring, completion, and the
>     other tasks you require in an IDE. That gives the best of both
>     worlds.

Yes, and given how nicely that works it makes sense that other tools 
could benefit from operating with parsed info rather than "plain text" 
(e.g. repositories, which could store name-changes as updating a 
property in the stored object and allow for ignoring non-meaningful 
changes [like tabs vs. spaces]).

> 6) What is your business plan? You are proposing to directly compete
>     with AdaCore; it is not at all clear from the proposal that you
>     understand what that means.

I understand that AdaCore mainly deals in support not, strictly 
speaking, the compiler itself; but even if this weren't the case, I'm of 
the opinion that the programming community could benefit from another 
freely available implementation... especially one which doesn't share 
the same codebase.