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

[Shark8 <OneWingedShark@gmail.com>]

On 19-Mar-14 14:04, Alan Browne wrote:
> On 2014.03.18, 19:23 , Shark8 wrote:
>> It is my belief that a new, non-GNAT, open-source [and free] Ada 2012
>> translator would be a good thing for both the Ada community and the
>> general programming population -- this without even breaking from the
>> traditional approaches. However, I think that a good, quality IDE/PSE
>> could be quite advantageous; offering better project-management,
>> documentation, verification, versioning, and correctness/consistency
>> checking.
>>
>> The working-copy of the proposal is here:
>> https://drive.google.com/file/d/0BwQVNNshW39cTXVOdWxQaVJ5WjA/edit?usp=sharing
>>
>
> 0. Why is your exec summary so detailed?

Because it's a working copy and I still have a lot to do, esp. WRT 
describing the tools-set.

> 1. Delphi?   Why not in Ada?

Answered upthread: mostly possible issues in licensing and my rotten 
luck getting DB bindings to compile/link correctly.

> 2. Your subject is "... a new open-source Compiler".  Your project is
> not so much about a compiler.

Well, true: it's about a whole PSE (Programming Support Environment), 
but the Ada 83 Library is a decent step in that direction already.

> 3. Text.  Nothing wrong with that.  You can ridicule it all you like
> with quotations, but it is the lowest common denominator.

That's a horrid argument; if we did that with editors we'd be using vi 
and Notepad (actually probably not even Notepad, as its interface is a 
direct result of Larry Tesler's crusade against modes, which was [then] 
the common thing in computers.)

> Strawmen arguments like EOL and character sets is just distraction - such are
> easily fixed/translated if not handled automatically.

And yet they are relevant in that they are (sometimes surprisingly) more 
difficult to fix than you would initially think; there was one incident 
with CSV exported from Excel on PC vs Excel on a Mac that lead to 
some... interesting behavior in an import procedure.

> 4. References to alleged poor design practices at Toyota are specious
> and irrelevant.  The Sony reference too.  (You're employing "scare"
> marketing.  Bzzzt.).

Really?
Correctness should be a concern for programmers; could Toyota's errors 
have been made using Ada... *sure*, but some of them would have been 
easy to avoid (e.g. using protected objects for shared values.) Plus, I 
think Toyota would disagree that it's irrelevent, seeing how they just 
$1.2 bn settlement. See: 
http://www.politico.com/story/2014/03/toyota-settlement-doj-104809.html

> 5. This whole project, to me, puts the programmer too far away from the
> source code.  Buries it.  That is not a good objective.

That's one problem I'm trying to address, it's not about burring the 
source, but getting closer to the [underlying] structure and ideas that 
the code is expressing. An example would be CASE statements, the 
language mandates that they have complete coverage (individually or via 
OTHERS) so would it be putting the programmer "too far away from the 
source" to allow something like "right-click > show as table" to convert 
the [possibly nested] CASE statement into a decision table? I mean we 
already have the mandate that all the possibilities must be covered.

Or, imagine having the ability to visually tinker with a [sub]type; say 
you have Type Voltage is new Natural range 0 .. 220. that you could have 
represented with two sliders in the same channel (for 'First and 'Last) 
and possibly a tab for indicating [or specifying] the 
default/uninitialized value. (Perhaps packaging Annex H's "Pragma 
Normalize_Scalars" value right there with the type.)