a new language, designed for safety !

a new language, designed for safety !

[Nasser M. Abbasi]

Fyi, for those who like safe languages, watch out Ada and
Spark, Apple introduced new "safe" language today, meant
to replace objective-C:

"In addition, Apple notes how the language was designed for
safety, with variables that have to be initialized before
use <WOW!>, arrays and integers that are checked for
overflow <WOW!> and automatic memory management."

"Inferred types make code cleaner and less prone to mistakes"
<REALLY?, I do not like inferred types>

"while modules eliminate headers and provide namespaces"
<good>

"Memory is managed automatically, and you don’t even need
to type semi-colons"

"Variables are always initialized before use"

"for example, simple three-character keywords
define a variable (var) or constant (let)."

If you like to read more about it:

https://developer.apple.com/swift/

--Nasser

Re: a new language, designed for safety !

[Luke A. Guest]

Quel surprise, it's YAC (yet another C)

Re: a new language, designed for safety !

[Dan'l Miller]

On Tuesday, June 3, 2014 7:21:45 PM UTC-5, Luke A. Guest wrote:
> Quel surprise, it's YAC (yet another C)

If Swift is yet another C, then Ada is yet another Pascal.  As food for thought for a few features to import into Ada202X, I encourage everyone to read Apple's language reference for Swift, which is available as a free iBook (but not a PDF apparently).  Generally, my initial impression is that Swift is Objective-C done right, ridding us of that obnoxious Objective-C bracket syntax for "sending" OO "messages" via Smalltalk-like selectors.  Had Brad Cox given the world Swift during the 1980s instead of Objective-C, C++ might never have been as popular as it became during the late 1980s and during the 1990s.

Re: a new language, designed for safety !

[Dan'l Miller]

On Tuesday, June 3, 2014 8:19:03 PM UTC-5, Dan'l Miller wrote:
> On Tuesday, June 3, 2014 7:21:45 PM UTC-5, Luke A. Guest wrote:
> 
> > Quel surprise, it's YAC (yet another C)

Calling Swift yet another C is somewhat disingenuous.  For example, the switch statement is drastically reworked & expanded to be based on patterns in Swift instead of based on itemized integer values in C:

“A switch statement has the following form:
 switch control expression {
case pattern 1:
    statements
case pattern 2 where condition:
    statements
case pattern 3 where condition,
pattern 4 where condition:
    statements
default:
    statements
}”
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l

“Patterns

A pattern represents the structure of a single value or a composite value. For example, the structure of a tuple (1, 2) is a comma-separated list of two elements. Because patterns represent the structure of a value rather than any one particular value, you can match them with a variety of values. For instance, the pattern (x, y) matches the tuple (1, 2) and any other two-element tuple. In addition matching a pattern with a value, you can extract part or all of a composite value and bind each part to a constant or variable name.

In Swift, patterns occur in variable and constant declarations (on their left-hand side), in for-in statements, and in switch statements (in their case labels). Although any pattern can occur in the case labels of a switch statement, in the other contexts, only wildcard patterns, identifier patterns, and patterns containing those two patterns can occur.

You can specify a type annotation for a wildcard pattern, an identifier pattern, and a tuple pattern to constraint the pattern to match only values of a certain type.

GRAMMAR OF A PATTERN
 pattern → wildcard-patterntype-annotationopt
‌ pattern → identifier-patterntype-annotationopt
‌ pattern → value-binding-pattern[…]”
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l

Re: a new language, designed for safety !

[Dan'l Miller]

On Tuesday, June 3, 2014 8:19:03 PM UTC-5, Dan'l Miller wrote:
> On Tuesday, June 3, 2014 7:21:45 PM UTC-5, Luke A. Guest wrote:
> 
> > Quel surprise, it's YAC (yet another C)

This YAC is not your father's Oldsmobile.  As another example, Swift (along with Seed7, Fortress, and a few other languages lately) allow declaration of prefix, infix, & postfix operators that do not appear in the standardized language:

"Custom Operators
You can declare and implement your own custom operators in addition to the standard operators provided by Swift. Custom operators can be defined only with the characters / = - + * % < > ! & | ^ . ~.

New operators are declared at a global level using the operator keyword, and can be declared as prefix, infix or postfix:

operator prefix +++ {}
The example above defines a new prefix operator called +++. This operator does not have an existing meaning in Swift, and so it is given its own custom meaning below in the specific context of working with Vector2D instances. For the purposes of this example, +++ is treated as a new "prefix doubling incrementer" operator. It doubles the x and y values of a Vector2D instance, by adding the vector to itself with the addition assignment operator defined earlier:

@prefix @assignment func +++ (inout vector: Vector2D) -> Vector2D {
    vector += vector
    return vector
}
This implementation of +++ is very similar to the implementation of ++ for Vector2D, except that this operator function adds the vector to itself, rather than adding Vector2D(1.0, 1.0):

var toBeDoubled = Vector2D(x: 1.0, y: 4.0)
let afterDoubling = +++toBeDoubled
// toBeDoubled now has values of (2.0, 8.0)
// afterDoubling also has values of (2.0, 8.0)

Precedence and Associativity for Custom Infix Operators[...]"

Excerpt From: Apple Inc. "The Swift Programming Language." iBooks. https://itun.es/us/jEUH0.l

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/03/2014 05:21 PM, Luke A. Guest wrote:
> Quel surprise, it's YAC (yet another C)

Looks a lot like Go to me.

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36

Re: a new language, designed for safety !

[Georg Bauhaus]

On 04/06/14 06:05, Dan'l Miller wrote:
> On Tuesday, June 3, 2014 8:19:03 PM UTC-5, Dan'l Miller wrote:
>> On Tuesday, June 3, 2014 7:21:45 PM UTC-5, Luke A. Guest wrote:
>>
>>> Quel surprise, it's YAC (yet another C)
>
> Calling Swift yet another C is somewhat disingenuous.

> Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l

The book is also accessible by directing a web browser to
https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/index.html

Re: a new language, designed for safety !

[Dan'l Miller]

On Monday, June 2, 2014 8:37:12 PM UTC-5, Nasser M. Abbasi wrote:
> Fyi, for those who like safe languages, watch out Ada and
> 
> Spark, Apple introduced new "safe" language today, meant
> to replace objective-C:
> 
> "In addition, Apple notes how the language was designed for
> safety, with variables that have to be initialized before
> use <WOW!>, arrays and integers that are checked for
> overflow <WOW!> and automatic memory management."

One major category of Objective-C unsafety that Swift apparently does absolutely nothing to prevent (until fatal error at runtime, hence the unsafety) is whether an object actually provides a method for a given selector or whether an object actually provides a forwarding to another object for a given selector or is handled by a per-class or per-object-instance error handler or none of the above, which precipitates the fatal error at runtime.

Except when an iPhone or iPad or iPod or MacOSX app presents to the human user a roulette wheel of all object instances or of all class names to choose an object instance or class to extend dynamically at runtime, the programmer certainly knows at source-code-editing time which categories of object instances or which  class name is to have additional methods or forwardings for a given selector--and hence when to create some overtly-declared-at-compile-time categorization (e.g., subclass) of a class or of a categorization of object-instance.  Hence, the vast vast vast majority of so-called dynamic extension of an object instance or of a class is actually an engineering-time decision (i.e., prior to compile-time).  Therefore, Objective-C and Swift both provide no compile-time-assured mechanism to 100% assure that a given class (or a given object instance) will able to successfully invoke a method or forwarding when "sent" a "message" for a given selector.  This is not surprising for the 1980s-vintage Objective-C, back when Smalltalk was often held up as the ultimate state-of-the-art in OO; Smalltalk had much the same fundamental unsafety, due in turn much the same selector mechanisms as Objective-C.  But almost 3 decades later, Swift has the same fundamental unsafety at its core and throughout all nontrivial source code, when following Apple's advice regarding when so-called dynamic extension of a class or of a object-instance is to be utilized.

Or in short, Swift's so-called safety is much more like swiss cheese (Swift cheese?) than Ada's higher expectations of what constitutes safety.

Re: a new language, designed for safety !

[Robert A Duff]

"Dan'l Miller" <optikos@verizon.net> writes:

> ...This is not surprising for the 1980s-vintage
> Objective-C, back when Smalltalk was often held up as the ultimate
> state-of-the-art in OO; Smalltalk had much the same fundamental
> unsafety, due in turn much the same selector mechanisms as
> Objective-C.

Yeah, Objective-C is basically just Smalltalk tacked onto the side of C.

But I wouldn't call it "unsafe" if you get a run-time error.
To me, "unsafe" means "misuse can cause unpredictable behavior".
Array indexing is safe in Ada (you get a run-time error if
you go out of bounds), but unsafe in C (anything can happen
if you go out of bounds).

Anyway, I guess your point is that Ada prevents dangling dispatch at
compile time, which is a good thing, whereas Swift, Objective C,
and Smalltalk do not.

- Bob

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-04, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> "Dan'l Miller" <optikos@verizon.net> writes:
>
>> ...This is not surprising for the 1980s-vintage
>> Objective-C, back when Smalltalk was often held up as the ultimate
>> state-of-the-art in OO; Smalltalk had much the same fundamental
>> unsafety, due in turn much the same selector mechanisms as
>> Objective-C.
>
> Yeah, Objective-C is basically just Smalltalk tacked onto the side of C.
>
> But I wouldn't call it "unsafe" if you get a run-time error.
> To me, "unsafe" means "misuse can cause unpredictable behavior".
> Array indexing is safe in Ada (you get a run-time error if
> you go out of bounds), but unsafe in C (anything can happen
> if you go out of bounds).
>

To me, it's all about remaining in control when Bad Things Happen.

If you take a runtime error in a controlled manner (ie: Ada style) then
you remain in control. If you go out of bounds in C then you are no
longer in control of what happens next.

Compile time errors are preferred, but runtime errors are ok if you
cannot achieve that, _provided_ they happen in a controlled manner.

Swift is an interesting idea with some uses, but the real benefits
to our computing ecosystem will come when someone designs a plug in
replacement for C which can be used in all the environments which C
can currently be used in and which is easy enough for the typical C
programmer to learn.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Georg Bauhaus]

On 04/06/14 17:25, Dan'l Miller wrote:
> Or in short, Swift's so-called safety is much more like swiss cheese (Swift cheese?) than Ada's higher expectations of what constitutes safety.

Consequently, Ada programmers just cannot express certain valuable
algorithms if the execution environment isn't known at compile time.

I understand that GNAT supports dynamic plug-ins. Are they safe?

http://www.adacore.com/knowledge/technical-papers/dynamic-plug-in-loading-with-ada/

Re: a new language, designed for safety !

[Nasser M. Abbasi]

On 6/4/2014 2:43 PM, Robert A Duff wrote:

> But I wouldn't call it "unsafe" if you get a run-time error.

This depends if the run-time error could have been avoided in
the first place had the compiler been able to detect the
problem at compile time or not?

With these dynamics languages (Julia, swift, Matlab, etc...),
many errors will show up at run-time, since there is no
static time compiler with a rich language semantics that
allows the compiler to do more analysis and find more errors
even before the program is run.

Even though some dynamic languages will not let one at run
time mix apples and oranges, and will give run-time error,
I'd rather know at compile time that I am not mixing apples
with oranges. That is much more safe.

Many times, one writes a program in a dynamic language
and they would only know there is a bug in the code if
they happen to hit a condition that leads to a
code path at run-time with a bug in it.  There could
be a bug sitting in some corner of the source code
for years and not be detected because of this since it
is hard to test for all code paths all the time.

So one will fly with the code and keep fingers crossed.

On the other hand, dynamic languages are more fun,
since they allow one to hack code so much faster! And
many also come with build-in GUI.

Also they come with really cool modern names such as
"Julia", "Swift", "Hack", "Python", etc..

Compare this to the name "Ada", named after a programmer
who lived hundreds of years ago :)

> To me, "unsafe" means "misuse can cause unpredictable behavior".
> Array indexing is safe in Ada (you get a run-time error if
> you go out of bounds), but unsafe in C (anything can happen
> if you go out of bounds).
>
> Anyway, I guess your point is that Ada prevents dangling dispatch at
> compile time, which is a good thing, whereas Swift, Objective C,
> and Smalltalk do not.
>
> - Bob
>

--Nasser

Re: a new language, designed for safety !

[Adam Beneschan]

On Thursday, June 5, 2014 2:13:46 AM UTC-7, Nasser M. Abbasi wrote:

> On the other hand, dynamic languages are more fun,
> since they allow one to hack code so much faster! And
> many also come with build-in GUI.
> 
> Also they come with really cool modern names such as
> "Julia", "Swift", "Hack", "Python", etc..
> 
> Compare this to the name "Ada", named after a programmer
> who lived hundreds of years ago :)

What about "Go", which was named for a board game invented thousands of years ago?  

OK, I don't know where the name really came from (it's probably an acronym for Google Obnoxiousness).  Anyway, it's not the name of a language that determines how popular a language becomes.  It's whether the language's inventor has a good beard.

                              -- Adam

Re: a new language, designed for safety !

[Adam Beneschan]

On Thursday, June 5, 2014 2:13:46 AM UTC-7, Nasser M. Abbasi wrote:

> Also they come with really cool modern names such as
> "Julia", "Swift", "Hack", "Python", etc..
> 
> Compare this to the name "Ada", named after a programmer
> who lived hundreds of years ago :)

Actually, now that I think about it, was Swift named after an author who lived three hundred years ago?  I guess time will tell whether this modest proposal of a language will have a big impact on the programming world, or whether the impact will be more Lilliputian.

                                -- Adam

Re: a new language, designed for safety !

[sbelmont700]

On Thursday, June 5, 2014 11:55:30 AM UTC-4, Adam Beneschan wrote:
> 
> Actually, now that I think about it, was Swift named after an author who lived three hundred years ago?  I guess time will tell whether this modest proposal of a language will have a big impact on the programming world, or whether the impact will be more Lilliputian.
> 

The real question is, what approach will be taken with respect to byte-ordering?

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/05/2014 08:33 AM, Adam Beneschan wrote:
>
> OK, I don't know where the name really came from (it's probably an acronym
> for Google Obnoxiousness).  Anyway, it's not the name of a language that
> determines how popular a language becomes.  It's whether the language's
> inventor has a good beard.

I guess any language I invent will be popular, then.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail
23

Re: a new language, designed for safety !

[Robert A Duff]

"Nasser M. Abbasi" <nma@12000.org> writes:

> On 6/4/2014 2:43 PM, Robert A Duff wrote:
>
>> But I wouldn't call it "unsafe" if you get a run-time error.
>
> This depends if the run-time error could have been avoided in
> the first place had the compiler been able to detect the
> problem at compile time or not?

No, the meaning of "safe" and "unsafe" doesn't depend on that.

> With these dynamics languages (Julia, swift, Matlab, etc...),
> many errors will show up at run-time, since there is no
> static time compiler with a rich language semantics that
> allows the compiler to do more analysis and find more errors
> even before the program is run.

Quite true, but not relevant to my point about the word "unsafe".
As I said, to me, "unsafe" (applied to programming language features)
means "misuse of this feature can cause unpredictable behavior".

Run-time errors are bad enough, but unpredictable behavior is far
worse; it's useful to have a word to describe that distinction.

> Even though some dynamic languages will not let one at run
> time mix apples and oranges, and will give run-time error,
> I'd rather know at compile time that I am not mixing apples
> with oranges. That is much more safe.

No, it is "better", perhaps, but not "safer".  By my definition,
"safe" and "unsafe" are absolutes; a feature either can or cannot cause
unpredictable behavior.  There's no "safer" and "less safe".

>> To me, "unsafe" means "misuse can cause unpredictable behavior".
>> Array indexing is safe in Ada (you get a run-time error if
>> you go out of bounds), but unsafe in C (anything can happen
>> if you go out of bounds).

- Bob

Re: a new language, designed for safety !

[Dan'l Miller]

On Thursday, June 5, 2014 5:40:24 PM UTC-5, Robert A Duff wrote:
> "Nasser M. Abbasi" writes: 
> > On 6/4/2014 2:43 PM, Robert A Duff wrote:
>
> >> But I wouldn't call it "unsafe" if you get a run-time error.

I am glad that you are not working for the FAA or NTSB regarding what is and is not a safety-critical software system.

Currently in the popular press, General Motors ignition-switch recall has strong resemblance to Mr. Duff's picayune excessively-narrow definition of safety of a system.  For over a decade, GM fervently held the perfectly-factually-correct position that if the ignition switch has dangling from it nothing other than the keys that GM issued plus one key ring, then the spring in the ignition switch was of sufficient resistance to assure that gravity does not turn the ignition switch to a different position (e.g., the off-position, which could cause sudden loss of power-steering and power-brakes, in turn playing a nontrivial role in a wreck, in part by surprising the driver into a panic).  Mr. Duff and GM adopt an excessively narrow definition of safety of a system here in their respective lines of reasoning.  GM's official position was in effect:  it is not our fault if a driver of a vehicle put more keys on their keyring than what GM issued at the time of initial sale and those nonGM keys placed more load on the ignition-switch's spring than what GM minimally designed that spring to withstand.  The federal government correctly lambasted such an excessively narrow definition of safety of a system, because of a failure-mode caused by a commonplace scenario that could have easily been averted at build-time of the system.  The question of safety does not hinge on academic purity of an ideology, but rather on how affordably & practically preventable at build-time a commonplace failure-mode scenario is.

> > This depends if the run-time error could have been avoided in
> > the first place had the compiler been able to detect the
> > problem at compile time or not?
> 
> No, the meaning of "safe" and "unsafe" doesn't depend on that.

Actually in general, it does.  Please see the explanation below at the end of this posting.

> > With these dynamics languages (Julia, swift, Matlab, etc...),
> > many errors will show up at run-time, since there is no
> > static time compiler with a rich language semantics that
> > allows the compiler to do more analysis and find more errors
> > even before the program is run.
> 
> Quite true, but not relevant to my point about the word "unsafe".
> As I said, to me, "unsafe" (applied to programming language features)
> means "misuse of this feature can cause unpredictable behavior".

During an accident investigation, the NTSB and FAA would reject your irrelevance assertion, as explained below at the end of this posting.

> Run-time errors are bad enough, but unpredictable behavior is far
> worse; it's useful to have a word to describe that distinction.
> 
> > Even though some dynamic languages will not let one at run
> > time mix apples and oranges, and will give run-time error,
> > I'd rather know at compile time that I am not mixing apples
> > with oranges. That is much more safe.

So would I, Nasser.  I thoroughly reject the narrowness of Mr. Duff's picayune definition of software safety and of what is or is not a facilitator of a safety-critical software system.

> No, it is "better", perhaps, but not "safer".  By my definition,
> "safe" and "unsafe" are absolutes; a feature either can or cannot cause
> unpredictable behavior.  There's no "safer" and "less safe".

Mr. Duff, here I agree with you, but not in the way that you intend:  Mr. Duff, your unwisely narrow definition of safety of a software system is not less safe, it is full-fledged unsafe.  Mr. Duff, your own definition of "safety" of software in a safety-critical software system is itself unsafe, because usage of your definition could itself directly cause bodily injury or loss of life if it were utilized in a safety-critical system.  How?  By lulling people into believing that all of the state-of-the-art assurances & precautions have been taken to eliminate whole categories of failure of software.  And when I say state of the art, I mean here 1970s-era technology on which Ada & C++ & only a very few other OO languages are based:  compile-time assurance that an invoked method actually was implemented, instead of SmallTalk's, Objective-C's, and Swift's unsafe cavalierness in this regard.  To not have compile-time assurance that an invoked OO method actually was implemented on some rarely-executed branch of code is taking the software industry & knowledgebase back as much as 4 decades in direction of primitive ignorance of the solutions to that commonplace defect.

> >> To me, "unsafe" means "misuse can cause unpredictable behavior".
> >> Array indexing is safe in Ada (you get a run-time error if
> >> you go out of bounds), but unsafe in C (anything can happen
> >> if you go out of bounds).

What matters to you regarding software safety is quite different than what matters to the National Transportation Safety Board (NTSB) and the Federal Aviation Administration (FAA).  If a fatal runtime error due to an unimplemented method (which Ada would catch at compile-time, but Swift & Objective-C would catch only at runtime via the equivalent of an exception whose default behavior is to stop executing the entire program), then if that fatal runtime error causes any sort of dangerous mishap (e.g., near miss; crash; collision; fire) due to the software no longer performing its function, then the NTSB and/or FAA rightly would identify that fatal runtime exception and the lack of method-implementation that Ada (and C++ and a very few other languages) would have caught at compile-time as the root-causes of the dangerous mishap.  This becomes ever worse if the dangerous mishap causes injury or death.  Whoever caused those 2 root causes might expect to be defending themselves in at least wrongful-death litigation if not more-severe court cases in the aftermath of investigating the unsafe software.

So with only a modicum of respect for Mr. Duff's picayune definition of safety of a software system, I reject the excessive narrowness of that definition and replace it with:  if the software fault (e.g., unimplemented method in Swift or Objective-C accompanied by the -->default!!!<-- handling of that fault of fatal exit of the entire program) can cause bodily injury or loss of life then the software is unsafe.  Mr. Duff itemizes one avenue to travel to arrive at unsafety, but Mr. Duff's picayune definition of safety does a disservice in forestalling all consideration of the other avenues to arrive at unsafety (i.e., casually arrive at an outcome of bodily injury or loss of life when the state-of-the-art infrastructure would have easily detected at compile-time the root cause months, years, or decades before the injury or loss of life).

Re: a new language, designed for safety !

[G.B.]

On 06.06.14 17:13, Dan'l Miller wrote:
> If a fatal runtime error due to an unimplemented method (which Ada would catch at compile-time, but Swift & Objective-C would catch only at runtime via the equivalent of an exception whose default behavior is to stop executing the entire program), then if that fatal runtime error causes any sort of dangerous mishap (e.g., near miss; crash; collision; fire) due to the software no longer performing its function, then the NTSB and/or FAA rightly would identify that fatal runtime exception and the lack of method-implementation that Ada (and C++ and a very few other languages) would have caught at compile-time as the root-causes of the dangerous mishap.

Since Ada programs may well have "unimplemented methods",
I think this appraisal of Ada's capabilities needs to be
augmented a little in order to be valid, viz. by referring
to reversed defaults in the way dispatching is part of the
language, and to rule checkers.
   Because, with regard to dispatching, if an Ada programmer
decides to use run-time dispatching, then there may well be
run-time errors. These include calling an undefined primitive
operation of a tagged type. This is demonstrated below.

The program fails predictably, even though it does not use
pointers or tricks.

$ ./comptime

raised CONSTRAINT_ERROR : comptime.ada:35 tag check failed
$

That's a run-time error, I'd say, stopping the program.
The state of P2.Op being unimplemented is announced in source,
though, ("abstract") which is different from just absence
as in Objective-C etc.

Consequently, a set of additional rules is needed to prevent
such errors in Ada , and some checking as can be performed
with AdaControl, I should think. Ada alone is better if less
lenience is, but won't suffice.

package Pak is

    pragma Pure (Pak);

    package P1 is
       type A is abstract tagged private;
       procedure Op (X : in out A) is abstract;
    private
       type A is abstract tagged null record;
    end P1;

    package P2 is
       type T is new P1.A with private;
       overriding procedure Op (X : in out T);
    private
       type T is new P1.A with null record;
    end P2;

    package P3 is
       -- Drills a hole!
       type TA is abstract new P2.T with private;
       overriding procedure Op (X : in out TA) is abstract;
    private
       type TA is abstract new P2.T with null record;
    end P3;

end Pak;

with Pak;
procedure Comptime
is
    Obj : Pak.P2.T;
    X : Pak.P1.A'Class := Obj;
begin
    Pak.P3.TA'Class(X).Op;  -- run-time dispatching
end Comptime;

package body Pak is

    package body P2 is
       overriding procedure Op (X : in out T)
       is begin
          null;
       end Op;
    end P2;

end Pak;

Re: a new language, designed for safety !

[Niklas Holsti]

On 14-06-06 20:51 , G.B. wrote:
> On 06.06.14 17:13, Dan'l Miller wrote:
>> If a fatal runtime error due to an unimplemented method (which Ada
>> would catch at compile-time, but Swift & Objective-C would catch only
>> at runtime [ snip ] 
> 
> Since Ada programs may well have "unimplemented methods",   

   [ snip ]

> Because, with regard to dispatching, if an Ada programmer
> decides to use run-time dispatching, then there may well be
> run-time errors. These include calling an undefined primitive
> operation of a tagged type. This is demonstrated below.

I think the error in your example is of a different kind.

> The program fails predictably, even though it does not use
> pointers or tricks.
> 
> $ ./comptime
> 
> raised CONSTRAINT_ERROR : comptime.ada:35 tag check failed
> $
> 
> That's a run-time error, I'd say, stopping the program.

Yes.

> The state of P2.Op being unimplemented is announced in source,
> though, ("abstract") which is different from just absence
> as in Objective-C etc.

This is not the error in your program.

> package Pak is
> 
>    pragma Pure (Pak);
> 
>    package P1 is
>       type A is abstract tagged private;
>       procedure Op (X : in out A) is abstract;
>    private
>       type A is abstract tagged null record;
>    end P1;
> 
>    package P2 is
>       type T is new P1.A with private;
>       overriding procedure Op (X : in out T);
>    private
>       type T is new P1.A with null record;
>    end P2;
> 
>    package P3 is
>       -- Drills a hole!

No.

>       type TA is abstract new P2.T with private;
>       overriding procedure Op (X : in out TA) is abstract;
>    private
>       type TA is abstract new P2.T with null record;
>    end P3;
> 
> end Pak;
> 
> with Pak;
> procedure Comptime
> is
>    Obj : Pak.P2.T;
>    X : Pak.P1.A'Class := Obj;
> begin
>    Pak.P3.TA'Class(X).Op;  -- run-time dispatching

The error, as I understand it, is trying to convert X, which is of a
classwide type covering Pak.P2.T, to a classwide type (Pak.P3.TA'Class)
which does not cover Pak.P2.T. (Apologies if I'm not using the correct
ARM terms for this.) The dispatching call is not the problem.

This error is more similar to a subtype or type conversion error, where
the source value violates the constraints of the target type.

Yes, Ada has run-time errors, but they are not the result of
"unimplemented methods".

An example coming closer to an unimplemented method error would, IMO, be
a run-time dispatch to an operation with two or more controlling
parameters, where the actual parameters have different tags, and there
is no operation for this mixture of tags (of course, as Ada does not
permit such multiple dispatch).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: a new language, designed for safety !

[Robert A Duff]

Boy, you completely misunderstood my point!  Possibly my fault;
perhaps I was unclear.

"Dan'l Miller" <optikos@verizon.net> writes:

> Currently in the popular press, General Motors ignition-switch recall
> has strong resemblance to Mr. Duff's picayune excessively-narrow
> definition of safety of a system.

I didn't define "safety of a system".

> So with only a modicum of respect for Mr. Duff's picayune definition
> of safety of a software system, ...

Nor did I define "safety of a software system".

You are mixing up "safe" as applied to programming language features,
and "safe" as in the real-world sense of preventing injury and death.
Sorry for the misunderstanding, but the rest of your rant doesn't apply
to anything I actually said -- as if I advocate ignition keys that kill
(sheesh!).

Unsafe programming language features can cause injury or death
-- but only in safety critical systems.  (E.g. dangling dispatch
in Objective C won't kill anybody if the program is a word processor.)
But safe programming language features can cause injury or death, too
(in safety critical systems).  You see the difference?

- Bob

Re: a new language, designed for safety !

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> The error, as I understand it, is trying to convert X, which is of a
> classwide type covering Pak.P2.T, to a classwide type (Pak.P3.TA'Class)
> which does not cover Pak.P2.T. (Apologies if I'm not using the correct
> ARM terms for this.) The dispatching call is not the problem.

Right.

> This error is more similar to a subtype or type conversion error, where
> the source value violates the constraints of the target type.

It is EXACTLY a type conversion error.  The Tag is wrong, so the type
conversion raises Constraint_Error.  It never gets to the dispatching
call.  There is no dangling dispatching in Ada!  It is impossible for
a call to (try to) call the nonexistent body of an abstract operation.

> Yes, Ada has run-time errors, but they are not the result of
> "unimplemented methods".

Right.

- Bob

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Fri, 06 Jun 2014 15:43:37 -0400, Robert A Duff wrote:

> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> This error is more similar to a subtype or type conversion error, where
>> the source value violates the constraints of the target type.
> 
> It is EXACTLY a type conversion error.

I would say it not a conversion error, it is a mandated behavior of the
type conversion operation. No error, since you could write a legal program
that would exploit this behavior.

> The Tag is wrong, so the type
> conversion raises Constraint_Error.  It never gets to the dispatching
> call.

Semantically it dispatches to a "body" that raises Constraint_Error.
Furthermore, whether the check is made on the callee's or caller's context
is irrelevant, the behavior is just same.

> There is no dangling dispatching in Ada!  It is impossible for
> a call to (try to) call the nonexistent body of an abstract operation.

Yes. The difference is, as always, in the time the checks happen. In Ada
the check for a missing body happens at compile time, which is why it is
safe. Anything that happens at run-time is no more error and *if*
unanticipated then is a bug.

The advantage of Ada is to prevent undesired things to happen at run-time
through static typing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-06, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>
> You are mixing up "safe" as applied to programming language features,
> and "safe" as in the real-world sense of preventing injury and death.
> Sorry for the misunderstanding, but the rest of your rant doesn't apply
> to anything I actually said -- as if I advocate ignition keys that kill
> (sheesh!).
>
> Unsafe programming language features can cause injury or death
> -- but only in safety critical systems.  (E.g. dangling dispatch
> in Objective C won't kill anybody if the program is a word processor.)
> But safe programming language features can cause injury or death, too
> (in safety critical systems).  You see the difference?
>

Indeed. There's nothing to stop you from creating the next Therac-25
using Ada. That's why the language is only one part of the safety
critical process.

However, languages like Ada are _very_ useful in the problem areas
which don't justify a full safety critical process and where you rely
a lot more on the language itself.

A really good example are the security libraries at the core of the
applications in use on the Internet. Unfortunately, for reasons
previously discussed, you are not going to be able to replace
OpenSSL (for example) with a Ada version. (Sadly :-()

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Georg Bauhaus]

On 06/06/14 20:39, Niklas Holsti wrote:

>> with Pak;
>> procedure Comptime
>> is
>>     Obj : Pak.P2.T;
>>     X : Pak.P1.A'Class := Obj;
>> begin
>>     Pak.P3.TA'Class(X).Op;  -- run-time dispatching
>
> The error, as I understand it, is trying to convert X, which is of a
> classwide type covering Pak.P2.T, to a classwide type (Pak.P3.TA'Class)
> which does not cover Pak.P2.T. (Apologies if I'm not using the correct
> ARM terms for this.) The dispatching call is not the problem.


While the technical side of the error has now been correctly
classified, does this difference in run-time mechanics between
Ada and Objective-C make a difference on the programming side?

The programmer is making assumptions about the type of
an object. When the programming situation is characterized
by dropping pedantry of language, if I may, then his or her
assumptions will be, respectively,

- "I can view this Obj as of type TA and call Op"
     (Ada, wrong view)

- "I can send Op: to Obj of presumed type TA"
    (Objective-C, no method)

Neither the Ada compiler nor the Objective-C compiler will detect
the error. The detection of these errors at run-time is different
per language. But does this make a difference either when programming,
or when collecting the remains of a stopped program?

The only difference I can see is that Ada provides for
a formal description of something, while Objective-C
provides for a semi-formal description of the lack of
something.

When correcting the error in either language, will their be
similarities?

Re: a new language, designed for safety !

[Robert A Duff]

Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:

> - "I can view this Obj as of type TA and call Op"
>     (Ada, wrong view)
>
> - "I can send Op: to Obj of presumed type TA"
>    (Objective-C, no method)

The two errors seem rather different, to me.  To get the Ada error, you
have to do a downward type conversion, something that is well known to
be questionable -- you need to be careful to say "if X in T3'Class...".

The dangling dispatch error in Objective C can happen on any call,
and there's no practical way to protect against it.

- Bob

Re: a new language, designed for safety !

[Dan'l Miller]

On Sunday, June 8, 2014 8:56:56 AM UTC-5, Robert A Duff wrote:
> Georg Bauhaus writes:
> > - "I can view this Obj as of type TA and call Op"
> >     (Ada, wrong view)
> >
> > - "I can send Op: to Obj of presumed type TA"
> >    (Objective-C, no method)
> 
> The two errors seem rather different, to me.  To get the Ada error, you
> have to do a downward type conversion, something that is well known to
> be questionable -- you need to be careful to say "if X in T3'Class...".

They seem quite different to me too.  ASIS could search for all downward-cast syntax and flag it.  One of the very few areas where C++98 and later is superior to even Ada2012 is that the permissible downcast syntaxes are obnoxiously obvious in modern C++ to facilitate easier pattern-matching via grep and its brethren:

1) dynamic_cast< Type2 >( expressionOfType1 ), which uses runtime-type-identification (RTTI) to perform an Ada-like runtime check

2) static_cast< Type2 >( expressionOfType1 ), which is an unsafe* compile-time forcing of Type2's virtual-function table instead of Type1's.  If Type2 does not conform to Type1 in this regard (e.g., unimplemented member-function), then undefined* behavior occurs (e.g., eventual crash, corruption of resources, potential attack surface for a worm to inject machine code).

Unfortunately, Ada's downcast syntax is not so obnoxiously conspicuous to the human eye or to mere regular-expression-only pattern-matchers.  To rigorously search for Ada downcasts throughout all source code, it seems that a parser with the expressive power of ASIS is needed.

* "Unsafe" here is defined using Mr. Duff's narrower definition of "undefined behavior" in an unsafe language, as established on another recent thread-branch above back along this thread.  Of course, undefined behavior in an "unsafe language" also meets my wider definition of "unsafe system" since 1) the compiler plus source code that it is compiling forms a system and 2) undefined behavior could easily be the root-cause bodily injury or death.

> The dangling dispatch error in Objective C can happen on any call,
> and there's no practical way to protect against it.

  i.e., no practical way *within* Objective-C, the way that Objective-C is defined today.  Even with an Objective-C equivalent of ASIS (if one were ever to exist, such as based on LLVM-Clang's relatively lucid C++ compiler source-code), there exist more avenues of precipitating a run-time error at time of "sending" a "message" to an object in Objective-C than only downcasting.  Hence, there is no especially-dangerous syntax to look for in Objective-C, because every single "message" "sent" to an object can be dangerous in the way that (only) downcasting is dangerous in Ada.

Re: a new language, designed for safety !

[J-P. Rosen]

Le 08/06/2014 18:13, Dan'l Miller a écrit :
> They seem quite different to me too.  ASIS could search for all
> downward-cast syntax and flag it.  One of the very few areas where
> C++98 and later is superior to even Ada2012 is that the permissible
> downcast syntaxes are obnoxiously obvious in modern C++ to facilitate
> easier pattern-matching via grep and its brethren:

You cannot identify anything safely with grep. Give me your regexp, and
I'll give you a counter example that is not recognized.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Sun, 8 Jun 2014 09:13:11 -0700 (PDT), Dan'l Miller wrote:

> Unfortunately, Ada's downcast syntax is not so obnoxiously conspicuous to
> the human eye or to mere regular-expression-only pattern-matchers.

Downcast is not a problem in the given example. The problem is
inconsistently implemented multi-method. The user expectation, I presume,
was multi-method call on a body (of mixed type) which the language does not
allow to override, and defines as Constraint_Error.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Niklas Holsti]

On 14-06-08 22:36 , Dmitry A. Kazakov wrote:
> On Sun, 8 Jun 2014 09:13:11 -0700 (PDT), Dan'l Miller wrote:
> 
>> Unfortunately, Ada's downcast syntax is not so obnoxiously conspicuous to
>> the human eye or to mere regular-expression-only pattern-matchers.
> 
> Downcast is not a problem in the given example. The problem is
> inconsistently implemented multi-method.

In Georg's example, the methods have a single argument, so it was not a
mixed multi-method problem. I mentioned the mixed multi-method case as
an Ada run-time error that is closer to a "missing method" error.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 09 Jun 2014 08:30:34 +0300, Niklas Holsti wrote:

> On 14-06-08 22:36 , Dmitry A. Kazakov wrote:
>> On Sun, 8 Jun 2014 09:13:11 -0700 (PDT), Dan'l Miller wrote:
>> 
>>> Unfortunately, Ada's downcast syntax is not so obnoxiously conspicuous to
>>> the human eye or to mere regular-expression-only pattern-matchers.
>> 
>> Downcast is not a problem in the given example. The problem is
>> inconsistently implemented multi-method.
> 
> In Georg's example, the methods have a single argument, so it was not a
> mixed multi-method problem. I mentioned the mixed multi-method case as
> an Ada run-time error that is closer to a "missing method" error.

Yes. Your example was correct. I objected to Georg's analysis. Syntax of
downcast is barely related to this. In both cases the language invents a
method (e.g. as raising something), since a call cannot really fail anyway.
The language-invented methods here are unsafe because it is not what the
programmer would normally expect calling them [*]. Thus in both cases the
languages are unsafe.

Ada is obviously safer because the area where the problem arise is much
narrower (only tagged types, only multi-methods, only certain and rare
cases of multi-method calls).

------
*  Robert's definition of unsafety formulated differently: unexpected
behavior from familiar syntax ["misuse"].

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Pascal Obry]

I would add to this thread that we do not need a new language for safety
I think Ada can do that... But we do need better software engineers to
properly use the too-many already available languages :)

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: a new language, designed for safety !

[Dan'l Miller]

On Monday, June 9, 2014 2:06:27 AM UTC-5, Dmitry A. Kazakov wrote:
> The language-invented methods here are unsafe because it is not what the
> programmer would normally expect calling them [*]. Thus in both cases the
> languages are unsafe.
> [...snip...]
> *  Robert's definition of unsafety formulated differently: unexpected
> behavior from familiar syntax ["misuse"].

[Unexpected /= undefined]
No, Dmitry, that is my definition formulated differently, not Robert's.  Robert's definition that I was critiquing (and that, in effect, you too are critiquing) hinges on *undefined* behaviors in the language specification (and constantly remembering to not evoke them is a battle-hardened badge of honor in C & C++ culture).  *Unexpected* behaviors that are well-defined as required in the Ada language specification are, by definition, not *undefined* in Ada---hence the key point of departure from Robert's excessively-narrow definition of "unsafe".  Unexpected behaviors resulting from familiar syntax are a category of defect that can go unnoticed in a shipped product and cause harshly-deliterious outcomes---hence the coverage by my definition of "unsafe" evoking Nancy Leveson's system-engineering school of thought on safeware http://en.wikipedia.org/wiki/Nancy_Leveson.  In my definition of "unsafe", for brevity and to drive home a crucial safety point, I rename "harshly-deliterious outcomes" to be bodily injury and/or death.

(Btw, why fast-forward safety in software to bodily injury and death? The concept of safety becomes too politically muddled for clear thinking if debate goes off on tangents when the set of harshly-deliterious outcomes includes legal liability, company's financial loss, user's financial loss, and other harshly-deliterious outcomes that depend on socioeconomic philosophy [which some readers might not share] rather than the more-instinctual moral laws of don't hurt people and don't kill people [which I hope all readers share].)

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 9 Jun 2014 09:07:07 -0700 (PDT), Dan'l Miller wrote:

> On Monday, June 9, 2014 2:06:27 AM UTC-5, Dmitry A. Kazakov wrote:
>> The language-invented methods here are unsafe because it is not what the
>> programmer would normally expect calling them [*]. Thus in both cases the
>> languages are unsafe.
>> [...snip...]
>> *  Robert's definition of unsafety formulated differently: unexpected
>> behavior from familiar syntax ["misuse"].
> 
> [Unexpected /= undefined]
> No, Dmitry, that is my definition formulated differently, not Robert's. 
> Robert's definition that I was critiquing (and that, in effect, you too
> are critiquing) hinges on *undefined* behaviors in the language
> specification (and constantly remembering to not evoke them is a
> battle-hardened badge of honor in C & C++ culture).  *Unexpected*
> behaviors that are well-defined as required in the Ada language
> specification are, by definition, not *undefined* in Ada---hence the key
> point of departure from Robert's excessively-narrow definition of
> "unsafe".  Unexpected behaviors resulting from familiar syntax are a
> category of defect that can go unnoticed in a shipped product and cause
> harshly-deliterious outcomes---hence the coverage by my definition of
> "unsafe" evoking Nancy Leveson's system-engineering school of thought on
> safeware http://en.wikipedia.org/wiki/Nancy_Leveson.  In my definition of
> "unsafe", for brevity and to drive home a crucial safety point, I rename
> "harshly-deliterious outcomes" to be bodily injury and/or death.

You draw a line between objectively and subjectively unexpected behavior.
That does not much matter from the software design point of view [*]. The
effect is same. The programmer assumes one thing and the effect is
different.

Consider a perfectly defined language with all behavior specified which is
so cryptic that nobody could use it *safely*. E.g. Brainf*ck. Would you
call such a language safe?

> (Btw, why fast-forward safety in software to bodily injury and death? The
> concept of safety becomes too politically muddled for clear thinking if
> debate goes off on tangents when the set of harshly-deliterious outcomes
> includes legal liability, company's financial loss, user's financial loss,
> and other harshly-deliterious outcomes that depend on socioeconomic
> philosophy [which some readers might not share] rather than the
> more-instinctual moral laws of don't hurt people and don't kill people
> [which I hope all readers share].)

The problem is in proving that it was the software at fault, and if the
responsible acted accordingly to the standard practices, the fault could
have been prevented. But the standard practices are crap, and proving
anything about crappy software is more difficult than developing it anew.
And the next line of defence is that the software is newer actually sold,
it is bundled, licensed, free.

---------
* When human beings get involved, subjective becomes objective.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Stephen Leake]

Pascal Obry <pascal@obry.net> writes:

> I would add to this thread that we do not need a new language for safety
> I think Ada can do that... 

Can anyone comment on why Apple didn't just use Ada?

-- 
-- Stephe

Re: a new language, designed for safety !

[Luke A. Guest]

Stephen Leake <stephen_leake@stephe-leake.org> wrote:
> Pascal Obry <pascal@obry.net> writes:
> 
>> I would add to this thread that we do not need a new language for safety
>> I think Ada can do that... 
> 
> Can anyone comment on why Apple didn't just use Ada?

NIH syndrome? They can't control it? Take your pick.

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-10, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
> Pascal Obry <pascal@obry.net> writes:
>
>> I would add to this thread that we do not need a new language for safety
>> I think Ada can do that... 
>
> Can anyone comment on why Apple didn't just use Ada?
>

From a technical viewpoint, Ada is a great language to use, with lots
of features at various levels designed to produce robust and reliable
code. In an ideal world, the use of Ada would be widespread.

From a practical and pragmatic viewpoint however, Ada is a poor language
to use.

Jeffrey Carter said it best when he stated that only 2% of programmers
have an engineering mindset. I dispute that 2% figure (I think it's
probably closer to 20%-30%) but the point stands. Ada is designed for
engineers; those who write code in other ways (ie: the majority of
Apple's customers) would probably find Ada too stifling.

This is also one of the reasons why we don't see a large Ada uptake
in other areas even though GNAT has been freely available for years.

(The other reasons include the restricted set of host and target
platforms for Ada when compared to C and the fact the nicely
pre-packaged ACT version of GNAT is licenced under the GPL instead
of the GMGPL.)

For general programming for which C would be used, if you want to get
your typical C progammer using something safer than C, I still think
my Oberon-14 idea represents the general path to take: create a
"safer", not "safe", language with some of the basic Ada concepts
transplanted into it and which is easy for a C programmer to learn.

Such a language must be _easy_ to port to a wide range of host and
target platforms and you must be able to replace existing library
code written in C with code written in your new language without
disturbing the rest of the application.

Once you have them exposed to a "safer" programming mindset, _then_
you can introduce them to Ada for the bigger stuff.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Lucretia]

On Tuesday, 10 June 2014 13:28:33 UTC+1, Simon Clubley  wrote:

> Apple's customers) would probably find Ada too stifling.
> 
> This is also one of the reasons why we don't see a large Ada uptake
> in other areas even though GNAT has been freely available for years.

The name and the history of the language don't help either.

> (The other reasons include the restricted set of host and target
> platforms for Ada when compared to C and the fact the nicely

the fact that the FSF version has been crippled on purpose to stop the building of certain said targets, you mean?

> pre-packaged ACT version of GNAT is licenced under the GPL instead
> of the GMGPL.)

This is a major problem actually. With GCC C/C++/.Obj-C/etc., someone can come along and just write a mobile app and sell it without any fear of being sued as you didn't release the source. Not so with ACT's GPL'd GNAT, all because they want people to shell out a stupid amount of money for support, which people writing mobile apps just cannot afford. The fact that they now release all their libs as GPL is just a joke as well; may as well say "we'll make sure nobody uses Ada for anything but trains, planes and bombs."

> For general programming for which C would be used, if you want to get
> your typical C progammer using something safer than C, I still think
> my Oberon-14 idea represents the general path to take: create a
> "safer", not "safe", language with some of the basic Ada concepts
> transplanted into it and which is easy for a C programmer to learn.

I have thought of something similar. I'll have to try to find your idea and take a look.

> Such a language must be _easy_ to port to a wide range of host and
> target platforms and you must be able to replace existing library
> code written in C with code written in your new language without
> disturbing the rest of the application.
> 
> Once you have them exposed to a "safer" programming mindset, _then_
> you can introduce them to Ada for the bigger stuff.

I've actually considered just foregoing Ada and trying to create a language better than the C's and other derived languages but applying ideas from Ada.

This thought keeps stopping me from progressing any of my Ada projects, including game creation ones.

Luke.

Re: a new language, designed for safety !

[J-P. Rosen]

Le 10/06/2014 14:42, Lucretia a écrit :
>> pre-packaged ACT version of GNAT is licenced under the GPL instead
>>> of the GMGPL.)
> This is a major problem actually. With GCC C/C++/.Obj-C/etc., someone
> can come along and just write a mobile app and sell it without any
> fear of being sued as you didn't release the source. Not so with
> ACT's GPL'd GNAT [...]

But it the case with FSF Gnat. Nobody forces you to use ACT's version.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: a new language, designed for safety !

[Lucretia]

On Tuesday, 10 June 2014 13:50:49 UTC+1, J-P. Rosen  wrote:

> > This is a major problem actually. With GCC C/C++/.Obj-C/etc., someone
> > can come along and just write a mobile app and sell it without any
> > fear of being sued as you didn't release the source. Not so with
> > ACT's GPL'd GNAT [...]
> 
> But it the case with FSF Gnat. Nobody forces you to use ACT's version.

But you've not taken into account everything else I said. RE: The libs are GPL'd too, therefore you cannot do anything reasonable these days without unicode or XML, in fact both Android and iOS require the use of both. You would have to try to find an appropriately licenced lib or write your own or bind to something else.

Luke.

Re: a new language, designed for safety !

[Brad Moore]

On 14-06-10 07:00 AM, Lucretia wrote:
> On Tuesday, 10 June 2014 13:50:49 UTC+1, J-P. Rosen  wrote:
>
>>> This is a major problem actually. With GCC C/C++/.Obj-C/etc., someone
>>> can come along and just write a mobile app and sell it without any
>>> fear of being sued as you didn't release the source. Not so with
>>> ACT's GPL'd GNAT [...]
>>
>> But it the case with FSF Gnat. Nobody forces you to use ACT's version.
>
> But you've not taken into account everything else I said. RE: The libs are GPL'd too, therefore you cannot do anything reasonable these days without unicode or XML, in fact both Android and iOS require the use of both. You would have to try to find an appropriately licenced lib or write your own or bind to something else.

Is there a list of such libraries that would be of interest? If that is 
what is stopping people from using Ada, then I would think it wouldn't 
be too hard to find people willing to work on creating non-GPL versions 
of such libraries, or to create bindings to other libraries that already 
exist. At the very least it would be a lot easier than inventing a new 
language, and then creating versions of those libraries in that new 
language.

Brad

>
> Luke.
>

Re: a new language, designed for safety !

[J-P. Rosen]

Le 10/06/2014 16:43, Brad Moore a écrit :
>> But you've not taken into account everything else I said. RE: The libs
>> are GPL'd too, therefore you cannot do anything reasonable these days
>> without unicode or XML, in fact both Android and iOS require the use
>> of both. You would have to try to find an appropriately licenced lib
>> or write your own or bind to something else.
> 
> Is there a list of such libraries that would be of interest? If that is
> what is stopping people from using Ada, then I would think it wouldn't
> be too hard to find people willing to work on creating non-GPL versions
> of such libraries, or to create bindings to other libraries that already
> exist. At the very least it would be a lot easier than inventing a new
> language, and then creating versions of those libraries in that new
> language.

I'd like some examples too. AFAIK, the standard library that comes with
FSF-Gnat has the famous copyright exception (i.e. they are GMGPL, not
pure GPL). And other libraries have the copyright chosen by their
author, as for any language...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: a new language, designed for safety !

[Lucretia]

On Tuesday, 10 June 2014 15:43:04 UTC+1, Brad Moore  wrote:

> Is there a list of such libraries that would be of interest? If that is 
> what is stopping people from using Ada, then I would think it wouldn't 
> be too hard to find people willing to work on creating non-GPL versions 
> of such libraries, or to create bindings to other libraries that already 
> exist. At the very least it would be a lot easier than inventing a new 
> language, and then creating versions of those libraries in that new 
> language.

If you really need a list, go to AdaCore's libre site, they're all GPL, and all a problem due to that.

Also, the fact that the JVM interfacing stuff is also GPL will stop anyone trying to create closed source commercial apps too on relevant platforms, i.e. Android.

That's not the only problem, I know of people who have left Ada and gone to Java because of bugs in GNAT which won't get fixed unless someone pays for it, e.g. go back to my previous point of cost. Also, to add to that, they ended up getting slagged off in email by ACT for pointing it out, basically being told they were wrong. This also leads to the fact that GNAT is developed behind closed doors and anybody wanting to contribute patches, won't see them being included. * These are things I have been told by people who have gone through the various issues above.

I like Ada, but it has issues which make me think about going in a different direction.

Luke.

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Tue, 10 Jun 2014 08:33:07 -0700 (PDT), Lucretia wrote:

> On Tuesday, 10 June 2014 15:43:04 UTC+1, Brad Moore  wrote:
> 
>> Is there a list of such libraries that would be of interest? If that is 
>> what is stopping people from using Ada, then I would think it wouldn't 
>> be too hard to find people willing to work on creating non-GPL versions 
>> of such libraries, or to create bindings to other libraries that already 
>> exist. At the very least it would be a lot easier than inventing a new 
>> language, and then creating versions of those libraries in that new 
>> language.
> 
> If you really need a list, go to AdaCore's libre site, they're all GPL,
> and all a problem due to that.

That is not an answer. I am using nothing from that site, except for
GtkAda. The company I am working in also uses nothing.

If you have concrete things in mind, I am sure people here will be glad to
point you closed source friendly alternatives.

-----------------
One of Ada problems that people simply do not ask or else ask for kind of
cosmic-sized things, unbelievable for a small start-up. Presently, I'd
claim, Ada lacks nothing substantial at the library side. Few missing
things, you mentioned XML parser (why anybody would need an atomic hand
grenade?), could be done in a weak or so with existing tools.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Dan'l Miller]

On Tuesday, June 10, 2014 2:44:56 AM UTC-5, Dmitry A. Kazakov wrote:
> On Mon, 9 Jun 2014 09:07:07 -0700 (PDT), Dan'l Miller wrote:
> > On Monday, June 9, 2014 2:06:27 AM UTC-5, Dmitry A. Kazakov wrote:
> >> The language-invented methods here are unsafe because it is not what the
> >> programmer would normally expect calling them [*]. Thus in both cases the
> >> languages are unsafe.
> >> [...snip...]
> >> *  Robert's definition of unsafety formulated differently: unexpected
> >> behavior from familiar syntax ["misuse"].
> 
> > [Unexpected /= undefined]
> > No, Dmitry, that is my definition formulated differently, not Robert's. 
> > Robert's definition that I was critiquing (and that, in effect, you too
> > are critiquing) hinges on *undefined* behaviors in the language
> > specification (and constantly remembering to not evoke them is a
> > battle-hardened badge of honor in C & C++ culture).  *Unexpected*
> > behaviors that are well-defined as required in the Ada language
> > specification are, by definition, not *undefined* in Ada---hence the key
> > point of departure from Robert's excessively-narrow definition of
> > "unsafe".
> 
> You draw a line between objectively and subjectively unexpected behavior.

No, it is Robert who insists on injecting [objectively] "undefined" into this conversation as the sole form of unsafety in a programming language.  Analogous to you, I sweep all undefined behavior, unexpected/unintended behavior, gaffs (e.g., = where == was intended in C), and just plain old bad habits into one bucket-o'-stuff that can easily cause deleterious outcomes (e.g., death or bodily injury).  That bucket-o'-stuff is the set of root-causes of unsafety in imperative programming languages.  That bucket-o'-stuff is a quite-larger proper superset of Mr. Duff's set of root-causes of unsafety in imperative programming languages.

Btw, the goal of proactively facilitating safeware that Ada partially achieves generally tends toward declarative programming (especially at compile-time) that replaces or cross-checks the imperative programming.  Imperative programming by its very nature (except in multistage programming via interpreters within the compiler) is at run-time.  This debate of declarative at compile-time versus imperative at run-time is the key difference between Ada (and to a lesser degree C++ due its numerous undefined behaviors) versus Objective-C and Swift.

> That does not much matter from the software design point of view [*]. The
> effect is same. The programmer assumes one thing and the effect is
> different.

But correctly categorizing [objectively] undefined behavior versus [subjectively "undefined" to use your term] unexpected/unintended behavior very much does matter to Mr. Duff's definition of unsafe, which I am critiquing as being too narrow.  Likewise, Dmitry, you effectively make the case that Mr. Duff's definition of unsafe is too narrow by not covering both the [objectively] undefined and [subjectively "undefined"] unexpected/unintended categories of root causes of unsafety.  This is my point as well.

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Tue, 10 Jun 2014 09:31:59 -0700 (PDT), Dan'l Miller wrote:

> On Tuesday, June 10, 2014 2:44:56 AM UTC-5, Dmitry A. Kazakov wrote:
>> On Mon, 9 Jun 2014 09:07:07 -0700 (PDT), Dan'l Miller wrote:
>>> On Monday, June 9, 2014 2:06:27 AM UTC-5, Dmitry A. Kazakov wrote:
>>>> The language-invented methods here are unsafe because it is not what the
>>>> programmer would normally expect calling them [*]. Thus in both cases the
>>>> languages are unsafe.
>>>> [...snip...]
>>>> *  Robert's definition of unsafety formulated differently: unexpected
>>>> behavior from familiar syntax ["misuse"].
>> 
>>> [Unexpected /= undefined]
>>> No, Dmitry, that is my definition formulated differently, not Robert's. 
>>> Robert's definition that I was critiquing (and that, in effect, you too
>>> are critiquing) hinges on *undefined* behaviors in the language
>>> specification (and constantly remembering to not evoke them is a
>>> battle-hardened badge of honor in C & C++ culture).  *Unexpected*
>>> behaviors that are well-defined as required in the Ada language
>>> specification are, by definition, not *undefined* in Ada---hence the key
>>> point of departure from Robert's excessively-narrow definition of
>>> "unsafe".
>> 
>> You draw a line between objectively and subjectively unexpected behavior.
> 
> No, it is Robert who insists on injecting [objectively] "undefined" into
> this conversation as the sole form of unsafety in a programming language.

OK, then I misunderstood you both.

> Btw, the goal of proactively facilitating safeware that Ada partially
> achieves generally tends toward declarative programming (especially at
> compile-time) that replaces or cross-checks the imperative programming. 
> Imperative programming by its very nature (except in multistage
> programming via interpreters within the compiler) is at run-time.  This
> debate of declarative at compile-time versus imperative at run-time is the
> key difference between Ada (and to a lesser degree C++ due its numerous
> undefined behaviors) versus Objective-C and Swift.

Well, there is a problem with declarative paradigm that the effect (the
program behavior induced by declarations) is not obvious to the programmer,
less obvious, the more powerful declarative framework becomes. Which is per
our definition makes such language unsafe. [Compilers shall have no free
will]

I think Ada has a good balance of imperative execution control and
declarative types system.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Pascal Obry]

Le mardi 10 juin 2014 à 10:48 +0000, Luke A.Guest a écrit : 
> Stephen Leake <stephen_leake@stephe-leake.org> wrote:
> > Pascal Obry <pascal@obry.net> writes:
> > 
> >> I would add to this thread that we do not need a new language for safety
> >> I think Ada can do that... 
> > 
> > Can anyone comment on why Apple didn't just use Ada?
> 
> NIH syndrome? They can't control it? Take your pick.

Yes plus:

- We hear again and again that a language is not all, you need
libraries. But obviously when you come with a new langage you start with
an empty bag! Everything must be recreated.

- We hear that every new language is a revolution, it makes code
cleaner, easier to maintain, easy to develop and with such power than
you gain a lot in productivity... Well we should all be able to take
such language and create a simulation for a complex system as a plane in
one or two days I suppose.

Why Apple choose a new language you asked? Yes probably to gain control
of something... But this language, as some created in recent years, will
just add more garbage into our systems for no added value :( With a bit
of luck Swift will be a big failure and we will never cross a piece of
code :)

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: a new language, designed for safety !

[Tero Koskinen]

10.6.2014 19:31, Dmitry A. Kazakov wrote:
> On Tue, 10 Jun 2014 08:33:07 -0700 (PDT), Lucretia wrote:
> 
>> On Tuesday, 10 June 2014 15:43:04 UTC+1, Brad Moore  wrote:
>>
>>> Is there a list of such libraries that would be of interest?
>>
>> If you really need a list, go to AdaCore's libre site, they're all GPL,
>> and all a problem due to that.
> 
> That is not an answer. I am using nothing from that site, except for
> GtkAda. The company I am working in also uses nothing.
> 
> If you have concrete things in mind, I am sure people here will be glad to
> point you closed source friendly alternatives.

I would like to have following non-gpl, preferably 100% Ada, libraries
without GNAT specific dependencies:
- GUI library
- JSON library (well, I have written my own, but it isn't perfect yet)
- Tiny-YAML library [1]
- HTTP client library with SSL (using curl bindings for now)
- Plain socket library with poll/epoll support
- Some sort of easy interface to execute programs on *nix/Windows
  and capture the input/output/stderr/exit code[2]
- Server side web framework which does not require the latest
  GNAT to work (=works with older GNAT releases and other compilers
  also)
- At least semi-decent runtime/peripheral library for ARM Cortex-Mx
  processors[3]
- Interface to sqlite databases (using my own partial bindings atm.)
- reStructuredText to HTML formatter
- Antlr4 runtime

For many things bindings to existing C libraries would be fine, but
usually authors select different licenses for Ada bindings than
what the original C library has. Like why on earth use plain GPL
or even GMGPL for bindings if original C library is distributed
under public domain, MIT, or BSD license?!

Of course, authors can do that, but it still baffles me and
causes some extra headache when I need to decipher can I
combine the licenses and the code with my own code.

Yours,
 Tero

[1] http://search.cpan.org/dist/YAML-Tiny/lib/YAML/Tiny.pm
[2] *nix part is easy, but I have no idea how to do that on Windows :)
[3] Like libopencm3, http://libopencm3.org, or http://mbed.org

Re: a new language, designed for safety !

[J-P. Rosen]

Le 10/06/2014 17:33, Lucretia a écrit :
> If you really need a list, go to AdaCore's libre site, they're all
> GPL, and all a problem due to that.
Ada is not AdaCore. Go to other sites, and you'll find plenty of useful
libraries with as many licenses as other languages. Hint: explore
Adalog's site ;-)

> Also, the fact that the JVM interfacing stuff is also GPL will stop
> anyone trying to create closed source commercial apps too on relevant
> platforms, i.e. Android.
Once again, that's AdaCore; Atego provided another one (TBH: I'm not
sure what it's state is currently).

> That's not the only problem, I know of people who have left Ada and
> gone to Java because of bugs in GNAT which won't get fixed unless
> someone pays for it, e.g. go back to my previous point of cost. Also,
> to add to that, they ended up getting slagged off in email by ACT for
> pointing it out, basically being told they were wrong. This also
> leads to the fact that GNAT is developed behind closed doors and
> anybody wanting to contribute patches, won't see them being included.
This is FUD. Anybody can contribute patches to FSF, and so does AdaCore.
AdaCore is a commercial company; you can choose a compiler from AdaCore,
or a compiler from FSF, like for any other language. Would you argue
that C is being impaired because Microsoft C is not free?

In addition, AdaCore provides a free (as in beer) compiler, with certain
limitations to avoid shooting themselves in the foot. That's very kind
of them, if it does not fit your needs, choose another one.

> * These are things I have been told by people who have gone through
> the various issues above.
> 
Second hand information...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-10, Lucretia <laguest9000@googlemail.com> wrote:
> On Tuesday, 10 June 2014 13:28:33 UTC+1, Simon Clubley  wrote:
>> (The other reasons include the restricted set of host and target
>> platforms for Ada when compared to C and the fact the nicely
>
> the fact that the FSF version has been crippled on purpose to stop the
> building of certain said targets, you mean?
>

I'm aware of how much trouble you have had trying to get bare metal
ARM and bare metal PIC32 working because I looked at what you had
done a year or two ago. According to your comments and logs at the
time, it all seemed to be very fragile and prone to breaking in
various random ways with each new version of GNAT.

There's also the lack of public versions of Ada (or any Ada version
at all) for various non-mainstream platforms. For example, about a
year ago, I evaluated the state of gcc (including Ada) for VMS in the
public gcc kits. (ACT did a port of gcc to VMS for it's customers).

It didn't take me long to discover that not all the required bits
were there and that I would have a major task ahead of me. I managed
to build a C only cross compiler/binutils running on Linux which
produced VMS executables and was able to successfully compile binutils
binaries which ran native on VMS, but I didn't have any luck with Ada.

[Note: I didn't spend as nearly as much time on this as you have clearly
done as my interest in VMS outside of work has declined over the years
but I spent enough time to get a feeling for the size of the task. I did
post some detailed notes in comp.os.vms if you want to go looking for
them but they were more general gcc/binutils issues and not Ada specific.]

There's also the lack of Ada for microcontroller platforms other than
ARM (ACT supplied) and AVR (ACT/third party supplied). Just think of
all the stuff Farnell sells which doesn't have Ada compiler target
support, but does have C compiler target support. (I mention Farnell
because your website says you are in Leeds.)

>> pre-packaged ACT version of GNAT is licenced under the GPL instead
>> of the GMGPL.)
>
> This is a major problem actually. With GCC C/C++/.Obj-C/etc., someone can
> come along and just write a mobile app and sell it without any fear of being
> sued as you didn't release the source. Not so with ACT's GPL'd GNAT, all
> because they want people to shell out a stupid amount of money for support,
> which people writing mobile apps just cannot afford. The fact that they now
> release all their libs as GPL is just a joke as well; may as well say "we'll
> make sure nobody uses Ada for anything but trains, planes and bombs."
>

Back in the early days of the GNU project (~20 years ago) someone (maybe
RMS ?) suggested the output from the gcc compiler in general might be
subject to the GPL. It didn't take long for _that_ idea to be shot down
and to _never_ be suggested again. :-)

>> For general programming for which C would be used, if you want to get
>> your typical C progammer using something safer than C, I still think
>> my Oberon-14 idea represents the general path to take: create a
>> "safer", not "safe", language with some of the basic Ada concepts
>> transplanted into it and which is easy for a C programmer to learn.
>
> I have thought of something similar. I'll have to try to find your idea and
> take a look.
>

To stop you wasting your time, I only discussed it in comp.lang.ada in
the aftermath of the Heartbleed fiasco although I made some specific
suggestions in c.l.a.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-10, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 10/06/2014 16:43, Brad Moore a écrit :
>> 
>> Is there a list of such libraries that would be of interest? If that is
>> what is stopping people from using Ada, then I would think it wouldn't
>> be too hard to find people willing to work on creating non-GPL versions
>> of such libraries, or to create bindings to other libraries that already
>> exist. At the very least it would be a lot easier than inventing a new
>> language, and then creating versions of those libraries in that new
>> language.
>
> I'd like some examples too. AFAIK, the standard library that comes with
> FSF-Gnat has the famous copyright exception (i.e. they are GMGPL, not
> pure GPL). And other libraries have the copyright chosen by their
> author, as for any language...
>

The one ACT supplied library I used to use was GtkAda which had a GMGPL
style licence until around GTK 2.4 (IIRC) when it was suddenly changed
to pure GPL overnight by ACT.

I made a point _never_ to use anything under the direct control of ACT
after that experience. (For gcc, I use the FSF gcc branch only).

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Pascal Obry]

Le mardi 10 juin 2014 à 20:28 +0000, Simon Clubley a écrit : 
> The one ACT supplied library I used to use was GtkAda which had a GMGPL
> style licence until around GTK 2.4 (IIRC) when it was suddenly changed
> to pure GPL overnight by ACT.

Well you can still create commercial applications using pure GPL. Isn't
that an option for you?

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-10, Pascal Obry <pascal@obry.net> wrote:
> Le mardi 10 juin 2014 à 20:28 +0000, Simon Clubley a écrit : 
>> The one ACT supplied library I used to use was GtkAda which had a GMGPL
>> style licence until around GTK 2.4 (IIRC) when it was suddenly changed
>> to pure GPL overnight by ACT.
>
> Well you can still create commercial applications using pure GPL. Isn't
> that an option for you?
>

The real problem is that when a company pulls a stunt like that you can
never be sure what other things might be waiting around the corner so
you can become reluctant to use any freely available packages that
company might have direct control over.

IIRC, there was quite a bit of anger in comp.lang.ada at the time this
sudden GtkAda licence change was discovered.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-10, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> There's also the lack of Ada for microcontroller platforms other than
> ARM (ACT supplied) and AVR (ACT/third party supplied). Just think of
> all the stuff Farnell sells which doesn't have Ada compiler target
> support, but does have C compiler target support. (I mention Farnell
> because your website says you are in Leeds.)
>

And before I get pulled up for forgetting it :-), there's also Brian's
third party port for the MSP430.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Luke A. Guest]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> And before I get pulled up for forgetting it :-), there's also Brian's
> third party port for the MSP430.

He was one who talked to me about it.

Re: a new language, designed for safety !

[Luke A. Guest]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> The one ACT supplied library I used to use was GtkAda which had a GMGPL
> style licence until around GTK 2.4 (IIRC) when it was suddenly changed
> to pure GPL overnight by ACT.
> 
> I made a point _never_ to use anything under the direct control of ACT
> after that experience. (For gcc, I use the FSF gcc branch only).

Exactly.

I have similar concerns now they are the ones 'controlling' the future is
ASIS, as there's no external agency defining the packages, if someone comes
along and takes that interface spec and uses it, they could well tell them
it's GPL and to change the lib licence. Bad news.

Re: a new language, designed for safety !

[Luke A. Guest]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> I'm aware of how much trouble you have had trying to get bare metal
> ARM and bare metal PIC32 working because I looked at what you had
> done a year or two ago. According to your comments and logs at the
> time, it all seemed to be very fragile and prone to breaking in
> various random ways with each new version of GNAT.

From my experiments, GNAT is the only GCC front end that cannot build for
all of GCC's targets, standalone or with runtime.

> There's also the lack of public versions of Ada (or any Ada version
> at all) for various non-mainstream platforms. For example, about a
> year ago, I evaluated the state of gcc (including Ada) for VMS in the
> public gcc kits. (ACT did a port of gcc to VMS for it's customers).

I don't know if all the bits for VMS are in the FAF version.

> There's also the lack of Ada for microcontroller platforms other than
> ARM (ACT supplied) and AVR (ACT/third party supplied). Just think of
> all the stuff Farnell sells which doesn't have Ada compiler target

I doubt there's enough interest tbh, even though there should be. I can
count the number of people who have contacted me about it on 2 hands.

> support, but does have C compiler target support. (I mention Farnell
> because your website says you are in Leeds.)
 I seriously doubt they would be interested. All these people care about is
C.

> To stop you wasting your time, I only discussed it in comp.lang.ada in
> the aftermath of the Heartbleed fiasco although I made some specific
> suggestions in c.l.a.

Already read it.

Re: a new language, designed for safety !

[Luke A. Guest]

"J-P. Rosen" <rosen@adalog.fr> wrote:

>> platforms, i.e. Android.
> Once again, that's AdaCore; Atego provided another one (TBH: I'm not
> sure what it's state is currently).

This available for download? Didn't think so.


>> leads to the fact that GNAT is developed behind closed doors and
>> anybody wanting to contribute patches, won't see them being included.
> This is FUD. Anybody can contribute patches to FSF, and so does AdaCore.

No it's not, look at the number of outstanding bugs on the FSF site, same
for I accepted patches.

> AdaCore is a commercial company; you can choose a compiler from AdaCore,
> or a compiler from FSF, like for any other 

A tomato is a tomato no matter where you get it from, same for GNAT.

language. Would you argue
> that C is being impaired because Microsoft C is not free?

There are many implementations of C, not true of Ada.

> In addition, AdaCore provides a free (as in beer) compiler, with certain
> limitations to avoid shooting themselves in the foot. That's very kind
> of them, if it does not fit your needs, choose another one.

Like I said, there are loads to choose from.

>> * These are things I have been told by people who have gone through
>> the various issues above.
>> 
> Second hand information...

Doesn't make it wrong information.

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/10/2014 01:22 PM, Simon Clubley wrote:>
 > There's also the lack of Ada for microcontroller platforms other than
 > ARM (ACT supplied) and AVR (ACT/third party supplied). Just think of
 > all the stuff Farnell sells which doesn't have Ada compiler target
 > support, but does have C compiler target support. (I mention Farnell
 > because your website says you are in Leeds.)

If it's targeted by a C compiler then it's targeted by an Ada compiler.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/10/2014 01:28 PM, Simon Clubley wrote:
>
> The one ACT supplied library I used to use was GtkAda which had a GMGPL
> style licence until around GTK 2.4 (IIRC) when it was suddenly changed
> to pure GPL overnight by ACT.
>
> I made a point _never_ to use anything under the direct control of ACT
> after that experience. (For gcc, I use the FSF gcc branch only).

GTKAda from FSF is GMGPL.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: a new language, designed for safety !

[Natasha Kerensikova]

Hello,

On 2014-06-10, Tero Koskinen <tero.koskinen@iki.fi> wrote:
> I would like to have following non-gpl, preferably 100% Ada, libraries
> without GNAT specific dependencies:
> - [...]
> - HTTP client library with SSL (using curl bindings for now)
> - Plain socket library with poll/epoll support

For what it's worth, I'm currently writing bindings for libevent2 (under
ISC licence because that's my default choice).

Wouldn't that cover most of the above? (I think fine socket tuning might
be missing)


Natasha

Re: a new language, designed for safety !

[Pascal Obry]

Le mardi 10 juin 2014 à 21:04 +0000, Simon Clubley a écrit : 
> The real problem is that when a company pulls a stunt like that you can
> never be sure what other things might be waiting around the corner so
> you can become reluctant to use any freely available packages that
> company might have direct control over.

That's strange thinking as GPL is about freedom! So moving to GPL is
going into the right direction to me.

Many commercial devices (televisions, internet boxes, routers...) are
using a Linux kernel or VLC player those days.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-10, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 06/10/2014 01:28 PM, Simon Clubley wrote:
>>
>> The one ACT supplied library I used to use was GtkAda which had a GMGPL
>> style licence until around GTK 2.4 (IIRC) when it was suddenly changed
>> to pure GPL overnight by ACT.
>>
>> I made a point _never_ to use anything under the direct control of ACT
>> after that experience. (For gcc, I use the FSF gcc branch only).
>
> GTKAda from FSF is GMGPL.
>

Do you have a link for the FSF version of GtkAda please as I cannot
find it ? I can only find the ACT version.

Thanks,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-10, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 06/10/2014 01:22 PM, Simon Clubley wrote:>
> > There's also the lack of Ada for microcontroller platforms other than
> > ARM (ACT supplied) and AVR (ACT/third party supplied). Just think of
> > all the stuff Farnell sells which doesn't have Ada compiler target
> > support, but does have C compiler target support. (I mention Farnell
> > because your website says you are in Leeds.)
>
> If it's targeted by a C compiler then it's targeted by an Ada compiler.
>

That doesn't make sense.

Some random examples:

What about the various microcontrollers you can buy which have C
available but not a Ada compiler ?

What about IBM's AS/400 or MVS systems ?

What about a usable version of Ada for the PIC32MX ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Maciej Sobczak]

W dniu wtorek, 10 czerwca 2014 11:36:59 UTC+2 użytkownik Stephen Leake napisał:

> Can anyone comment on why Apple didn't just use Ada?

Because Ada does not have the features that they wanted to have? Like closures, straightforward dictionaries, type inference, string templating, tuples, built-in refcounting for dynamically allocated objects, pattern matching, ...?

Ada is not competing well in this space and the features above are what nowadays developers expect, especially in the mobile and web-oriented market. Also, if you see the rising popularity of Scala and you want to retain (and even attract) developers in the platform, you need to compete at the same level.
If Apple switched to Ada, they'd probably kill the platform overnight - that does not mean Ada is bad, it just means that Apple needed a language in *their* target space and Ada simply does not belong there.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Tue, 10 Jun 2014 22:34:12 +0300, Tero Koskinen wrote:

> 10.6.2014 19:31, Dmitry A. Kazakov wrote:
>> On Tue, 10 Jun 2014 08:33:07 -0700 (PDT), Lucretia wrote:
>> 
>>> On Tuesday, 10 June 2014 15:43:04 UTC+1, Brad Moore  wrote:
>>>
>>>> Is there a list of such libraries that would be of interest?
>>>
>>> If you really need a list, go to AdaCore's libre site, they're all GPL,
>>> and all a problem due to that.
>> 
>> That is not an answer. I am using nothing from that site, except for
>> GtkAda. The company I am working in also uses nothing.
>> 
>> If you have concrete things in mind, I am sure people here will be glad to
>> point you closed source friendly alternatives.
> 
> I would like to have following non-gpl, preferably 100% Ada, libraries
> without GNAT specific dependencies:
> - GUI library

There is not much choice, since the C GUI libraries aren't GM GPL either.  

> - JSON library (well, I have written my own, but it isn't perfect yet)
> - Tiny-YAML library [1]
> - HTTP client library with SSL (using curl bindings for now)

A client?

> - Plain socket library with poll/epoll support

Adasockets? I didn't use it for a long time, however. The last time I
looked at, it had a makefile, which was a non-starter to me. But I think it
is possible to make a decent portable high-level socket library for
Windows/Linux/VxWorks, if there were interest.

> - Some sort of easy interface to execute programs on *nix/Windows
>   and capture the input/output/stderr/exit code[2]

I am using it from GTK+. It does all that under both Windows and Linux,
even capturing output into a text buffer:

http://www.dmitry-kazakov.de/ada/gtkada_contributions.htm#10

The drawback is that you need GTK+ and GtkAda.

> - Server side web framework which does not require the latest
>   GNAT to work (=works with older GNAT releases and other compilers
>   also)

I have a HTTP server implementation. It is based on GNAT.Sockets though,
and does not have any tools (I needed none for embeddable/disk-less servers
where I used it).

http://www.dmitry-kazakov.de/ada/components.htm#HTTP_implementation

If there were interest I could add an adasockets back-end. Provided
adasockets support socket select.

Simon Wright probably has a HTTP server, if I correctly remember.

> - At least semi-decent runtime/peripheral library for ARM Cortex-Mx
>   processors[3]

Oh, yes. As well as a cross compiler. It is a torture to use the native
GNAT. 

> - Interface to sqlite databases (using my own partial bindings atm.)

I have GM GPL SQLite (no C library needed) here

http://www.dmitry-kazakov.de/ada/components.htm#SQLite

> - reStructuredText to HTML formatter

I did HTML output manually.

> - Antlr4 runtime
> 
> For many things bindings to existing C libraries would be fine, but
> usually authors select different licenses for Ada bindings than
> what the original C library has. Like why on earth use plain GPL
> or even GMGPL for bindings if original C library is distributed
> under public domain, MIT, or BSD license?!

Hmm, I thought GM GPL is a least offensive license possible.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Simon Wright]

Luke A. Guest <laguest@archeia.com> writes:

> No it's not, look at the number of outstanding bugs on the FSF site,
> same for I accepted patches.

Not sure about the patches (I know one of mine never got implemented -
to do with the visibility of switches passed to ranlib), but the
outstanding bugs don't get cleared just because they're fixed, someone
has to report that the problem has been solved. Not that AdaCore folk
don't look at new bugs, just that there's no obvious curatorial effort.

Re: a new language, designed for safety !

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Simon Wright probably has a HTTP server, if I correctly remember.

Yes, http://embed-web-srvr.sourceforge.net

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-11, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 10 Jun 2014 22:34:12 +0300, Tero Koskinen wrote:
>> 
>> I would like to have following non-gpl, preferably 100% Ada, libraries
>> without GNAT specific dependencies:
>> - GUI library
>
> There is not much choice, since the C GUI libraries aren't GM GPL either.  
>

The C GTK libraries are LGPL which is pretty much the same thing.

>> - JSON library (well, I have written my own, but it isn't perfect yet)
>> - Tiny-YAML library [1]
>> - HTTP client library with SSL (using curl bindings for now)
>
> A client?
>

There are a large number of reasons to want to issue HTTP/HTTPS requests
directly from within a program and to receive the results directly back
into that same program.

>> - At least semi-decent runtime/peripheral library for ARM Cortex-Mx
>>   processors[3]
>
> Oh, yes. As well as a cross compiler. It is a torture to use the native
> GNAT. 
>

When you talk about native GNAT in this specific case, are you talking
about a native ARM GNAT compiler running on an ARM board under something
like Linux ?

I've just had a look at the ACT libre website because I thought they did
a GPL version of GNAT for ARM Cortex-Mx devices in some form but it looks
like the only microcontroller GPL version is for AVR.

Their ARM version appears to be a paid version only (which was news to me).

>> - Antlr4 runtime
>> 
>> For many things bindings to existing C libraries would be fine, but
>> usually authors select different licenses for Ada bindings than
>> what the original C library has. Like why on earth use plain GPL
>> or even GMGPL for bindings if original C library is distributed
>> under public domain, MIT, or BSD license?!
>
> Hmm, I thought GM GPL is a least offensive license possible.
>

Not the least, but amongst the least. The point about bindings using
a more restrictive licence than the underlying library is well taken.
The example which comes to mind is GTK; the underlying C library uses
the LGPL licence. The ACT Ada bindings now use the GPL licence.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[björn lundin]

Den tisdagen den 10:e juni 2014 kl. 21:34:12 UTC+2 skrev Tero Koskinen:
> I would like to have following non-gpl, preferably 100% Ada, libraries
> without GNAT specific dependencies:
...
> - Some sort of easy interface to execute programs on *nix/Windows
>   and capture the input/output/stderr/exit code[2]
... 
> [2] *nix part is easy, but I have no idea how to do that on Windows :)

in Gnat for win, there's a file adaint.c in 
which there are functions

static int win32_wait (int *status)
static void win32_no_block_spawn (char *command, char *args[], HANDLE *h, int *pid)

which perhaps are helpful in spawning an getting exitcodes,
if combined.

/Björn

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Wed, 11 Jun 2014 12:09:23 +0000 (UTC), Simon Clubley wrote:

> On 2014-06-11, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Tue, 10 Jun 2014 22:34:12 +0300, Tero Koskinen wrote:
>>> - HTTP client library with SSL (using curl bindings for now)
>>
>> A client?
>>
> There are a large number of reasons to want to issue HTTP/HTTPS requests
> directly from within a program and to receive the results directly back
> into that same program.

Maybe, but if not implementing a browser, why sending a pair of strings and
reading few strings back deserves a library?

>>> - At least semi-decent runtime/peripheral library for ARM Cortex-Mx
>>>   processors[3]
>>
>> Oh, yes. As well as a cross compiler. It is a torture to use the native
>> GNAT. 
> 
> When you talk about native GNAT in this specific case, are you talking
> about a native ARM GNAT compiler running on an ARM board under something
> like Linux ?

Yep.

> Their ARM version appears to be a paid version only (which was news to me).

ARM cross hosted on x86 Linux is GNAT Pro. There never was a GPL edition
of.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[björn lundin]

Den onsdagen den 11:e juni 2014 kl. 14:34:44 UTC+2 skrev Dmitry A. Kazakov:
> > There are a large number of reasons to want to issue HTTP/HTTPS requests
> > directly from within a program and to receive the results directly back
> > into that same program.
> 
> Maybe, but if not implementing a browser, why sending a pair of strings and
> reading few strings back deserves a library?

When you communicate with a web-service that uses
JSON over https, it is nice not to have to write
everything from scratch.

Actually, by using AWS.Client and Gnatcoll.JSON,
my pet project became a reality. Without those
libraries/frameworks, I'd still be struggling with python,
and falling into every trap imaginable of a dynamic language.

/Björn

Re: a new language, designed for safety !

[Lucretia]

On Wednesday, 11 June 2014 13:34:44 UTC+1, Dmitry A. Kazakov  wrote:
> On Wed, 11 Jun 2014 12:09:23 +0000 (UTC), Simon Clubley wrote:
> 
> > Their ARM version appears to be a paid version only (which was news to me).
> 
> ARM cross hosted on x86 Linux is GNAT Pro. There never was a GPL edition
> of.

But I built an FSF version. https://github.com/Lucretia/tamp - see the README

Re: a new language, designed for safety !

[G.B.]

On 11.06.14 09:32, Simon Clubley wrote:
> On 2014-06-10, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
>> On 06/10/2014 01:22 PM, Simon Clubley wrote:>
>>> There's also the lack of Ada for microcontroller platforms other than
>>> ARM (ACT supplied) and AVR (ACT/third party supplied). Just think of
>>> all the stuff Farnell sells which doesn't have Ada compiler target
>>> support, but does have C compiler target support. (I mention Farnell
>>> because your website says you are in Leeds.)
>>
>> If it's targeted by a C compiler then it's targeted by an Ada compiler.
>>
>
> That doesn't make sense.

http://www.mapusoft.com/admin/wp-content/uploads/adamagic-datasheet.pdf

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/11/2014 12:32 AM, Simon Clubley wrote:
> On 2014-06-10, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
>>
>> If it's targeted by a C compiler then it's targeted by an Ada compiler.
>
> That doesn't make sense.
>
> Some random examples:
>
> What about the various microcontrollers you can buy which have C
> available but not a Ada compiler ?
>
> What about IBM's AS/400 or MVS systems ?
>
> What about a usable version of Ada for the PIC32MX ?

What about the AdaMagic compiler that uses ANSI C as its intermediate language?

-- 
Jeff Carter
"Nobody expects the Spanish Inquisition!"
Monty Python's Flying Circus
22

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/11/2014 12:29 AM, Simon Clubley wrote:
>
> Do you have a link for the FSF version of GtkAda please as I cannot
> find it ? I can only find the ACT version.

I get mine from the Debian packaging.

-- 
Jeff Carter
"Nobody expects the Spanish Inquisition!"
Monty Python's Flying Circus
22

Re: a new language, designed for safety !

[Peter Chapin]

On 2014-06-11 04:27, Maciej Sobczak wrote:

>> Can anyone comment on why Apple didn't just use Ada?
> 
> Because Ada does not have the features that they wanted to have? Like closures, straightforward dictionaries, type inference, string templating, tuples, built-in refcounting for dynamically allocated objects, pattern matching, ...?
> 
> Ada is not competing well in this space and the features above are what nowadays developers expect, especially in the mobile and web-oriented market. Also, if you see the rising popularity of Scala and you want to retain (and even attract) developers in the platform, you need to compete at the same level.

As someone who enjoys both Ada and Scala I can say that the languages
are quite different in their general "world view." I agree that
closures, pattern matching, and other functional features are rising in
popularity and for good reason. On the other hand that doesn't mean Ada
should adopt them.

I see Ada living in the same universe as C and C++. It's good at low
level, close-to-the machine, systems programming. I tell my students,
"any application where it makes sense to consider C, it also makes sense
to consider Ada."

However, mobile applications live in a different universe, it seems to
me. In that universe a different feature set is probably best. Ada isn't
the ideal language for all programming! So I think it's a good thing
that Apple is trying to create a language that suits their purposes and
that focuses on safety and security. There is room in this world for
such a language.

Peter

Re: a new language, designed for safety !

[Luke A. Guest]

Peter Chapin <PChapin@vtc.vsc.edu> wrote:
> On 2014-06-11 04:27, Maciej Sobczak wrote:

> I see Ada living in the same universe as C and C++. It's good at low
> level, close-to-the machine, systems programming. I tell my students,
> "any application where it makes sense to consider C, it also makes sense
> to consider Ada."
> 
> However, mobile applications live in a different universe, it seems to
> me. In that universe a different feature set is probably best. Ada isn't
> the ideal language for all programming! So I think it's a good thing

Really? There's a ton of apps for ios written in c++, you really think Ada
doesn't belong?

If there was an Ada compiler for ios, would you use it?

Luke

Re: a new language, designed for safety !

[Peter Chapin]

On 2014-06-11 15:52, Luke A. Guest wrote:

>> However, mobile applications live in a different universe, it seems to
>> me. In that universe a different feature set is probably best. Ada isn't
>> the ideal language for all programming! So I think it's a good thing
> 
> Really? There's a ton of apps for ios written in c++, you really think Ada
> doesn't belong?
> 
> If there was an Ada compiler for ios, would you use it?

Probably not. I suppose it would depend on the alternative languages.
I'd use Scala in that domain instead of Ada if it were available.

Peter

Re: a new language, designed for safety !

[Dan'l Miller]

On Wednesday, June 11, 2014 8:39:06 PM UTC-5, Peter Chapin wrote:
> On 2014-06-11 15:52, Luke A. Guest wrote:
>
> > If there was an Ada compiler for ios, would you use it?
> 
> Probably not.

Specifically why not use Ada?  What portion(s) of Ada are detrimental to success on iOS?  Memory management?  Lack of clear mapping of the more-unusual portions of Objective-C runtime feature-set (e.g., reflection; Grand Central Dispatch) onto Ada?

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-11, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 06/11/2014 12:32 AM, Simon Clubley wrote:
>> On 2014-06-10, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
>>>
>>> If it's targeted by a C compiler then it's targeted by an Ada compiler.
>>
>> That doesn't make sense.
>>
>> Some random examples:
>>
>> What about the various microcontrollers you can buy which have C
>> available but not a Ada compiler ?
>>
>> What about IBM's AS/400 or MVS systems ?
>>
>> What about a usable version of Ada for the PIC32MX ?
>
> What about the AdaMagic compiler that uses ANSI C as its intermediate
> language?
>

The AdaMagic compiler is utterly unsuitable here.

In a world where development environments are available for free, you
are not going to persuade people to try Ada by telling them they have
to pay mega dollars/mega pounds for a Ada to C compiler.

When you are doing development in a corporate environment on production
systems, then a paid for solution makes very good sense. When you are
trying to persuade new people to adopt Ada, it does not.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Georg Bauhaus]

On 11/06/14 21:39, Peter Chapin wrote:
> So I think it's a good thing
> that Apple is trying to create a language that suits their purposes and
> that focuses on safety and security.

Swift suits Apple's purposes, Go acts in the same role for Google.
Is that our purpose, too? In what one might think is their market?

Once Apple's (Google's) produce becomes adopted by independent
organizations, then once again these will loose independence.
Controlling language, on behalf of We The People, e.g.,
will be political at best, and ISO can be used as an instrument
of hypocrisy, pushing voluminous "standardization" documents
though ECMA, first. (ISO-Swift, ISO-Go)

A difference to 1974 will be that the

   "minimal number of common, modern, high order
    computer programming languages"

is now equal to the number of big (well, rich) companies in the
computer market. They are in control, irrespective of the merits
and potential compatibilities of their language efforts.

http://archive.adaic.com/pol-hist/history/holwg-93/1.htm#justification

Re: a new language, designed for safety !

[Peter Chapin]

On 2014-06-11 22:46, Dan'l Miller wrote:

>>> If there was an Ada compiler for ios, would you use it?
>>
>> Probably not.
> 
> Specifically why not use Ada?  What portion(s) of Ada are detrimental to success on iOS?  Memory management?  Lack of clear mapping of the more-unusual portions of Objective-C runtime feature-set (e.g., reflection; Grand Central Dispatch) onto Ada?

I don't know much about iOS programming specifically (I have done some
Android programming) but my point is really that I'm not convinced Ada
is an ideal language for high level applications in general. To me it
feels like a low level language, similar in many ways to C, although C++
would probably be a more appropriate comparable.

Consider Ada's arrays. They are fairly primitive and close to the
machine. Compare them with, say, lists in Haskell which are fully
dynamic by default and come endowed with a powerful list comprehension
sublanguage that makes generating and manipulating lists very simple.
Ada can get the job done, of course, but it entails withing various
packages and writing explicit loops, conditional statements, etc.

Ada's design is excellent for a systems language. I much prefer using it
over C (and even C++, although modern C++ is nice too in many ways) in
systems applications. However, for "high level" applications... there
are other languages out there that I think are better.

Peter

Re: a new language, designed for safety !

[Lucretia]

On Thursday, 12 June 2014 12:24:30 UTC+1, Peter Chapin  wrote:
> 
> I don't know much about iOS programming specifically (I have done some
> Android programming) but my point is really that I'm not convinced Ada
> is an ideal language for high level applications in general. To me it

Yeah, nobody's ever written a higher level / UI app in C or C++, have they?

> feels like a low level language, similar in many ways to C, although C++
> would probably be a more appropriate comparable.
> 
> Consider Ada's arrays. They are fairly primitive and close to the
> machine. Compare them with, say, lists in Haskell which are fully

...and C's aren't? Have you done any OpenGL programming in C or C++? That is the definition of machine level arrays, very primitive, yet people do it all the time on both platforms.

> dynamic by default and come endowed with a powerful list comprehension
> sublanguage that makes generating and manipulating lists very simple.
> Ada can get the job done, of course, but it entails withing various
> packages and writing explicit loops, conditional statements, etc.

You still have to do that on other languages as well, fighting with include and library paths, etc.

> Ada's design is excellent for a systems language. I much prefer using it
> over C (and even C++, although modern C++ is nice too in many ways) in
> systems applications. However, for "high level" applications... there
> are other languages out there that I think are better.

Ada just needs a few things to make it better suited to the modern world. Mostly library level stuff. Simple as that.

Luke.

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-11, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 06/11/2014 12:29 AM, Simon Clubley wrote:
>>
>> Do you have a link for the FSF version of GtkAda please as I cannot
>> find it ? I can only find the ACT version.
>
> I get mine from the Debian packaging.
>

I've just had a quick look at this.

The Debian package is pure GPL, not GMGPL.

It is a repackaging of the ACT libre version which is pure GPL.

See https://packages.debian.org/stable/libs/libgtkada2.24.1 and follow
the "Copyright File" link on the right of that page.

That "Copyright File" link states (note the bit about the licence change):

|This package was debianized by Ludovic Brenta <lbrenta@debian.org> on
|Sun, 20 Jul 2003 17:18:06 +0200.
|
|It was downloaded from http://libre.act-europe.fr/GtkAda
|(now http://libre.adacore.com/libre/tools/GtkAda/).
|
|Upstream Authors:
|	Emmanuel Briot <briot@gnat.com>
|	Joel Brobecker <brobecker@gnat.com>
|	Arnaud Charlet <charlet@gnat.com>
|	Nicolas Setton <setton@adacore.com>
|
|Copyright (C) 1998-2000 E. Briot, J. Brobecker and A. Charlet
|Copyright (C) 2000-2011, AdaCore
|
|GtkAda  is free software;  you  can redistribute  it and/or  modify it
|under terms of the GNU General Public License as published by the Free
|Software Foundation; either  version 2, or  (at your option) any later
|version.  GtkAda is  distributed in the  hope that it  will be useful,
|but WITHOUT ANY   WARRANTY;   without even  the implied  warranty   of
|MERCHANTABILITY -- or  FITNESS FOR A PARTICULAR  PURPOSE.
|
|On Debian GNU/Linux systems, the complete text of the GNU General
|Public License can be found in `/usr/share/common-licenses/GPL-2'.
|
|Maintainer's note:
|
|In a previous version of Debian, libgtkada2 2.4.0 was licensed under
|the terms of the GNAT-Modified GNU General Public License (GMGPL).
|This new version is licensed under the terms of the pure GPL.  As a
|consequence, it is no longer legal to distribute proprietary software
|that incorporates this library.  If your program uses GtkAda, and if
|you wish your program to use licensing terms incompatible with the
|GPL, you have three choices:
|
|- distribute your program in source form only, and require your
|  licensees to build it for themselves.  Your sources need not be
|  under GPL, since they are not linked to GtkAda.
|
|- contact AdaCore, the upstream author, at sales@adacore.com, and
|  purchase a GMGPL license for GtkAda.
|
|- do not distribute your program at all.
|
|You may be tempted to retrieve the sources from AdaCore's CVS
|repository.  Be warned that doing so will still grant you a pure GPL
|license, despite the fact that AdaCore have not yet adjusted the
|licensing boilerplate in source files.  In Debian, I have removed the
|"special exception" language only to remove confusion.  It is not I
|who changed the actual license, it is AdaCore.  Contact them at
|libre@adacore.com for any clarification.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[björn lundin]

Den torsdagen den 12:e juni 2014 kl. 13:24:30 UTC+2 skrev Peter Chapin:

> ... but my point is really that I'm not convinced Ada
> is an ideal language for high level applications in general. To me it
> feels like a low level language, similar in many ways to C, although C++
> would probably be a more appropriate comparable.
> 

It is an ideal language when you want to write high level systems,
like Warehouse Management Systems.
You work with Database, transactions to ERP systems like
orders, order lines, pick lines etc.

The concept of body/spec/separates makes it VERY useful in larger project teams.
The type system makes it SO much easier to keep fundamental changes to the system fairly simple. Like introduce another order status somewhere between 'opened' and 'closed' and actually catch the locations in the code that needs to be changed. Or introducing another field in a database table.

The design goal to make the language READABLE is also a great help,
when customer wants tweaking after 10-15 years.

> Consider Ada's arrays. They are fairly primitive and close to the
> machine. 

And simple to use, read and write. A maintainer's dream.

>Compare them with, say, lists in Haskell which are fully
> dynamic by default and come endowed with a powerful list comprehension
> sublanguage that makes generating and manipulating lists very simple.

But usually costing a lot in readability. After a couple of years,
the code is difficult to read/maintain.

 
> Ada can get the job done, of course, but it entails withing various
> packages and writing explicit loops, conditional statements, etc.

Again, a maintainers wet dream. When the original coder left the company 10 years ago, it is nice to understand what he/she did.
 
> Ada's design is excellent for a systems language. I much prefer using it
> over C (and even C++, although modern C++ is nice too in many ways) in
> systems applications. However, for "high level" applications... there
> are other languages out there that I think are better.

Well everyone for his own opinion. Personally, I see NO better
language to implement reliable, maintainable systems.


And If Ada was available for iOS, I would definitively use it

/Björn

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/12/2014 04:48 AM, Simon Clubley wrote:
>
> I've just had a quick look at this.
>
> The Debian package [GTKAda] is pure GPL, not GMGPL.

You're right. Sorry.

-- 
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/12/2014 12:01 AM, Simon Clubley wrote:
>
> The AdaMagic compiler is utterly unsuitable here.
>
> In a world where development environments are available for free, you
> are not going to persuade people to try Ada by telling them they have
> to pay mega dollars/mega pounds for a Ada to C compiler.

I was replying to your statement:

"There's also the lack of Ada for microcontroller platforms other than
ARM (ACT supplied) and AVR (ACT/third party supplied). Just think of
all the stuff Farnell sells which doesn't have Ada compiler target
support, but does have C compiler target support."

No mention of cost. No mention of persuading people to try Ada. The AdaMagic 
compiler is, therefore, an existence proof of that which you claimed did not exist.

If you expressed yourself badly, don't blame me for responding to what you did say.

-- 
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-12, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 06/12/2014 12:01 AM, Simon Clubley wrote:
>>
>> The AdaMagic compiler is utterly unsuitable here.
>>
>> In a world where development environments are available for free, you
>> are not going to persuade people to try Ada by telling them they have
>> to pay mega dollars/mega pounds for a Ada to C compiler.
>
> I was replying to your statement:
>
> "There's also the lack of Ada for microcontroller platforms other than
> ARM (ACT supplied) and AVR (ACT/third party supplied). Just think of
> all the stuff Farnell sells which doesn't have Ada compiler target
> support, but does have C compiler target support."
>
> No mention of cost. No mention of persuading people to try Ada. The AdaMagic 
> compiler is, therefore, an existence proof of that which you claimed did not
> exist.
>
> If you expressed yourself badly, don't blame me for responding to what you
> did say.
>

I will try to assume less contextual knowledge on the part of the reader
in the future. Sorry. :-)

My response also came across as a lot more terse than it normally would
because I wrote it as I was heading out the door. Sorry once again.

While Farnell (and other distributors) sell to the high end market, they
also sell a _lot_ of low cost products to the hobbyist and other users.
The manufacturers of those products generally make sure that the end
user can get access to a C compiler for those products free of charge.

The discussions we have been having recently include the reasons why
we cannot get Ada into the hands of more users and it seems that
embedded systems are _exactly_ the kind of area Ada is strong at.

Ideally, we also need to try to get people to try Ada while they are
still learning or doing hobbyist work and not waiting until the
workplace to try to get them to use Ada.

Unfortunately, given the free availability of the C compilers you are
not going to get people using Ada in those situations if they have to
pay for it.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-12, björn lundin <b.f.lundin@gmail.com> wrote:
> Den torsdagen den 12:e juni 2014 kl. 13:24:30 UTC+2 skrev Peter Chapin:
>
>> Consider Ada's arrays. They are fairly primitive and close to the
>> machine. 
>
> And simple to use, read and write. A maintainer's dream.
>
>>Compare them with, say, lists in Haskell which are fully
>> dynamic by default and come endowed with a powerful list comprehension
>> sublanguage that makes generating and manipulating lists very simple.
>
> But usually costing a lot in readability. After a couple of years,
> the code is difficult to read/maintain.
>

I've sometimes wondered if it would be a good thing to add associative
arrays, including dynamic ones, directly to Ada without having to use
containers.

To make it clear in the code what is going on and in order to try to
avoid the addition of junk keys into the array due to programming
errors, I would require an explicit call to add a new key to the array.
In Ada code, a simple assignment would not be safe enough for me.

'Range would allow you to iterate over the array very cleanly.

Note that it's only the method of referencing array elements here
(keyed versus integer index) that I am talking about. The data type
of the array elements would still be declared in the usual Ada way.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Shark8]

On 10-Jun-14 06:42, Lucretia wrote:
>> >For general programming for which C would be used, if you want to get
>> >your typical C progammer using something safer than C, I still think
>> >my Oberon-14 idea represents the general path to take: create a
>> >"safer", not "safe", language with some of the basic Ada concepts
>> >transplanted into it and which is easy for a C programmer to learn.
>
> I have thought of something similar. I'll have to try to find your idea and take a look.
>

It is essentially having a different 'target'/'low-level assembler' than 
C [for intermediate/bootstrapping]. -- I'm more in favor of using Forth 
for that purpose.

Re: a new language, designed for safety !

[Shark8]

On 10-Jun-14 08:43, Brad Moore wrote:
> Is there a list of such libraries that would be of interest?

I'm looking for an ASN.1 lib -- might have to make my own.
That's so I can implement X.509 (sec. certs.) so that I can implement 
TLS 1.2 (as a replacement for OpenSSL).

Seriously, we missed/are-missing out on a great chance to showcase Ada 
in a spot where it could shine: as a reliable/correct, maintainable, 
secure replacement for OpenSSL.

Re: a new language, designed for safety !

[Shark8]

On 10-Jun-14 16:09, Luke A. Guest wrote:
> I have similar concerns now they are the ones 'controlling' the future is
> ASIS,

I remember you saying something like that.
Is DIANA an acceptable alternative? (Its definition is not w/i the 
purview of AdaCore.)

Re: a new language, designed for safety !

[Luke A. Guest]

Shark8 <OneWingedShark@gmail.com> wrote:
> On 10-Jun-14 16:09, Luke A. Guest wrote:
>> I have similar concerns now they are the ones 'controlling' the future is
>> ASIS,
> 
> I remember you saying something like that.
> Is DIANA an acceptable alternative? (Its definition is not w/i the purview of AdaCore.)

No, DIANA was an attempt to standardise on a compiler intermediate
representation (IR) for Ada compilers. It's too old, dated and there are
better IR's now.

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-12, Shark8 <OneWingedShark@gmail.com> wrote:
> On 10-Jun-14 06:42, Lucretia wrote:
>>> >For general programming for which C would be used, if you want to get
>>> >your typical C progammer using something safer than C, I still think
>>> >my Oberon-14 idea represents the general path to take: create a
>>> >"safer", not "safe", language with some of the basic Ada concepts
>>> >transplanted into it and which is easy for a C programmer to learn.
>>
>> I have thought of something similar. I'll have to try to find your idea and take a look.
>>
>
> It is essentially having a different 'target'/'low-level assembler' than 
> C [for intermediate/bootstrapping]. -- I'm more in favor of using Forth 
> for that purpose.

The idea behind Oberon-14 is to replace the language used (C) for
writing common widely used libraries and other utilities with a
language which is safer and easily learnable by a typical C programmer,

IMHO, Forth is far too alien a language for your typical C programmer. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[J-P. Rosen]

Le 12/06/2014 23:40, Simon Clubley a écrit :
> Ideally, we also need to try to get people to try Ada while they are
> still learning or doing hobbyist work and not waiting until the
> workplace to try to get them to use Ada.

Isn't Gnat GPL perfect for those people?

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: a new language, designed for safety !

[gvdschoot]

On Friday, June 13, 2014 6:28:41 AM UTC+2, Simon Clubley wrote:
> On 2014-06-12, Shark8 wrote:
> 
> > On 10-Jun-14 06:42, Lucretia wrote:
> 
> >>> >For general programming for which C would be used, if you want to get
> 
> >>> >your typical C progammer using something safer than C, I still think
> 
> >>> >my Oberon-14 idea represents the general path to take: create a
> 
> >>> >"safer", not "safe", language with some of the basic Ada concepts
> 
> >>> >transplanted into it and which is easy for a C programmer to learn.
> 
> >>
> 
> >> I have thought of something similar. I'll have to try to find your idea and take a look.
> 
> >>
> 
> >
> 
> > It is essentially having a different 'target'/'low-level assembler' than 
> 
> > C [for intermediate/bootstrapping]. -- I'm more in favor of using Forth 
> 
> > for that purpose.
> 
> 
> 
> The idea behind Oberon-14 is to replace the language used (C) for
> 
> writing common widely used libraries and other utilities with a
> 
> language which is safer and easily learnable by a typical C programmer,
> 
> 
> 
> IMHO, Forth is far too alien a language for your typical C programmer. :-)
> 
> 
> 
> Simon.
> 
> 
> 
> -- 
> 
> Simon Clubley
> 
> Microsoft: Bringing you 1980s technology to a 21st century world

The thing is: The languages with more options will win. You see that with the Rust vs Go people. Go is a language that is close to Oberon-14, with very well thought simplicity. Rust on the other hand is *the* C++ replacement and it has all the features that makes code hard to understand. But because of all these features it attracts the developers of today. Non-determinism is a very good thing IMO. Reasonability results in good code that is easy to maintain. But we don't live in that world anymore.

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Thu, 12 Jun 2014 22:12:55 +0000 (UTC), Simon Clubley wrote:

> On 2014-06-12, björn lundin <b.f.lundin@gmail.com> wrote:
>> Den torsdagen den 12:e juni 2014 kl. 13:24:30 UTC+2 skrev Peter Chapin:
>>
>>> Consider Ada's arrays. They are fairly primitive and close to the
>>> machine. 
>>
>> And simple to use, read and write. A maintainer's dream.
>>
>>>Compare them with, say, lists in Haskell which are fully
>>> dynamic by default and come endowed with a powerful list comprehension
>>> sublanguage that makes generating and manipulating lists very simple.
>>
>> But usually costing a lot in readability. After a couple of years,
>> the code is difficult to read/maintain.
> 
> I've sometimes wondered if it would be a good thing to add associative
> arrays, including dynamic ones, directly to Ada without having to use
> containers.

No.

1. From the language design POV, everything possible must be moved out the
language into the library. If Ada were a better language, array could be a
library container. If Ada were a worse language containers must have been
implemented at the language level.

2. Associative arrays are made by their non-functional requirements. The
implementations hugely differ if task-safety, persistence, search/index
heuristics required/available.
 
> 'Range would allow you to iterate over the array very cleanly.

Range should have been a proper type. A'Range should have been a primitive
array interface operation.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-13, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 12/06/2014 23:40, Simon Clubley a écrit :
>> Ideally, we also need to try to get people to try Ada while they are
>> still learning or doing hobbyist work and not waiting until the
>> workplace to try to get them to use Ada.
>
> Isn't Gnat GPL perfect for those people?
>

The problem is you need a cross compiler to be able to target bare metal
embedded systems and the only bare metal target available in the GNAT GPL
range is for the AVR.

There's no GNAT GPL cross compiler support for any other platforms/MCUs
including the _very_ popular ARM Cortex-M{0,3,4} MCUs. There are however
freely available C compilers for all these other MCUs (and in addition
those C compilers don't have any restrictions on what you can do with
the binaries you generate with them.)

So the reality is that most people just pick up the C cross compiler for
the MCU in question and use that for their projects.

Simon.

PS: Luke/Brian: do you want to take this opportunity to report on the
state of play and functionality of your work on your ports for ARM,
PIC32MX and MSP430 ?

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Wright]

gvdschoot@gmail.com writes:

> The thing is: The languages with more options will win. You see that
> with the Rust vs Go people. Go is a language that is close to
> Oberon-14, with very well thought simplicity. Rust on the other hand
> is *the* C++ replacement and it has all the features that makes code
> hard to understand. But because of all these features it attracts the
> developers of today. Non-determinism is a very good thing
> IMO. Reasonability results in good code that is easy to maintain. But
> we don't live in that world anymore.

I _hope_ you're being sarcastic.

Re: a new language, designed for safety !

[gvdschoot]

On Friday, June 13, 2014 3:16:38 PM UTC+2, Simon Wright wrote:
> gvds..@gmail.com writes:
> 
> 
> 
> > The thing is: The languages with more options will win. You see that
> 
> > with the Rust vs Go people. Go is a language that is close to
> 
> > Oberon-14, with very well thought simplicity. Rust on the other hand
> 
> > is *the* C++ replacement and it has all the features that makes code
> 
> > hard to understand. But because of all these features it attracts the
> 
> > developers of today. Non-determinism is a very good thing
> 
> > IMO. Reasonability results in good code that is easy to maintain. But
> 
> > we don't live in that world anymore.
> 
> 
> 
> I _hope_ you're being sarcastic.

Why?

Re: a new language, designed for safety !

[Lucretia]

On Friday, 13 June 2014 13:03:28 UTC+1, Simon Clubley  wrote:

> There's no GNAT GPL cross compiler support for any other platforms/MCUs
> including the _very_ popular ARM Cortex-M{0,3,4} MCUs. There are however
> freely available C compilers for all these other MCUs (and in addition
> those C compilers don't have any restrictions on what you can do with
> the binaries you generate with them.)
> 
> So the reality is that most people just pick up the C cross compiler for
> the MCU in question and use that for their projects.
> 
> Simon.
> 
> PS: Luke/Brian: do you want to take this opportunity to report on the
> state of play and functionality of your work on your ports for ARM,
> PIC32MX and MSP430 ?

I have built arm-none-eabi-*, mips-elf-*, msp430-elf-*, x86_64-elf-* cross tools using a small configure patch which allows me to still build the cross tools, they do not install any RTS, you have to provide this (right now). I have not touched any runtime support for ages and my scripts are way out of date.

My last tool versions are:

$ ~/opt/tinyada/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/laguest/opt/tinyada/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/laguest/opt/tinyada/libexec/gcc/arm-none-eabi/4.9.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../../../source/gcc-git-ro/configure --prefix=/home/laguest/opt/tinyada --target=arm-none-eabi --enable-interwork --enable-multilib --without-headers --disable-nls --disable-shared --disable-threads --disable-lto --with-gnu-as --with-gnu-ld --enable-languages=c,ada --enable-cross-gnattools --disable-libssp --disable-cloog-version-check --disable-isl-version-check --with-gmp=/home/laguest/opt/tinyada --with-mpfr=/home/laguest/opt/tinyada --with-mpc=/home/laguest/opt/tinyada --with-isl=/home/laguest/opt/tinyada --with-cloog=/home/laguest/opt/tinyada
Thread model: single
gcc version 4.9.0 20140122 (experimental) (GCC) 

$ ~/opt/tinyada/bin/mips-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/home/laguest/opt/tinyada/bin/mips-elf-gcc
COLLECT_LTO_WRAPPER=/home/laguest/opt/tinyada/libexec/gcc/mips-elf/4.9.0/lto-wrapper
Target: mips-elf
Configured with: ../../../source/gcc-git-ro/configure --prefix=/home/laguest/opt/tinyada --target=mips-elf --enable-multilib --without-headers --disable-nls --disable-shared --disable-threads --disable-lto --with-gnu-as --with-gnu-ld --enable-languages=c,ada --enable-cross-gnattools --with-float=soft --disable-libssp --disable-cloog-version-check --disable-isl-version-check --with-gmp=/home/laguest/opt/tinyada --with-mpfr=/home/laguest/opt/tinyada --with-mpc=/home/laguest/opt/tinyada --with-isl=/home/laguest/opt/tinyada --with-cloog=/home/laguest/opt/tinyada
Thread model: single
gcc version 4.9.0 20140122 (experimental) (GCC)

$ ~/opt/tinyada/bin/msp430-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/home/laguest/opt/tinyada/bin/msp430-elf-gcc
COLLECT_LTO_WRAPPER=/home/laguest/opt/tinyada/libexec/gcc/msp430-elf/4.9.0/lto-wrapper
Target: msp430-elf
Configured with: ../../../source/gcc-git-ro/configure --prefix=/home/laguest/opt/tinyada --target=msp430-elf --enable-multilib --without-headers --disable-nls --disable-shared --disable-threads --disable-lto --with-gnu-as --with-gnu-ld --enable-languages=c,ada --enable-cross-gnattools --disable-libssp --disable-cloog-version-check --disable-isl-version-check --with-gmp=/home/laguest/opt/tinyada --with-mpfr=/home/laguest/opt/tinyada --with-mpc=/home/laguest/opt/tinyada --with-isl=/home/laguest/opt/tinyada --with-cloog=/home/laguest/opt/tinyada
Thread model: single
gcc version 4.9.0 20140122 (experimental) (GCC) 

$ ~/opt/tinyada/bin/x86_64-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/home/laguest/opt/tinyada/bin/x86_64-elf-gcc
COLLECT_LTO_WRAPPER=/home/laguest/opt/tinyada/libexec/gcc/x86_64-elf/4.9.0/lto-wrapper
Target: x86_64-elf
Configured with: ../../../source/gcc-git-ro/configure --prefix=/home/laguest/opt/tinyada --target=x86_64-elf --enable-multilib --without-headers --disable-nls --disable-shared --disable-threads --disable-lto --with-gnu-as --with-gnu-ld --enable-languages=c,ada --enable-cross-gnattools --disable-libssp --disable-cloog-version-check --disable-isl-version-check --with-gmp=/home/laguest/opt/tinyada --with-mpfr=/home/laguest/opt/tinyada --with-mpc=/home/laguest/opt/tinyada --with-isl=/home/laguest/opt/tinyada --with-cloog=/home/laguest/opt/tinyada
Thread model: single
gcc version 4.9.0 20140122 (experimental) (GCC) 

Running any of the *-gnat* tools gives:

$ ~/opt/tinyada/bin/arm-none-eabi-gnat
fatal error, run-time library not installed correctly
cannot locate file system.ads

raised TYPES.UNRECOVERABLE_ERROR : targparm.adb:180

due to no runtime installed.

These compilers have been untested by me also really. The only one tested was the host one I built.

There is no reason why any other backend for gcc should not work either, including AVR, from the same source. i.e. no more hacks that break the build.

If anyone from Farnell or similar want to pay me a shedload of cash to build them some toolchains or set one up for them, let me know :D

Luke.

Re: a new language, designed for safety !

[Shark8]

On 13-Jun-14 08:13, gvdschoot@gmail.com wrote:
> On Friday, June 13, 2014 3:16:38 PM UTC+2, Simon Wright wrote:
>> gvds..@gmail.com writes:
>>> IMO. Reasonability results in good code that is easy to maintain. But
>>> we don't live in that world anymore.
>>
>> I _hope_ you're being sarcastic.
>
> Why?
>

Probably because of the above.

Re: a new language, designed for safety !

[Shark8]

On 13-Jun-14 02:36, Dmitry A. Kazakov wrote:
> Range should have been a proper type.

That would have been nice.

> A'Range should have been a primitive
> array interface operation.

Doesn't its status as a attribute, automatically accessible to any 
array-type, put it in a similar category? (IOW, what's wrong with it 
being an attribute?)

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Fri, 13 Jun 2014 09:55:52 -0600, Shark8 wrote:

> On 13-Jun-14 02:36, Dmitry A. Kazakov wrote:
>> Range should have been a proper type.
> 
> That would have been nice.
> 
>> A'Range should have been a primitive
>> array interface operation.
> 
> Doesn't its status as a attribute, automatically accessible to any 
> array-type, put it in a similar category? (IOW, what's wrong with it 
> being an attribute?)

You cannot override and re-implement it:

   type Ordered_Container is ... and What?;
   overriding -- What interface?
       function Range (X : Ordered_Container) return Which type?

Technically primitive operations could be treated as attributes the way
they are as "record members":

   type T is tagged ...;
   function Foo (X : T) return Bar;

X.Foo is legal, so make X'Foo legal as well.

From the language design POV all different syntaxes of subprogram call must
be treated uniformly, which includes indexing, aggregates, attributes,
members, prefix, postfix, infix, assignment sugars. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-13, Lucretia <laguest9000@googlemail.com> wrote:
> On Friday, 13 June 2014 13:03:28 UTC+1, Simon Clubley  wrote:
>> 
>> PS: Luke/Brian: do you want to take this opportunity to report on the
>> state of play and functionality of your work on your ports for ARM,
>> PIC32MX and MSP430 ?
>
> I have built arm-none-eabi-*, mips-elf-*, msp430-elf-*, x86_64-elf-* cross
> tools using a small configure patch which allows me to still build the cross
> tools, they do not install any RTS, you have to provide this (right now). I
> have not touched any runtime support for ages and my scripts are way out of
> date.
>
> My last tool versions are:
>

[snip]

Thanks for the detailed configuration options Luke.

>
> If anyone from Farnell or similar want to pay me a shedload of cash to build
> them some toolchains or set one up for them, let me know :D
>

Actually I was just using Farnell's product range as an example of the
wide range of products which you can easily run code written in C on but
cannot either easily or outright not at all run code written in Ada on.

I also doubt they would be interested in promoting Ada...

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-13, gvdschoot@gmail.com <gvdschoot@gmail.com> wrote:
> On Friday, June 13, 2014 3:16:38 PM UTC+2, Simon Wright wrote:
>> gvds..@gmail.com writes:
>> 
>> > The thing is: The languages with more options will win. You see that
>> > with the Rust vs Go people. Go is a language that is close to
>> > Oberon-14, with very well thought simplicity. Rust on the other hand
>> > is *the* C++ replacement and it has all the features that makes code
>> > hard to understand. But because of all these features it attracts the
>> > developers of today. Non-determinism is a very good thing
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> > IMO. Reasonability results in good code that is easy to maintain. But
     ^^^^
>> > we don't live in that world anymore.
>> 
>> I _hope_ you're being sarcastic.
>
> Why?

I suspect Simon's reacting to the statement about non-determinism I've
underlined. :-)

(Another) Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Wright]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2014-06-13, gvdschoot@gmail.com <gvdschoot@gmail.com> wrote:
>> On Friday, June 13, 2014 3:16:38 PM UTC+2, Simon Wright wrote:
>>> gvds..@gmail.com writes:
>>> 
>>> > The thing is: The languages with more options will win. You see that
>>> > with the Rust vs Go people. Go is a language that is close to
>>> > Oberon-14, with very well thought simplicity. Rust on the other hand
>>> > is *the* C++ replacement and it has all the features that makes code
>>> > hard to understand. But because of all these features it attracts the
>>> > developers of today. Non-determinism is a very good thing
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> 
>>> > IMO. Reasonability results in good code that is easy to maintain. But
>      ^^^^
>>> > we don't live in that world anymore.
>>> 
>>> I _hope_ you're being sarcastic.
>>
>> Why?
>
> I suspect Simon's reacting to the statement about non-determinism I've
> underlined. :-)

Yes, also Shark8's point.

You really don't want your car being driven, your medications dispensed,
or your finances managed by unpredictable bad code that's difficult to
maintain.

Re: a new language, designed for safety !

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> 1. From the language design POV, everything possible must be moved out the
> language into the library. If Ada were a better language, array could be a
> library container. If Ada were a worse language containers must have been
> implemented at the language level.

I agree.  In Eiffel, "array" doesn't have any special built-in
syntax/semantics.  It's just something declared in the predefined
library.  In general, putting functionality in the predefined
library greatly simplifies a language.

But I think what Simon wants is convenient syntax for dealing with
associative arrays, and that's reasonable.  But in a better language,
that wouldn't require associative arrays to be built in.

By the way, I don't much like the term "associative array".  To me,
"array" implies random access (i.e. roughly constant-time component
access).  I'd prefer "map" or "mapping", where "array" is a kind of
mapping, and "hashed map" is another kind.

> Range should have been a proper type. A'Range should have been a primitive
> array interface operation.

Yes, that's another example of the same language design principle.
There ought to be a way to write procedure Do_Something, such that

    Do_Something(Some_Array'Range);

makes sense.  Except it might as well be 

    Do_Something(Some_Array.Range);

or perhaps

    Do_Something(Range(Some_Array));

- Bob

Re: a new language, designed for safety !

[Brian Drummond]

On Fri, 13 Jun 2014 12:03:28 +0000, Simon Clubley wrote:

> On 2014-06-13, J-P. Rosen <rosen@adalog.fr> wrote:
>> Le 12/06/2014 23:40, Simon Clubley a écrit :
>>> Ideally, we also need to try to get people to try Ada while they are
>>> still learning or doing hobbyist work and not waiting until the
>>> workplace to try to get them to use Ada.

> PS: Luke/Brian: do you want to take this opportunity to report on the
> state of play and functionality of your work on your ports for ARM,
> PIC32MX and MSP430 ?

There's not much to say about the MSP430 compiler. It's had a few hundred 
downloads and practically no feedback (good or bad!) from anybody using 
it. So I may be its only user for all that I know.

It's based on Peter Bigot's "mspgcc" MSP430 backend for gcc4.7, which I 
think is very good indeed. 

The RTS is based on (stolen from?) the AVR-Ada project and works as far 
as I have tried it (including limited support for exceptions, modulo 
tickets http://sourceforge.net/p/msp430ada/tickets/2/ and http://
sourceforge.net/p/msp430ada/tickets/3/ ) with very few changes. 

So far so good...

When the MSP430 became an officially supported target in gcc4.9 I tried 
building gcc4.9 with Ada support, and found that (apart from the 
officially supported newlib being HUGE compared to the msp430-libc) it 
generated much (about 30%) larger code than "mspgcc". Over half the bloat 
came from one code generation bug (verified by one of the maintainers) 
which I promised to file. 

That was in March, but life has intervened since then to the extent I 
haven't even filed the bug yet, let alone looked into the rest of the 
code bloat.

So it may be some time before any decent updates to this project.

- Brian

Re: a new language, designed for safety !

[Georg Bauhaus]

On 13/06/14 22:57, Robert A Duff wrote:
> Yes, that's another example of the same language design principle.
> There ought to be a way to write procedure Do_Something, such that
>
>      Do_Something(Some_Array'Range);
>
> makes sense.  Except it might as well be
>
>      Do_Something(Some_Array.Range);
>
> or perhaps
>
>      Do_Something(Range(Some_Array));

Doesn't this one-type based approach limit the "forall" access to
the data to just one way? That is, why should arrays and *Range be
tied in the array type's definition?

   Syntax_for_Connect
     (Data => Some_Array,
      Access => Some_Iterator,
      Process_Item => Do_Something);

That still leaves unconsidered the case of picking pairs, e.g. Reduce.

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-13, Brian Drummond <brian3@shapes.demon.co.uk> wrote:
> On Fri, 13 Jun 2014 12:03:28 +0000, Simon Clubley wrote:
>> PS: Luke/Brian: do you want to take this opportunity to report on the
>> state of play and functionality of your work on your ports for ARM,
>> PIC32MX and MSP430 ?
>
> There's not much to say about the MSP430 compiler. It's had a few hundred 
> downloads and practically no feedback (good or bad!) from anybody using 
> it. So I may be its only user for all that I know.
>

Thanks for the feedback. I'll admit I've not yet used the MSP 430
because when I build my own circuits I use PDIP packaged MCUs and the
MSP 430 PDIP range been lacking when compared to other PDIP MCUs.

That's a pity because it looks like an elegant architecture.

> It's based on Peter Bigot's "mspgcc" MSP430 backend for gcc4.7, which I 
> think is very good indeed. 
>
> The RTS is based on (stolen from?) the AVR-Ada project and works as far 
> as I have tried it (including limited support for exceptions, modulo 
> tickets http://sourceforge.net/p/msp430ada/tickets/2/ and http://
> sourceforge.net/p/msp430ada/tickets/3/ ) with very few changes. 
>
> So far so good...
>
> When the MSP430 became an officially supported target in gcc4.9 I tried 
> building gcc4.9 with Ada support, and found that (apart from the 
> officially supported newlib being HUGE compared to the msp430-libc) it 
> generated much (about 30%) larger code than "mspgcc". Over half the bloat 
> came from one code generation bug (verified by one of the maintainers) 
> which I promised to file. 
>

Yes, newlib _is_ rather big isn't it ? :-)

Try picking a target with lots of multilib options and watch how much
disk space the newlib build takes up...

> That was in March, but life has intervened since then to the extent I 
> haven't even filed the bug yet, let alone looked into the rest of the 
> code bloat.
>

Yes, unfortunately, real life happens to all of us. :-)

Thanks for the status report.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-13, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> 1. From the language design POV, everything possible must be moved out the
>> language into the library. If Ada were a better language, array could be a
>> library container. If Ada were a worse language containers must have been
>> implemented at the language level.
>
> I agree.  In Eiffel, "array" doesn't have any special built-in
> syntax/semantics.  It's just something declared in the predefined
> library.  In general, putting functionality in the predefined
> library greatly simplifies a language.
>

Thanks for the observation; it's been a _long_ time since I last looked
at Eiffel. I think perhaps another visit might be in order.

> But I think what Simon wants is convenient syntax for dealing with
> associative arrays, and that's reasonable.  But in a better language,
> that wouldn't require associative arrays to be built in.
>

Yes, that's what I am really after.

> By the way, I don't much like the term "associative array".  To me,
> "array" implies random access (i.e. roughly constant-time component
> access).  I'd prefer "map" or "mapping", where "array" is a kind of
> mapping, and "hashed map" is another kind.
>

I see your point (and Dmitry's argument above is interesting as well.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Maciej Sobczak]

W dniu piątek, 13 czerwca 2014 10:36:49 UTC+2 użytkownik Dmitry A. Kazakov napisał:

> 1. From the language design POV, everything possible must be moved out the
> language into the library.

What if we treat the standard library as part of the language? Anyway, the border is fuzzy, as there are things at the library level that require dedicated language magic to work.

> If Ada were a better language, array could be a
> library container.

Assembly language fits that ideal, right?

> If Ada were a worse language containers must have been
> implemented at the language level.

This is an extremist view and quite unfounded.

Let try: dynamic memory. Ada has a built-in operator (new) for dynamic allocation of objects. The C programming language move the dynamic allocation to the library (malloc and friends). How would you compare these two approaches in terms of the language being better or worse?
If you are fine with the "new" operation at the language level, why not dictionaries?

I don't see any objective rules here, only subjective opinions.

> 2. Associative arrays are made by their non-functional requirements. The
> implementations hugely differ if task-safety, persistence, search/index
> heuristics required/available.

Oh, dynamic memory is the same in this aspect. Should it be in the language or in the library?

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: a new language, designed for safety !

[Tero Koskinen]

14.6.2014 23:41, Simon Clubley wrote:
> On 2014-06-13, Brian Drummond <brian3@shapes.demon.co.uk> wrote:
>> On Fri, 13 Jun 2014 12:03:28 +0000, Simon Clubley wrote:
>>> PS: Luke/Brian: do you want to take this opportunity to report on the
>>> state of play and functionality of your work on your ports for ARM,
>>> PIC32MX and MSP430 ?
>>
>> There's not much to say about the MSP430 compiler. It's had a few hundred 
>> downloads and practically no feedback (good or bad!) from anybody using 
>> it. So I may be its only user for all that I know.
>>
> 
> Thanks for the feedback. I'll admit I've not yet used the MSP 430
> because when I build my own circuits I use PDIP packaged MCUs and the
> MSP 430 PDIP range been lacking when compared to other PDIP MCUs.

Olimex sells MSP430 header boards, which are basically just
DIP adapters (+crystal) for MSP430 MCUs. Of course, in some cases
real PDIP packaged MCU is better, but I find those boards
quite handy. (For now, I have played only with MSP430 assembler,
I haven't had time to test MSP430-Ada much.)

https://www.olimex.com/Products/MSP430/Header/

Yours,
 Tero

Re: a new language, designed for safety !

[Tero Koskinen]

13.6.2014 16:16, Simon Wright wrote:
> gvdschoot@gmail.com writes:
> 
>> The thing is: The languages with more options will win. You see that
>> with the Rust vs Go people. Go is a language that is close to
>> Oberon-14, with very well thought simplicity. Rust on the other hand
>> is *the* C++ replacement and it has all the features that makes code
>> hard to understand. But because of all these features it attracts the
>> developers of today. Non-determinism is a very good thing
>> IMO. Reasonability results in good code that is easy to maintain. But
>> we don't live in that world anymore.
> 
> I _hope_ you're being sarcastic.
> 

This is valid Rust code [1]:
pub fn inner<'a>(&'a mut self) -> &'a mut R
{
   &mut self.h.r
}

Yours,
 Tero

[1] https://twitter.com/damienmiller/status/476207923702423552

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Sat, 14 Jun 2014 14:05:17 -0700 (PDT), Maciej Sobczak wrote:

> W dniu piątek, 13 czerwca 2014 10:36:49 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> 
>> 1. From the language design POV, everything possible must be moved out the
>> language into the library.
> 
> What if we treat the standard library as part of the language?

It would be self-contradictory. A library is defined in the language terms,
it cannot be a part of itself.

> Anyway, the
> border is fuzzy, as there are things at the library level that require
> dedicated language magic to work.

You mean a special treatment of the same language construct when it appears
in the standard library?

>> If Ada were a better language, array could be a
>> library container.
> 
> Assembly language fits that ideal, right?

No it does not. Assembly languages do not have containers. It is possible
to write a program in assembly language that would expose the same
functionality as a program in a higher-level language with containers. That
does not make assembly language having containers. Compare: * and []
operators do not make C having arrays.

>> If Ada were a worse language containers must have been
>> implemented at the language level.
> 
> This is an extremist view and quite unfounded.
> 
> Let try: dynamic memory. Ada has a built-in operator (new) for dynamic
> allocation of objects. The C programming language move the dynamic
> allocation to the library (malloc and friends). How would you compare
> these two approaches in terms of the language being better or worse?

Operator new was a mistake, excusable for early 80's. It is especially
obvious since deallocator is not an operator. BTW, assignment operator was
a mistake too.

There existed reasons for both decisions and others (like stream I/O
attributes), because making these proper subprograms would require at lot
of work on the type system. Which was not done then, and is not complete
now.

>> 2. Associative arrays are made by their non-functional requirements. The
>> implementations hugely differ if task-safety, persistence, search/index
>> heuristics required/available.
> 
> Oh, dynamic memory is the same in this aspect. Should it be in the
> language or in the library?

In the library. Ada 95 introduced storage pools for exactly this purpose.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[gvdschoot]

On Sunday, June 15, 2014 8:33:44 AM UTC+2, Tero Koskinen wrote:
> 13.6.2014 16:16, Simon Wright wrote:
> 
> > gvdschoot@gmail.com writes:
> 
> > 
> 
> >> The thing is: The languages with more options will win. You see that
> 
> >> with the Rust vs Go people. Go is a language that is close to
> 
> >> Oberon-14, with very well thought simplicity. Rust on the other hand
> 
> >> is *the* C++ replacement and it has all the features that makes code
> 
> >> hard to understand. But because of all these features it attracts the
> 
> >> developers of today. Non-determinism is a very good thing
> 
> >> IMO. Reasonability results in good code that is easy to maintain. But
> 
> >> we don't live in that world anymore.
> 
> > 
> 
> > I _hope_ you're being sarcastic.
> 
> > 
> 
> 
> 
> This is valid Rust code [1]:
> 
> pub fn inner<'a>(&'a mut self) -> &'a mut R
> 
> {
> 
>    &mut self.h.r
> 
> }
> 
> 
> 
> Yours,
> 
>  Tero
> 
> 
> 
> [1] https://twitter.com/damienmiller/status/476207923702423552

On reddit there was a discussion about the GNU coreutils in platform independent Rust code[1] and here the code itself on github[2]. This is how it looks like in Go[3]. I mean, just look at the code. I am sorry to say this, but in the case of Rust I see C++ mistakes being repeated. To me language syntax is very important. Readability, simplicity and reasonability should be paramount. 


<i>"Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?"</i>

        -- Edsger W. Dijkstra


[1] http://www.reddit.com/r/programming/comments/27yccu/crossplatform_rust_rewrite_of_the_gnu_coreutils/
[2] https://github.com/uutils/coreutils
[3] https://github.com/aisola/go-coreutils

Re: a new language, designed for safety !

[gvdschoot]

Here is the quote how it should be:


Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?

         -- Edsger W. Dijkstra

Re: a new language, designed for safety !

[Nasser M. Abbasi]

speaking of safe languages, I just saw this trying to update
my viedeplan plugin for firefox:

http://www.videolan.org/security/sa1302.html

"Security Advisory 1302
When parsing a specially crafted ASF movie,
a buffer overflow might occur.

Impact
If successful, a malicious third party could
trigger an invalid memory access"

"This issue is addressed in VLC media player 2.0.x
source code repository by replacing a macro with a
static inline and improved bounds checking."

Notice: "improved bounds checking", WOw! So there
is still a chance the bounds checking might fail?

They should use Ada then!

--Nasser

Re: a new language, designed for safety !

[Georg Bauhaus]

On 15/06/14 08:52, Dmitry A. Kazakov wrote:
>> >Oh, dynamic memory is the same in this aspect. Should it be in the
>> >language or in the library?
> In the library. Ada 95 introduced storage pools for exactly this purpose.

But moving (backing) operators to (by) the library should not entail
abandoning special  syntax, I would hope?

Otherwise, libraries will offer nothing but a bag of names (of
types and their operations, say), blurring distinctions that
facilitate expressing "typical patterns" of program structure,
discernably.

Imagine a programmer wishing to express a typical pattern such as

   "Find A in B!"

And imagine a language framework for integrating this pattern with
other language features:

* the first A in B
* the number of A in B
* all A in B
* while there is A in B ...
* is there A in B such that ...

All of these cases should not be part of differently named procedures,
or depend on optional presence of differently named parameters. The
pattern is "generic". Instead, all use cases might be inferred from
context, as is done by the Icon programming language, or, to some
extent, in Python, and in Ada's new loop syntax, if one twists the
argument a little. (Or, in GNAT's Spitbol patterns, taking
backtracking into account.)

Can we have these "program patterns" via syntax and operators?
Even when a compiler needs to make sure that a library based
"interpretation" is consistent with the Ada LRM?

Operators in (syntactical) context will add readability because
the pattern is clear, not because one knows some names.

Just names would result in only trivial readability. A programmer
would need to have received special training in names (vocabulary)
since the meaning of those names for special program patterns is
hidden behind non-special words, they would not be obvious.(*)

__
(*) "Just names" can create a costly mess. The plethora of operations
on strings that involve {index, indexOf, find, substr, substring, ...}
demonstrates, their meanings and arguments being sometimes alike,
sometimes different, and per language. The Javascript language has both
substr *and* substring. They differ.

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Sun, 15 Jun 2014 12:04:26 +0200, Georg Bauhaus wrote:

> On 15/06/14 08:52, Dmitry A. Kazakov wrote:
>>> >Oh, dynamic memory is the same in this aspect. Should it be in the
>>> >language or in the library?
>> In the library. Ada 95 introduced storage pools for exactly this purpose.
> 
> But moving (backing) operators to (by) the library should not entail
> abandoning special  syntax, I would hope?

Another language design principle reads: any operator shall be
implementable by a user-defined subprogram.

Operator is only syntax sugar. There is nothing wrong in having an unary
prefix operator "new" along with "abs", "+", "-", except for reserving the
keyword "new", of course.

> Imagine a programmer wishing to express a typical pattern such as
> 
>    "Find A in B!"

No problem:

find - prefix unary operation
A - operand
in - infix operation
B - operand
! - postfix unary operation

If you are ready to make "find" reserved and allow "!" there would be no
syntax problem. "in" is already an infix operation in Ada.

> Operators in (syntactical) context will add readability because
> the pattern is clear, not because one knows some names.

No, they are ambiguous if not reserved keywords *and* if association
priorities are unset.

You need to reduce syntax into non-existence, like Forth does, in order to
have that. And nobody sane would claim Forth readable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Luke A. Guest]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> Yes, newlib _is_ rather big isn't it ? :-)

Why are you using newlib exactly? Not required.

Luke

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-15, Luke A  Guest <laguest@archeia.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>> Yes, newlib _is_ rather big isn't it ? :-)
>
> Why are you using newlib exactly? Not required.
>

I'm not using newlib directly, but the build procedures I use for a
gcc cross compiler build does use it.

It's also required when I, for example, use RTEMS.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-15, Tero Koskinen <tero.koskinen@iki.fi> wrote:
> 14.6.2014 23:41, Simon Clubley wrote:
>> 
>> Thanks for the feedback. I'll admit I've not yet used the MSP 430
>> because when I build my own circuits I use PDIP packaged MCUs and the
>> MSP 430 PDIP range been lacking when compared to other PDIP MCUs.
>
> Olimex sells MSP430 header boards, which are basically just
> DIP adapters (+crystal) for MSP430 MCUs. Of course, in some cases
> real PDIP packaged MCU is better, but I find those boards
> quite handy. (For now, I have played only with MSP430 assembler,
> I haven't had time to test MSP430-Ada much.)
>
> https://www.olimex.com/Products/MSP430/Header/
>

I know about the Olimex boards, but thanks for the pointer anyway.

I've bought a number of the Olimex ARM boards over the years but
when I am building circuits which don't need a ARM MCU I prefer to
use a circuit I've designed for the specific task and which has a
PDIP MCU at it's core rather than a header board.

For one thing, it's cheaper and for another it's generally a slightly
smaller circuit. (And the circuit's already big enough anyway when
using PDIP sized components. :-))

Thanks for the suggestion however,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-15, Nasser M. Abbasi <nma@12000.org> wrote:
> speaking of safe languages, I just saw this trying to update
> my viedeplan plugin for firefox:
>
> http://www.videolan.org/security/sa1302.html
>
> "Security Advisory 1302
> When parsing a specially crafted ASF movie,
> a buffer overflow might occur.
>
> Impact
> If successful, a malicious third party could
> trigger an invalid memory access"
>
> "This issue is addressed in VLC media player 2.0.x
> source code repository by replacing a macro with a
> static inline and improved bounds checking."
>
> Notice: "improved bounds checking", WOw! So there
> is still a chance the bounds checking might fail?
>

That's what you get when you have to place the bounds checking
within the source code itself. :-)

Another related area for security issues are in specially crafted
images which trigger buffer overflows (and other issues) in image
processing libraries.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-15, gvdschoot@gmail.com <gvdschoot@gmail.com> wrote:
> On Sunday, June 15, 2014 8:33:44 AM UTC+2, Tero Koskinen wrote:
>> 
>> This is valid Rust code [1]:
>> 
>> pub fn inner<'a>(&'a mut self) -> &'a mut R
>> {
>>    &mut self.h.r
>> }
>> 

That's bloody depressing. :-(

I wonder if today's language designers even know what a Wirth style
language looks like.

>> [1] https://twitter.com/damienmiller/status/476207923702423552
>

Now I'm even more depressed. "function" is too long ???

> On reddit there was a discussion about the GNU coreutils in platform
> independent Rust code[1] and here the code itself on github[2]. This is how it
> looks like in Go[3]. I mean, just look at the code. I am sorry to say this, but
> in the case of Rust I see C++ mistakes being repeated. To me language syntax is
> very important. Readability, simplicity and reasonability should be paramount. 
>
> [1] http://www.reddit.com/r/programming/comments/27yccu/crossplatform_rust_rewrite_of_the_gnu_coreutils/
> [2] https://github.com/uutils/coreutils
> [3] https://github.com/aisola/go-coreutils

Thanks for the links (and very interesting links they were.)

I don't like the Go brace style however. (My own brace style in C
is the Whitesmiths brace style.)

I guess I now know what I'm re-implementing as a test if Oberon-14
were to ever become something real. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Georg Bauhaus]

On 16/06/14 02:35, Simon Clubley wrote:
> I wonder if today's language designers even know what a Wirth style
> language looks like.

You mean, neither cool nor marketable?

Re: a new language, designed for safety !

[Georg Bauhaus]

On 16/06/14 08:08, Georg Bauhaus wrote:
> On 16/06/14 02:35, Simon Clubley wrote:
>> I wonder if today's language designers even know what a Wirth style
>> language looks like.
>
> You mean, neither cool nor marketable?

Seriously, from these adjectives follows that referring to Wirth
style languages will likely sound preachy. Not the attitude that
one would want associated with a language designed for free,
enthusiastic, up-to-date people.

But look at how Apple did use some more syntax in its version
of Go. Similarly, Scala, I think, is only superficially
catering to the ever popular omissive style.

Re: a new language, designed for safety !

[gvdschoot]

On Monday, June 16, 2014 8:08:52 AM UTC+2, Georg Bauhaus wrote:
> On 16/06/14 02:35, Simon Clubley wrote:
> 
> > I wonder if today's language designers even know what a Wirth style
> 
> > language looks like.
> 
> 
> 
> You mean, neither cool nor marketable?

Yes, exactly. A dull and very productive language.

Re: a new language, designed for safety !

[Peter Chapin]

On 2014-06-16 02:19, Georg Bauhaus wrote:

> But look at how Apple did use some more syntax in its version
> of Go. Similarly, Scala, I think, is only superficially
> catering to the ever popular omissive style.

Excessive terseness is bad for readability but so is excessive
verbosity. There is a sweet spot somewhere between the extremes; finding
it is tricky because, I believe, it's different for different people.
Also an expert in a language will have a different outlook than a novice.

Scala allows you to create new operators (in effect). That's one of
those features that can be very nice when used with wisdom but
absolutely terrible when used carelessly. Alas, for each wise usage of
that feature I think there are probably 10 careless usages.

Peter

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-16, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:
> On 16/06/14 08:08, Georg Bauhaus wrote:
>> On 16/06/14 02:35, Simon Clubley wrote:
>>> I wonder if today's language designers even know what a Wirth style
>>> language looks like.
>>
>> You mean, neither cool nor marketable?
>
> Seriously, from these adjectives follows that referring to Wirth
> style languages will likely sound preachy. Not the attitude that
> one would want associated with a language designed for free,
> enthusiastic, up-to-date people.
>

Actually, I just was wondering if today's students are still exposed
to these types of languages or if such languages are alien to them.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:2100734262424129975.133931laguest-archeia.com@nntp.aioe.org...
> "J-P. Rosen" <rosen@adalog.fr> wrote:
...
> language. Would you argue
>> that C is being impaired because Microsoft C is not free?
>
> There are many implementations of C, not true of Ada.

Really? I'm sure the Atego people, ICC (Adam's employer), and RRS (me) would 
be rather surprised to hear that. Not to mention the many Ada 95 
implementations still available.

                  Randy. 

Re: a new language, designed for safety !

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccd2ec34um.fsf@shell01.TheWorld.com...
...
> But I think what Simon wants is convenient syntax for dealing with
> associative arrays, and that's reasonable.  But in a better language,
> that wouldn't require associative arrays to be built in.

Which Ada 2012 has. Specifically, referencing container elements works just 
like an array, and iteration works just like an array. Simon said he didn't 
want keys created implicitly, so the explicit calls to Insert aren't a 
problem. So what's missing? (Slices don't make sense for Maps, since the 
items are not ordered.)

                                  Randy.

Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-16, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Luke A. Guest" <laguest@archeia.com> wrote in message 
> news:2100734262424129975.133931laguest-archeia.com@nntp.aioe.org...
>> "J-P. Rosen" <rosen@adalog.fr> wrote:
> ...
>> language. Would you argue
>>> that C is being impaired because Microsoft C is not free?
>>
>> There are many implementations of C, not true of Ada.
>
> Really? I'm sure the Atego people, ICC (Adam's employer), and RRS (me) would 
> be rather surprised to hear that. Not to mention the many Ada 95 
> implementations still available.
>

How many of those compilers can be used to generate code for an ARM
or MIPS processor and how does the pricing compare to the comparable
C compiler ?

The real problem is that Ada isn't a mainstream language these days
(at least for general use) so if you want to attract new people to
it, you can't start charging significant money to people just wanting
to explore the language.

Many of those people wanting to explore the language will be wanting
to explore Ada by using it on embedded platforms so you need a range
of Ada cross compilers available in the same way you have a range of
C cross compilers available for those same people to use.

I know I keep repeating this, but the cold reality is that if the Ada
compiler options available don't match the needs (both in terms of
platforms and pricing) of the people who are potentially interested
in exploring Ada, then it doesn't matter how good Ada is; none of
those people are going to give Ada a go.

I know many of you work in critical environments where paying large
amounts of money for a supported compiler not only makes sense, but
is expected. However, many of the people you are potentially trying
to get interested in using Ada in the future workplace are generally
hobbyists and other people paying for their experiments out of their
own pockets - and those people have several free non-Ada options
available to them for their projects.

These people you are trying to get to use Ada will generally have
very different pricing and platforms needs compared to your critical
workplace projects and, when pushing Ada, you need to think in terms
of their needs, not yours.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 16 Jun 2014 11:39:27 -0500, Randy Brukardt wrote:

> Slices don't make sense for Maps, since the items are not ordered.

Most useful maps are. And you couldn't iterate an unordered map anyway.

Anyway, Ada 2012 indices have are no substitute to arrays. Arrays require
no pointers, need not to be by-reference themselves, etc. Granted, I never
tried it, but I honestly doubt it were possible to emulate say Integer
array with Ada 2012 indexing and implicit dereferencing kludges, even
without slices. And struggling with compiler messages would certainly be a
hell.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-16, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccd2ec34um.fsf@shell01.TheWorld.com...
> ...
>> But I think what Simon wants is convenient syntax for dealing with
>> associative arrays, and that's reasonable.  But in a better language,
>> that wouldn't require associative arrays to be built in.
>
> Which Ada 2012 has. Specifically, referencing container elements works just 
> like an array, and iteration works just like an array. Simon said he didn't 
> want keys created implicitly, so the explicit calls to Insert aren't a 
> problem. So what's missing? (Slices don't make sense for Maps, since the 
> items are not ordered.)
>

I guess I'm adding Ada 2012 to the list of things to take a more
detailed look at. :-)

Thanks Randy,

Simon.

PS: What is the availability (and reliability) of the Ada 2012 features
in the FSF gcc branch these days ?

For example, when I look here:

	http://people.debian.org/~lbrenta/debian-ada-policy.html

it's not at all clear how much of Ada 2012 is present in the FSF GCC
branch and the same is true for other searches I've just done.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Wright]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> PS: What is the availability (and reliability) of the Ada 2012
> features in the FSF gcc branch these days ?

I don't think we know that for GNAT GPL 2014 either! But, FWIW, my
limited experience with FSF GCC 4.9.0 hasn't shown up any problems so
far.

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-16, Simon Wright <simon@pushface.org> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> PS: What is the availability (and reliability) of the Ada 2012
>> features in the FSF gcc branch these days ?
>
> I don't think we know that for GNAT GPL 2014 either! But, FWIW, my
> limited experience with FSF GCC 4.9.0 hasn't shown up any problems so
> far.

Thanks Simon - another thing added to the outstanding projects list. :-)

Simon.

PS: "gcc 4.9.0". I'm either getting old or the gcc version numbers are
really starting to fly past these days. :-) I still remember when it
was gcc 2.8.x and we were manually integrating the GNAT sources with
the gcc sources prior to building the compiler...

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Luke A. Guest]

"Randy Brukardt" <randy@rrsoftware.com> wrote:

>> language. Would you argue
>>> that C is being impaired because Microsoft C is not free?
>> 
>> There are many implementations of C, not true of Ada.
> 
> Really? I'm sure the Atego people, ICC (Adam's employer), and RRS (me) would 
> be rather surprised to hear that. Not to mention the many Ada 95 
> implementations still available.

I meant available to a general user or beginner. Also, I meant those that
do not use someone else's front end as I understand a lot of the Ada
compilers available (at extreme cost) are the same front end.

Therefore 1) not many available for free or less than a couple I hundred
quid and even that is too much for a lot of people, 2) not many independent
implementations.

Can't believe we have to spell this shit out constantly on this group.

Re: a new language, designed for safety !

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Which Ada 2012 has. Specifically, referencing container elements works just 
> like an array, and iteration works just like an array.

Yes, Ada 2012 is a big improvement in this area.  I found the Containers
unusable in Ada 2005 due to syntactic overhead.  Something like:

    ... My_Function(A(X).Y) ...

was taking a dozen or more lines of code if A is a Vector instead of an array.
That's been largely fixed, for clients of Vectors.

It's unfortunate that writing something like Vectors requires arcane
black magic involving access discriminants, though.

It's also unfortunate that Vectors are inherently slow.  I wrote a big
program recently that made heavy use of Vectors.  The Ada 2012 features
were essential for readability -- Vectors would have been unusable
otherwise.  But Vectors was way too slow.  So I wrote my own vectors
package, using the same 2012 features, and then it was fine -- both
readability-wise and efficiency-wise.

>... Simon said he didn't 
> want keys created implicitly, so the explicit calls to Insert aren't a 
> problem. So what's missing?

For Maps, user-defined aggregate notation.  Look at how easy it is to
create a mapping in Python, for example.  But that's built in.  I'd like
user-defined aggregate notation for any type where it makes sense.

For other types:  User-defined literal notation.  User-defined slices.

How about "A Vector is limited if the component type is limited."?
Arrays can do that, but Vectors can't.

Basically, the goal should be that anything the language designer can do
(e.g. for arrays), a programmer can do (e.g. for a user-defined
array-like abstraction).  Well, ALMOST anything -- I'm not asking for
user-defined willy-nilly syntax.  Try writing a "big nums" package, for
example -- just like Ada's Integer, but unbounded.

>...(Slices don't make sense for Maps, since the 
> items are not ordered.)

Slices make sense for Vectors, though.

- Bob

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/16/2014 02:31 PM, Luke A. Guest wrote:
>
> I meant available to a general user or beginner. Also, I meant those that
> do not use someone else's front end as I understand a lot of the Ada
> compilers available (at extreme cost) are the same front end.

Please don't spread FUD.

> Therefore 1) not many available for free or less than a couple I hundred
> quid and even that is too much for a lot of people, 2) not many independent
> implementations.

C's overriding design principle appears to have been ease of compiler 
implementation. The result was a very badly designed language with lots of 
implementations. Since the implementations are mostly crappy, they're free. (How 
crappy? Before it was bought by TI, there was a company called Tartan that made 
most of its money by selling C compilers for systems that came with a free C 
compiler.) Comparing crappy compilers for a crappy language to decent compilers 
for a well designed language makes no sense.

> Can't believe we have to spell this shit out constantly on this group.

Can't believe you still think "Ada compiler" means "free, high-quality, 
independently implemented Ada compiler with a complete run-time library".

-- 
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/16/2014 02:53 PM, Robert A Duff wrote:
>
> It's also unfortunate that Vectors are inherently slow.  I wrote a big
> program recently that made heavy use of Vectors.  The Ada 2012 features
> were essential for readability -- Vectors would have been unusable
> otherwise.  But Vectors was way too slow.  So I wrote my own vectors
> package, using the same 2012 features, and then it was fine -- both
> readability-wise and efficiency-wise.

If Vectors are inherently slow, how were you able to write one that wasn't?

-- 
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

Re: a new language, designed for safety !

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 06/16/2014 02:53 PM, Robert A Duff wrote:
>>
>> It's also unfortunate that Vectors are inherently slow.  

To be clear:  I meant that Ada.Containers.Vectors as defined by the Ada
RM are inherently slow.  Not that all possible vector-like
(i.e. growable-array implementations) are inherently slow.

>>...I wrote a big
>> program recently that made heavy use of Vectors.  The Ada 2012 features
>> were essential for readability -- Vectors would have been unusable
>> otherwise.  But Vectors was way too slow.  So I wrote my own vectors
>> package, using the same 2012 features, and then it was fine -- both
>> readability-wise and efficiency-wise.
>
> If Vectors are inherently slow, how were you able to write one that wasn't?

By writing one that has different semantics -- i.e. does not obey all
the Ada RM rules for Ada.Containers.Vectors.

For example, it has the operations I happened to need (like Append), but
lacks the ones I did not (like Insert).

For example, it supports easy and efficient conversions
Vector <--> array.

For yet another example, it lacks the "tampering" business required by
the RM.  I didn't need all sorts of Cursors pointing into the middle of
Vectors, so I didn't need those run-time checks.

The new Ada 2012 features made my vectors usable from a readability
point of view, just as they have for Ada.Containers.Vectors.

- Bob

Re: a new language, designed for safety !

[Maciej Sobczak]

> > What if we treat the standard library as part of the language?
> 
> It would be self-contradictory.

No. There are languages where even things like package importing, adding fields to record types or even virtual dispatch are library-level operations. They might or might not have a support at the level of what we consider "syntax", but even there the border is blurred. In languages that are somewhat inspired by Lisp even the for loop might or might not be a library feature.

> A library is defined in the language terms,

You are trying to give your own definitions as if they are universal truth. My definition is: language and its standard library are indivisible. What now?

I agree that it is a cool ideal to have a language that allows you to implement its own run-time or at least as much of it as possible. But I don't accept it as an objective definition.

> >> If Ada were a better language, array could be a
> >> library container.
> 
> > Assembly language fits that ideal, right?
> 
> No it does not. Assembly languages do not have containers.

You have asked for a library. Definitely assembly languages can have libraries with containers.

> Operator new was a mistake, excusable for early 80's. It is especially
> obvious since deallocator is not an operator.

Ada is exceptional in the sense that deallocator is not an operator. Other languages like have that right (that is, allocation/deallocations are both operators or neither one is).

> BTW, assignment operator was
> a mistake too.

If there is no assignment operator, you need something else to build it upon. A dictionary, perhaps? But now, you wanted that in the library, too.
It seems to be that the choice between syntax and library support is a matter of taste - but this makes it even further from being an objective definition.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Tue, 17 Jun 2014 01:18:46 -0700 (PDT), Maciej Sobczak wrote:

>>> What if we treat the standard library as part of the language?
>> 
>> It would be self-contradictory.
> 
> No. There are languages where even things like package importing, adding
> fields to record types or even virtual dispatch are library-level
> operations. They might or might not have a support at the level of what we
> consider "syntax", but even there the border is blurred.

It is never blurred, cannot be. It could be ill-defined, yes. But in a
*well-defined* formal language each syntactic construct is either legal or
not. A library is either composed out of legal constructs or not. In the
former case it is not a part of the language. In the latter case it isn't
either.

>> A library is defined in the language terms,
> 
> You are trying to give your own definitions as if they are universal
> truth.

http://en.wikipedia.org/wiki/Library_%28computing%29

Straight in the first sentence.

> My definition is: language and its standard library are
> indivisible. What now?

Then it does not make sense to distinguish them. Thus there is no library
at all.

Not my invention either:

http://en.wikipedia.org/wiki/Occam_razor

> I agree that it is a cool ideal to have a language that allows you to
> implement its own run-time or at least as much of it as possible. But I
> don't accept it as an objective definition.

Huh? The whole idea of programming is implementing own "run-time", isn't
it?

>>>> If Ada were a better language, array could be a
>>>> library container.
>> 
>>> Assembly language fits that ideal, right?
>> 
>> No it does not. Assembly languages do not have containers.
> 
> You have asked for a library. Definitely assembly languages can have
> libraries with containers.

Nope, it cannot. As I said earlier you can get an equivalent functionality
(per Turing-completeness), but you could not organize it as a set of types
with instances of. Assembly language does not support user-defined types.
 
>> BTW, assignment operator was
>> a mistake too.
> 
> If there is no assignment operator, you need something else to build it
> upon.

I was talking about syntax. There is no need to have it a statement.
Assignment could have been an operation, without the result, if we wanted
to prevent it appearing in the middle of an expression. However, since Ada
2012 allowed if-then-else expression, in-out parameters of functions, it
becomes difficult to defend the status of assignment as a statement. Not
that I welcome if-then-else expression or would assignments returning
results.

> A dictionary, perhaps? But now, you wanted that in the library, too.
> It seems to be that the choice between syntax and library support is a
> matter of taste - but this makes it even further from being an objective
> definition.

Nope, it the difference between syntax and semantics. You shall not burden
syntax with semantics unless absolutely required. There is nothing special
in assignment's semantics comparing to the semantics of other subprograms.
Thus it does not deserve special syntax. This is not related to the
question should the language provide operator ":=" or not. The former is
semantics, the latter is syntax.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[gvdschoot]

On Tuesday, June 17, 2014 1:02:08 AM UTC+2, Jeffrey Carter wrote:
> On 06/16/2014 02:31 PM, Luke A. Guest wrote:
> 
> >
> 
> > I meant available to a general user or beginner. Also, I meant those that
> 
> > do not use someone else's front end as I understand a lot of the Ada
> 
> > compilers available (at extreme cost) are the same front end.
> 
> 
> 
> Please don't spread FUD.
> 
> 
> 
> > Therefore 1) not many available for free or less than a couple I hundred
> 
> > quid and even that is too much for a lot of people, 2) not many independent
> 
> > implementations.
> 
> 
> 
> C's overriding design principle appears to have been ease of compiler 
> 
> implementation. The result was a very badly designed language with lots of 
> 
> implementations. Since the implementations are mostly crappy, they're free. (How 
> 
> crappy? Before it was bought by TI, there was a company called Tartan that made 
> 
> most of its money by selling C compilers for systems that came with a free C 
> 
> compiler.) Comparing crappy compilers for a crappy language to decent compilers 
> 
> for a well designed language makes no sense.
> 
> 
> 
> > Can't believe we have to spell this shit out constantly on this group.
> 
> 
> 
> Can't believe you still think "Ada compiler" means "free, high-quality, 
> 
> independently implemented Ada compiler with a complete run-time library".
> 

That is probably one of the main reasons it isn't a generally used language. I have never seen Unix written in Ada. And even the majority of the JSF/F35 code is written in C++ instead of Ada. Reason? Lack of Ada programmers. So the lack of good free compilers (with that I mean BSD/ISC/MIT licensed instead of GPL) is hindering the general acceptance more than acknowledged.

> 
> 
> -- 
> 
> Jeff Carter
> 
> "Saving keystrokes is the job of the text editor,
> 
> not the programming language."
> 
> Preben Randhol
> 
> 64

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-16, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 06/16/2014 02:31 PM, Luke A. Guest wrote:
>>
>> I meant available to a general user or beginner. Also, I meant those that
>> do not use someone else's front end as I understand a lot of the Ada
>> compilers available (at extreme cost) are the same front end.
>
> Please don't spread FUD.
>
>> Therefore 1) not many available for free or less than a couple I hundred
>> quid and even that is too much for a lot of people, 2) not many independent
>> implementations.
>
> C's overriding design principle appears to have been ease of compiler 
> implementation. The result was a very badly designed language with lots of 
> implementations. Since the implementations are mostly crappy, they're free. (How 
> crappy? Before it was bought by TI, there was a company called Tartan that made 
> most of its money by selling C compilers for systems that came with a free C 
> compiler.) Comparing crappy compilers for a crappy language to decent compilers 
> for a well designed language makes no sense.
>

Don't confuse the C compiler market in the 1980s/1990s with today's
market now gcc and llvm have become established and set minimum baselines
for what is and is not acceptable quality wise.

Also, just because something is easy to implement than that doesn't mean
it has to be a bad thing. Oberon is a language which is (relatively)
easy to implment.

I think the core question here is: do you want to encourage Ada use by
more people or do you want Ada to only be used by some ever declining
elite ?

If it's the former, then you have to package Ada compilers in a way
which is relevant to those people or Ada simply will never be considered
by them.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: a new language, designed for safety !

[Simon Wright]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> PS: "gcc 4.9.0". I'm either getting old or the gcc version numbers are
> really starting to fly past these days. :-) I still remember when it
> was gcc 2.8.x and we were manually integrating the GNAT sources with
> the gcc sources prior to building the compiler...

My download of 4.8.0 is dated 12 April 2013, so releases aren't all that
frequent!

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/17/2014 04:14 AM, gvdschoot@gmail.com wrote:
>
> That is probably one of the main reasons it isn't a generally used language.
> I have never seen Unix written in Ada. And even the majority of the JSF/F35
> code is written in C++ instead of Ada. Reason? Lack of Ada programmers. So
> the lack of good free compilers (with that I mean BSD/ISC/MIT licensed
> instead of GPL) is hindering the general acceptance more than acknowledged.

The F-35 code was probably written in C++ because there are hard data showing 
that using C++ results in twice the development cost as Ada, and the F-35 
contract was cost-plus, meaning the more it cost, the greater the contractor's 
profit.

That's quite an assertion. I'd have to see some evidence to back it up. All you 
have to do is write a really good quality Ada compiler available under one of 
those licenses targeting all those systems and having a really great library and 
see if a significant amount of the crap being written in C-family languages 
starts being written in Ada.

But I can tell you what the result would be. Ada is a language for software 
engineers, and only about 2% of developers are software engineers. The 98% who 
are coders will never use an Ada-like language by choice.

-- 
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/17/2014 05:56 AM, Simon Clubley wrote:
>
> I think the core question here is: do you want to encourage Ada use by
> more people or do you want Ada to only be used by some ever declining
> elite ?

As I've said before, Ada will never be used willingly by the 98% of of 
developers who aren't software engineers.

-- 
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

Re: a new language, designed for safety !

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccoaxss9po.fsf@shell01.TheWorld.com...
...
> For yet another example, it lacks the "tampering" business required by
> the RM.  I didn't need all sorts of Cursors pointing into the middle of
> Vectors, so I didn't need those run-time checks.

Reminder: Those run-time checks have two purposes: (1) to prevent iteration 
from going off into the weeds if the container is modified during iteration. 
Perhaps you only support iteration by indexes such that that isn't a 
problem. (2) to prevent elements from disappearing or causing erroneous 
execution while they are in use. There's nothing about "cursors pointing 
into the middle of vectors".

Indexing is only "safe" if some sort of element check is performed; in many 
cases the check isn't needed (if the element is used quickly and then 
discarded), but passing an element (or part of an element) as a parameter is 
common and there lie dragons.

The reason that using indexing in the standard containers is slow is because 
it requires compiler support to eliminate the check in the cases where it is 
not needed (probably over 90% of the cases in practice). But most 
implementors just write an Ada package and let the chips fall where they 
may. That won't give decent performance.

Other languages just let all container use be erroneous if one makes a 
mistake. We didn't want containers to be significantly less safe than an 
array (which doesn't have these issues as an element cannot be removed). 
Maybe that was a mistake, as safety no longer seems to matter.

                                                         Randy.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lnn8ff$k42$1@dont-email.me...
> On 2014-06-16, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Luke A. Guest" <laguest@archeia.com> wrote in message
>> news:2100734262424129975.133931laguest-archeia.com@nntp.aioe.org...
>>> "J-P. Rosen" <rosen@adalog.fr> wrote:
>> ...
>>> language. Would you argue
>>>> that C is being impaired because Microsoft C is not free?
>>>
>>> There are many implementations of C, not true of Ada.
>>
>> Really? I'm sure the Atego people, ICC (Adam's employer), and RRS (me) 
>> would
>> be rather surprised to hear that. Not to mention the many Ada 95
>> implementations still available.
>
> How many of those compilers can be used to generate code for an ARM
> or MIPS processor and how does the pricing compare to the comparable
> C compiler ?

Not relevant to the original point, which is that there are pay compilers 
and free compilers for both Ada and C. And there are many of each for both 
languages. You said nothing about targets in your original statement, nor 
the message you were replying to (which was about Microsoft C).

...
> Many of those people wanting to explore the language will be wanting
> to explore Ada by using it on embedded platforms so you need a range
> of Ada cross compilers available in the same way you have a range of
> C cross compilers available for those same people to use.

It's impractical to have any such cross-compilers. Every such compiler 
(run-time, really) has to be tailored to the specific board in question. We 
treated each embedded compiler as something that would require extensive 
support, and I still think we lost money on each.

The only reason that C compilers exist is because the board manufacturer 
spent $$$$ to create/tailor it.

Obviously, a dedicated person can do that work for themselves, but you 
already have to be an expert to do so.

> ... However, many of the people you are potentially trying
> to get interested in using Ada in the future workplace are generally
> hobbyists and other people paying for their experiments out of their
> own pockets - and those people have several free non-Ada options
> available to them for their projects.

And there is no possible way for Ada to compete with this. It takes $$$$ (or 
equivalent time) to create *one* cross-compiler for *one* board. Without 
someone providing that $$$$ or time, no equivalent is possible.

Personally, I'm dubious that there are enough hardware hackers out there for 
the existence of free Ada cross-compilers to matter. I found hardware 
near-impossible to understand, and as such, it's clearly beyond the 
possibility for 99.9% of hobbyists as well. :-) The existence of things like 
the Raspberry PI helps a bit, but there were boards like that back in the 
80s (I forget the name of the one that we had) but it still was way too 
difficult to make it do something. I decided that getting an S-100 A-to-D 
card was a better, if more expensive, plan (because it could then be 
programmed sensibly).

                                        Randy.

P.S. Of course, I'm the same guy who has never managed to write a fully 
working program in C. I refuse to believe that anyone can do so (and most of 
the evidence is that I'm right :-).

Re: a new language, designed for safety !

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lnpdt2$ggn$1@dont-email.me...
> On 2014-06-16, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
...
> I think the core question here is: do you want to encourage Ada use by
> more people or do you want Ada to only be used by some ever declining
> elite ?

As Jeff says, Ada is only for software engineers. Most people do not want to 
engineer software. (They shouldn't be allowed near a computer, IMHO, but 
that's never going to happen.) Ergo, Ada is only for an "elite" (and those 
who want to be "elite").

Mass-marketed Ada would have to be the same sort of garbage that you see in 
C-family languages (or worse) -- the point would be completely lost in that 
case.

> If it's the former, then you have to package Ada compilers in a way
> which is relevant to those people or Ada simply will never be considered
> by them.

Most of those people should be kept in a sandbox where they can't do any 
harm. They're not candidates for using Ada. That's probably the only good 
thing about Apple's IOS systems. :-)

                                 Randy.

Re: a new language, designed for safety !

[Jacob Sparre Andersen]

Jeffrey Carter wrote:

> As I've said before, Ada will never be used willingly by the 98% of of
> developers who aren't software engineers.

But shouldn't we still attempt to reach the remaining 2%?

Comparing the number of JavaScript and Ada developers on GitHub
indicates that there is space to multiply the number of Ada developers
by 50.

Greetings,

Jacob
-- 
"... but I don't think even Tucker can do scheduling with no cost."
                                                  -- Randy Brukardt

Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/17/2014 12:41 PM, Randy Brukardt wrote:
>
> As Jeff says, Ada is only for software engineers. Most people do not want to
> engineer software. (They shouldn't be allowed near a computer, IMHO, but
> that's never going to happen.) Ergo, Ada is only for an "elite" (and those
> who want to be "elite").

Some day, perhaps, liability issues will keep coders from designing important 
software and choosing the language to write it in, just as liability issues keep 
construction workers from designing bridges and choosing the materials to build 
them with. Until then, though, we have the construction workers designing the 
bridges.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/17/2014 12:34 PM, Randy Brukardt wrote:
>
> P.S. Of course, I'm the same guy who has never managed to write a fully
> working program in C. I refuse to believe that anyone can do so (and most of
> the evidence is that I'm right :-).

We have decades of experience that show that humans cannot write real-world C 
without creating security vulnerabilities.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Luke A. Guest]

You have nailed it completely. I think we are the only people in this group
who seem to grasp this concept.

Re: a new language, designed for safety !

[Georg Bauhaus]

On 17/06/14 22:08, Jeffrey Carter wrote:
> On 06/17/2014 12:41 PM, Randy Brukardt wrote:
>>
>> As Jeff says, Ada is only for software engineers. Most people do not want to
>> engineer software. (They shouldn't be allowed near a computer, IMHO, but
>> that's never going to happen.) Ergo, Ada is only for an "elite" (and those
>> who want to be "elite").
>
> Some day, perhaps, liability issues will keep coders from designing important software and choosing the language to write it in, just as liability issues keep construction workers from designing bridges and choosing the materials to build them with. Until then, though, we have the construction workers designing the bridges.
>

A language may require programmers to write a "responsibility
section" as part of an entity's interface: a formal description
that lists everything a client must know about it in order
to use it without error.

Ada 2012 contracts can be interpreted as a step in this direction,
I think. Unfortunately, Ada 2012 makes the contractual aspect of
programming an optional part, and in some pinboard style list of
notes at that.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Georg Bauhaus]

On 17/06/14 22:16, Jeffrey Carter wrote:
> On 06/17/2014 12:34 PM, Randy Brukardt wrote:
>>
>> P.S. Of course, I'm the same guy who has never managed to write a fully
>> working program in C. I refuse to believe that anyone can do so (and most of
>> the evidence is that I'm right :-).
>
> We have decades of experience that show that humans cannot write real-world C without creating security vulnerabilities.
>

Vulnerable products do not harm economically, as long as
each competitor in the software business suffers the same
economical consequences.

Therefore, if every competitor creates security vulnerabilities
C style, the consequences do not include a relative disadvantage
for any of them, economically.

On the contrary, a security vulnerability creates an opportunity
to have customers apply any patches to products as long as they are
distributed with a label saying "security and vulnerability fixes".

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Nasser M. Abbasi]

On 6/18/2014 12:56 AM, Georg Bauhaus wrote:

> On the contrary, a security vulnerability creates an opportunity
> to have customers apply any patches to products as long as they are
> distributed with a label saying "security and vulnerability fixes".
>

Oracle have been issuing these for Java for the last, what
5 years?  There are pages and pages of these

http://www.oracle.com/technetwork/topics/security/alerts-086861.html

"This page lists announcements of security fixes made
in Critical Patch Update Advisories and Security Alerts"

Yet, Java remaines the most popular language among programmers,
as well as C and C++. But may be Java security problems is
with the JVM itself, and not the language itself?

But I really do not think most programmers consider safety and
robustness and strong typing of a programming language
as a first priority when selecting which one to learn or use.

--Nasser

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-17, Luke A  Guest <laguest@archeia.com> wrote:
> You have nailed it completely. I think we are the only people in this group
> who seem to grasp this concept.

For what it's worth, I too am completely with you in that.

And has been already pointed out (IIRC by Jacob Sparre Andersen), the
"2% argument" doesn't really counter that, since compiler avilability
probably drives away a significant part of those 2%ters.

Myself, for example. I'm here only because a few years ago, sheer luck
made me stumble upon wikipedia page for Steelman requirements, and
because GNAT-AUX made Ada available freely on my platform of choice
(FreeBSD/intel, which I believe to be a comparatively easy target).

How many of these 2%ers never heard of Ada and instead stick to C with
-Wall -Wextra -Weven-more -Werror -pedantic
-fblow-a-huge-horn-on-anything-suspicious ?

How many of them give Ada a go, only to drop it when they realize they
can't compile anything for their target platform?


Anyway, I'm willing to contribute a lot of my free time to help a new
free Ada compiler emerge, ideally a LLVM front-end written from scratch
in Ada, bootstrapped by FSF GNAT, licenced under BSD or Apache or
something like that.

I know that way lies madness, but every time I post here it makes me
feel like a complete lunatic on the killfile of most regular posters
here, so I guess I don't have much to lose.

However with only "a lot of my free time" it would still take decades to
make a usable Ada95 LLVM front-end, and I don't really have the people
skills to rally enough people to given a decent chance of success to
such a massive project.

So I guess nothing more than big talk would happen <sigh>.


Natasha

Re: a new language, designed for safety !

[Maciej Sobczak]

> It is never blurred, cannot be. It could be ill-defined, yes. But in a
> *well-defined* formal language

What is *well-defined*? If a language allows me to extend it by importing more syntax features by means of a library import, is that well-defined?
I don't see why any given definition (in particular yours) shall be more binding than others.

> each syntactic construct is either legal or
> not.

What if it becomes legal by means of library import?

http://en.wikipedia.org/wiki/Extensible_programming

> > You are trying to give your own definitions as if they are universal
> > truth.
> 
> http://en.wikipedia.org/wiki/Library_%28computing%29
> 
> Straight in the first sentence.

It's a pity you have stopped reading there. Further in the same article:

"Most compiled languages have a standard library"

The "standard library" is a link, which brings us to:

http://en.wikipedia.org/wiki/Standard_library

which contains (second paragraph):

"A language's standard library is often treated as part of the language [...]"

> > My definition is: language and its standard library are
> > indivisible. What now?
> 
> Then it does not make sense to distinguish them. Thus there is no library
> at all.

Fine. Which brings us two posts back to containers, arrays, allocators and operators. What was the point of your previous statements that some of these should be in the language while others should be in the library if now you say that the distinction itself is meaningless?

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Wed, 18 Jun 2014 07:46:13 +0200, Georg Bauhaus wrote:

> Unfortunately, Ada 2012 makes the contractual aspect of
> programming an optional part, and in some pinboard style list of
> notes at that.

1. You cannot contract everything, i.e. define the semantics through the
contract. Per definition of contract, it is a framework of constraints
imposed on the implementations (many).

2. You cannot have exhaustive contracts. That is per the nature of things
(e.g. the Hilbert's program).

1+2. There are many possible contracts, there always exist implied
contracts. Thus you should not require an explicit contract provided the
implied one is OK.

My dream is an ability to start with minimal proofs and, as the program
matures, to add checks later, incrementally. That would be a sort of better
TDD (test-driven design). It would keep up-front design reasonably small,
which is important while requirements are unstable. You would cover the
cases either with proofs or with tests, both incrementally.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Wed, 18 Jun 2014 00:55:51 -0700 (PDT), Maciej Sobczak wrote:

>> It is never blurred, cannot be. It could be ill-defined, yes. But in a
>> *well-defined* formal language
> 
> What is *well-defined*?

http://en.wikipedia.org/wiki/Well-defined

> If a language allows me to extend it by importing more syntax features by
> means of a library import, is that well-defined?

No. Such languages do not exist.

If you have a language definition, that (in a well-defined language) gives
you a countable set of all legal programs (not all of them compilable).

http://en.wikipedia.org/wiki/Well-formed_formula

Provided "importing" is a language term, that set includes everything you
might "import."

If "importing" is not a language term, then the effect of doing it is
*another* language. Not the one under consideration.

You cannot have both. You can consider "importing" and stuff as another
meta-language dealing with the object languages. That is what preprocessor,
generics and Co. is. Once you define your meta-language, it is a language
again, and the reasoning apples to it fully.

The only way out is to have it ill-defined.

>> each syntactic construct is either legal or not.
> 
> What if it becomes legal by means of library import?
> 
> http://en.wikipedia.org/wiki/Extensible_programming

Then it was legal already. Legality can be context-dependent.

> "A language's standard library is often treated as part of the language [...]"

Here "language" meant as a development framework not as a formal language.
Compare: bugs are definitely a part of C language.

>>> My definition is: language and its standard library are
>>> indivisible. What now?
>> 
>> Then it does not make sense to distinguish them. Thus there is no library
>> at all.
> 
> Fine. Which brings us two posts back to containers, arrays, allocators and
> operators. What was the point of your previous statements that some of
> these should be in the language while others should be in the library if
> now you say that the distinction itself is meaningless?

Because this distinction is NOT meaningless for Ada and other properly
designed languages. You could invent a language where the distinction would
make no sense. That would be so not because the principle were bad, but
because the language is so poor and messy that it would make no sense to
consider it in this context at all, like applying compresses to a dead man.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[G.B.]

On 18.06.14 10:02, Dmitry A. Kazakov wrote:
> On Wed, 18 Jun 2014 07:46:13 +0200, Georg Bauhaus wrote:
>
>> Unfortunately, Ada 2012 makes the contractual aspect of
>> programming an optional part, and in some pinboard style list of
>> notes at that.
>
> 1. You cannot [...] define the semantics through the
> contract.

Contracts are not about this illusion of exhaustive semantics.

The topic (intent) of a contract is really programmer behavior.
It's a legal (cf. Law, not LRM) thing. A contract does not
tackle the decision problem, no matter what the formal tools
will do.

A contract helps Programmer B, who is a reader of the contract,
finding a meaningful answer, in the contract, to the question:

  "What if I ...?"

B doesn't expect miracles (exhaustive miracles that would be)
but B's employer does expect *liability*, which is the term
Jeffrey Carter has used. If B tells his employer that the
entity T does not do what the contract says it does, then B's
employer can talk to the supplier (who has signed the contract
as the other party) and ask for corrections if they agree that
B's observation is correct. They decide what's the case.

> Per definition of contract,

(Pardon? A contract is a manifest piece from the equivalence
class of paper, signed by two parties. Don't blur the
distinction by suggesting that some formal modes of expression
(via Pre, Post, etc.) stand for the entire notion of contract:

                 Townsville, 6th of December 2003

                         CONTRACT
                          between
            Programmer A  and Other Programmers

       We agree that entity T can be used in such a way
       that {... some *agreed* *upon* meaningfulness ...}

    Signed
     for programmer A        for Other Programmers

      Programmer A                John Doe

(No arbitrary wikipedia links this time please, this is serious.
Programming has not invented the word "contract", neither has
mathematics, and since this is about programmers and other
professionals as legal entities, not compilers, formalist views
of "contract" are much too narrow. And also beside the point. 
Programming is a subordinate here.)


> 2. You cannot have exhaustive contracts.

Writing contracts is not a just formal logic, it is about
programmers *behaving* responsibly when programming:

Boss:
   "Sit down, and write a description of your type from which
    both we and they can learn what matters to the contract
    to be signed with Client Corp!")

Programmer:
   "O.K., o.K., I will!"

Boss:
   "You better had do that!"


> My dream is an ability to start with minimal proofs and, as the program
> matures, to add checks later, incrementally. That would be a sort of better
> TDD (test-driven design). It would keep up-front design reasonably small,
> which is important while requirements are unstable. You would cover the
> cases either with proofs or with tests, both incrementally.

Yes! Yes! A thousand times Yes!

This is what contract based design is about.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[J-P. Rosen]

Le 18/06/2014 09:09, Natasha Kerensikova a écrit :
> Anyway, I'm willing to contribute a lot of my free time to help a new
> free Ada compiler emerge, ideally a LLVM front-end written from scratch
> in Ada, bootstrapped by FSF GNAT, licenced under BSD or Apache or
> something like that.

You may not have to start from scratch. Pick-up the Gela-ASIS project
(currently sleeping) and fix what's missing. That will give you a
stand-alone implementation of ASIS, that could be used to generate code
from.

You may even find people at your working place to help you in such an
endeavour ;-)

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Brian Drummond]

On Wed, 18 Jun 2014 12:32:57 +0200, J-P. Rosen wrote:

> Le 18/06/2014 09:09, Natasha Kerensikova a écrit :
>> Anyway, I'm willing to contribute a lot of my free time to help a new
>> free Ada compiler emerge, ideally a LLVM front-end written from scratch
>> in Ada, bootstrapped by FSF GNAT, licenced under BSD or Apache or
>> something like that.
> 
> You may not have to start from scratch. Pick-up the Gela-ASIS project
> (currently sleeping) and fix what's missing. That will give you a
> stand-alone implementation of ASIS, that could be used to generate code
> from.
> 
> You may even find people at your working place to help you in such an
> endeavour ;-)

Also possibly worth looking at ghdl. It's not an Ada compiler, but a 
compiler, written in Ada, for a somewhat related language (VHDL). 

http://sourceforge.net/projects/ghdl-updates/
(disclaimer : I do a little - lately VERY little - on this project)

Its author Tristan Gingold is now employed by Adacore so probably can't 
help a rival effort!

Ghdl separates the front end and back end quite cleanly, with an 
intermediate representation ("ortho") which currently interfaces to any 
of: 
gcc, 
its own JIT compiler for i386
and recently, LLVM.

LLVM caused some trouble; apparently it does not provide means to support 
nested (locally declared) subprograms, such as the chain of frame 
pointers (or alternatively display) to access the scope of outer 
subprograms. This may have been a stumbling block for other Ada/LLVM 
projects.

Because VHDL supports multiple processes, ghdl leverages the support for 
these, to provide the chain of scopes. So one option may be to use part 
of this project as an adapter between Gela/Asis and LLVM.

- Brian

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Wed, 18 Jun 2014 11:34:01 +0200, G.B. wrote:

> (Pardon? A contract is a manifest piece from the equivalence
> class of paper, signed by two parties.

And that does not defines the parties it only constrains them, which was
the point.

>> 2. You cannot have exhaustive contracts.
> 
> Writing contracts is not a just formal logic, it is about
> programmers *behaving* responsibly when programming:

Irrelevant. So long they must behave in a way that the things they write
satisfy the contract. If they do that irresponsibly, whatever.

If you are contracted to smoke one block a day, that might be irresponsible
on your side, but a contract is a contract.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[G.B.]

On 18.06.14 14:30, Dmitry A. Kazakov wrote:
> On Wed, 18 Jun 2014 11:34:01 +0200, G.B. wrote:
>
>> (Pardon? A contract is a manifest piece from the equivalence
>> class of paper, signed by two parties.
>
> And that does not defines the parties it only constrains them, which was
> the point.

In fact, you declared "contract" to be a

"framework of constraints imposed on the implementations"

which a contract between two legal parties is not.
If things required entail things constrained, then making
it sound as if this was an equality, or even the other way
around is invalid.

There is then nothing that warrants mentioning Hilbert.
Maybe if the two parties have agreed to stop programming
entirely in view of of Hilbert's program.

>>> 2. You cannot have exhaustive contracts.
>>
>> Writing contracts is not a just formal logic, it is about
>> programmers *behaving* responsibly when programming:
>
> Irrelevant.

Essential because behavior of parties is the subject of court rulings.
If it is found that for whatever reason the contract was violated
by programmer X, then programmer X can be held responsible. This
is true even in case some technical detail seems to contradict at
the source level. ("It is found" outweighs formal logic.)

> If you are contracted to smoke one block a day, that might be irresponsible
> on your side, but a contract is a contract.

If I sign a contract with you about doing X, and then I
don't do X, then you can hold me responsible. Whether or
not I actually didn't do X is the matter that a compiler
cannot always decide, but courts will. Whether or not
some Y finds doing X morally irresponsible WRT Y's frame
of reference is indeed irrelevant if Y is not the court.

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Wed, 18 Jun 2014 16:43:55 +0200, G.B. wrote:

> On 18.06.14 14:30, Dmitry A. Kazakov wrote:
>> On Wed, 18 Jun 2014 11:34:01 +0200, G.B. wrote:
>>
>>> (Pardon? A contract is a manifest piece from the equivalence
>>> class of paper, signed by two parties.
>>
>> And that does not defines the parties it only constrains them, which was
>> the point.
> 
> In fact, you declared "contract" to be a
> 
> "framework of constraints imposed on the implementations"
> 
> which a contract between two legal parties is not.

Legal parties? What are you talking about?

>>>> 2. You cannot have exhaustive contracts.
>>>
>>> Writing contracts is not a just formal logic, it is about
>>> programmers *behaving* responsibly when programming:
>>
>> Irrelevant.
> 
> Essential because behavior of parties is the subject of court rulings.

Nope. But in any case it does not show that contracts could be exhaustive.

>> If you are contracted to smoke one block a day, that might be irresponsible
>> on your side, but a contract is a contract.
> 
> If I sign a contract with you about doing X, and then I
> don't do X, then you can hold me responsible.

Irrelevant as well. People's behavior and their contracts has nothing to do
with the point about implied contracts and exhaustiveness of contracts. Not
that human's contracts possessed these properties either.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Jeffrey Carter]

On 06/18/2014 12:09 AM, Natasha Kerensikova wrote:
>
> And has been already pointed out (IIRC by Jacob Sparre Andersen), the
> "2% argument" doesn't really counter that, since compiler avilability
> probably drives away a significant part of those 2%ters.
>
> Myself, for example. I'm here only because a few years ago, sheer luck
> made me stumble upon wikipedia page for Steelman requirements, and
> because GNAT-AUX made Ada available freely on my platform of choice
> (FreeBSD/intel, which I believe to be a comparatively easy target).

This is more likely the reason many software engineers don't use Ada: they are 
not aware of it. You stumbled upon Ada by accident; how many others who would 
use Ada have not been so lucky? I don't think free-compiler availability is part 
of it. There are free compilers for the most common development environments 
(Windows and various forms of Unix) to allow such people to learn and experiment 
with the language. Once they get to the point of wanting to use it on obscure 
platform X they're already hooked.

-- 
Jeff Carter
"When Bell Labs were invited to evaluate C against the DoD requirements
[for Ada], they said that there was no chance of C meeting the
requirements of readability, safety, etc. for which we were striving,
and that it should not even be on the list of evaluated languages."
William Whitaker
116

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-18, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 18/06/2014 09:09, Natasha Kerensikova a écrit :
>> Anyway, I'm willing to contribute a lot of my free time to help a new
>> free Ada compiler emerge, ideally a LLVM front-end written from scratch
>> in Ada, bootstrapped by FSF GNAT, licenced under BSD or Apache or
>> something like that.
>
> You may not have to start from scratch. Pick-up the Gela-ASIS project
> (currently sleeping) and fix what's missing. That will give you a
> stand-alone implementation of ASIS, that could be used to generate code
> from.

I wasn't aware of that. Suddenly the idea of a second free Ada compiler
seems within human grasp \o/

For some reason I'm much more frightened by parsing Ada text than by
code generation. I know the latter is probably not easier than the
former (I'm aware of LLVM vs nested functions), but who said fright is
rational?

> You may even find people at your working place to help you in such an
> endeavour ;-)
>
How wonderful a working place this is :-)


Natasha

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Peter Chapin]

On 2014-06-18 13:34, Natasha Kerensikova wrote:

>> You may not have to start from scratch. Pick-up the Gela-ASIS project
>> (currently sleeping) and fix what's missing. That will give you a
>> stand-alone implementation of ASIS, that could be used to generate code
>> from.
> 
> I wasn't aware of that. Suddenly the idea of a second free Ada compiler
> seems within human grasp \o/
> 
> For some reason I'm much more frightened by parsing Ada text than by
> code generation. I know the latter is probably not easier than the
> former (I'm aware of LLVM vs nested functions), but who said fright is
> rational?

I'll mention that I have a pet project to build an Ada compiler that
targets LLVM (although the precise target is subject to change) here

	https://github.com/pchapin/augusta

I don't anticipate this going anywhere quickly; it's mostly just
intended to be a fun hobby project. My implementation language is Scala.

Peter

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Lucretia]

On Wednesday, 18 June 2014 18:34:35 UTC+1, Natasha Kerensikova  wrote:

> I wasn't aware of that. Suddenly the idea of a second free Ada compiler
> seems within human grasp \o/
> 
> For some reason I'm much more frightened by parsing Ada text than by

Parsing wouldn't be hard. It's the semantics that would be the hardest part, imo.

> code generation. I know the latter is probably not easier than the
> former (I'm aware of LLVM vs nested functions), but who said fright is
> rational?

You can flatten them out if the code generator doesn't have them.
 
Luke

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Wed, 18 Jun 2014 17:34:35 +0000 (UTC), Natasha Kerensikova wrote:

> For some reason I'm much more frightened by parsing Ada text than by
> code generation. I know the latter is probably not easier than the
> former (I'm aware of LLVM vs nested functions), but who said fright is
> rational?

Oh, but parsing is really simple thing. You do recursive descent all the
time. Except for expressions. For expressions you could take this:

http://www.dmitry-kazakov.de/ada/components.htm#12.9

Semantic analysis is a hell. Code generation, optimization is a hell within
hell, IMO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-17, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
> message news:lnn8ff$k42$1@dont-email.me...
>> Many of those people wanting to explore the language will be wanting
>> to explore Ada by using it on embedded platforms so you need a range
>> of Ada cross compilers available in the same way you have a range of
>> C cross compilers available for those same people to use.
>
> It's impractical to have any such cross-compilers. Every such compiler 
> (run-time, really) has to be tailored to the specific board in question. We 
> treated each embedded compiler as something that would require extensive 
> support, and I still think we lost money on each.
>

You are thinking of this as a monolithic commercial product. Things are
much more modular in the open source world. Taking the ARM bare metal
(C language) world as an example:

1) At the bottom layer you have the compiler itself. This just generates
code for a set of ARM architecture variants such as Cortex-M3 and
Cortex-A8 as well as older ARM architecture variants such as the ARMv5
variants. It has absolutely no knowledge of any specific MCU or any
board which that MCU might be placed on. Things like memory layouts
are handled in linker scripts.

2) At the next layer up you have code to support a specific MCU. As
well as MCU specific startup code, this includes things like interrupt
handling which is MCU specific in the ARM world. This code generally
comes from the manufacturer of the MCU and is usually free.

3) At the next layer up you have a code library to support the
peripherals on a specific board. If this is a standard board, this
code might be written for you by the manufacturer, or you might have
to write this code yourself.

As an aside, I tend not to like the manufacturer's code and tend to
write and use my own code library written to my standards, but that's
probably just me as most people seem to just use the manufacturer's
code as-is. This is all C code BTW; as mentioned previously I don't do
any Ada bare metal work on ARM due to the compiler issue, but I have
done some Ada embedded work under RTEMS.

I don't know about Luke, but when I talk about Ada cross compilers,
I'm only really thinking about the first part (the compiler itself)
although you will probably need to add in Ada specific initialisation
code into the MCU startup code. Provided the calls into the Ada RTL
are cleanly documented then that's not a problem for me.

>
> Personally, I'm dubious that there are enough hardware hackers out there for 
> the existence of free Ada cross-compilers to matter. I found hardware 
> near-impossible to understand, and as such, it's clearly beyond the 
> possibility for 99.9% of hobbyists as well. :-)
>

I'm surprised at that. Granted, the components I use are PDIP sized,
but when they are available in that size, I have no problem designing
and building circuits.

I'm more capable in the digital hardware world than in the analogue
(or RF) world however.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 18 Jun 2014 17:34:35 +0000 (UTC), Natasha Kerensikova wrote:
>
>> For some reason I'm much more frightened by parsing Ada text than by
>> code generation. I know the latter is probably not easier than the
>> former (I'm aware of LLVM vs nested functions), but who said fright is
>> rational?
>
> Oh, but parsing is really simple thing. You do recursive descent all the
> time. Except for expressions. For expressions you could take this:
>
> http://www.dmitry-kazakov.de/ada/components.htm#12.9
>

I agree parsing is a lot easier than code generation and I've written
a number of recursive descent parsers over the years.

However, off the top of my head, I don't understand why you can't parse
an Ada expression using recursive descent, especially if you have access
to the symbol table (if you need it). Do you have an example, because
the answer's probably obvious once you point it out. :-)

(I've never written a parser for Ada syntax, but I have written parsers
for various Wirth style languages in the past and I don't recall any
specific problems with expressions in those languages.)

Thanks,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-18, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> However, off the top of my head, I don't understand why you can't parse
> an Ada expression using recursive descent, especially if you have access
> to the symbol table (if you need it). Do you have an example, because
> the answer's probably obvious once you point it out. :-)
>

The above is a bit badly worded. It should say:

|However, off the top of my head, I don't understand why you can't parse
|an Ada expression using recursive descent, especially since you have
|access to the symbol table (if you need it to solve the specific problem
|you are thinking of).

IOW, I _think_ all ambiguity should be resolvable with a suitably rich
symbol table. Clearly that's not the case - and there's probably some
really obvious case I am missing. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:erb49jp6qy6n$.5cesca6do7x3$.dlg@40tude.net...
...
> Semantic analysis is a hell.

Agreed here.

> Code generation, optimization is a hell within hell, IMO.

Naw, that's fun. Much more predicable than dealing with Ada semantics (or 
any language semantics, for that matter). If I had my druthers, that's all 
I'd do. Unfortunately, there's little possibility of that in modern systems, 
all of the fun is in the GCC and LLVM backends. Sigh.

                                     Randy.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lnsqus$d4j$1@dont-email.me...
> On 2014-06-17, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
>> message news:lnn8ff$k42$1@dont-email.me...
>>> Many of those people wanting to explore the language will be wanting
>>> to explore Ada by using it on embedded platforms so you need a range
>>> of Ada cross compilers available in the same way you have a range of
>>> C cross compilers available for those same people to use.
>>
>> It's impractical to have any such cross-compilers. Every such compiler
>> (run-time, really) has to be tailored to the specific board in question. 
>> We
>> treated each embedded compiler as something that would require extensive
>> support, and I still think we lost money on each.
>>
>
> You are thinking of this as a monolithic commercial product. Things are
> much more modular in the open source world.

Not at all. Janus/Ada is structured almost as you describe below:

> Taking the ARM bare metal (C language) world as an example:
>
> 1) At the bottom layer you have the compiler itself. This just generates
> code for a set of ARM architecture variants such as Cortex-M3 and
> Cortex-A8 as well as older ARM architecture variants such as the ARMv5
> variants. It has absolutely no knowledge of any specific MCU or any
> board which that MCU might be placed on. Things like memory layouts
> are handled in linker scripts.

Yup. But no one can do anything useful with such a thing. It's trivial to 
take a version of Janus/Ada and use it as a cross-compiler for some board. 
But without a runtime, hardware support, and the like, only the most 
dedicated people could use it for anything.

> 2) At the next layer up you have code to support a specific MCU. As
> well as MCU specific startup code, this includes things like interrupt
> handling which is MCU specific in the ARM world. This code generally
> comes from the manufacturer of the MCU and is usually free.

But it's probably not in a form that could be used for Ada. Certainly not 
unless you're planning to require having an C compiler around as well (not 
really good marketing for Ada).

> 3) At the next layer up you have a code library to support the
> peripherals on a specific board. If this is a standard board, this
> code might be written for you by the manufacturer, or you might have
> to write this code yourself.

Right, and this is where the problem is. These have to developed for every 
board for Ada, and there's little likelyhood of anything from the 
manufacturer.

You could of course use some zero-footprint subset of Ada to minimize the 
need for that; to me, such things are so emasculated (no exceptions, no 
tasks, no I/O, etc.) that they're of little value for teaching Ada. (You get 
C-in-Ada-syntax at best, little to be gained there.)

...
> I don't know about Luke, but when I talk about Ada cross compilers,
> I'm only really thinking about the first part (the compiler itself)
> although you will probably need to add in Ada specific initialisation
> code into the MCU startup code. Provided the calls into the Ada RTL
> are cleanly documented then that's not a problem for me.

You'd be very much in the minority. Remember, for the sorts of people you 
are talking about, the compiler is going to have to work pretty much out of 
the box, as the normal person isn't going to have the Ada knowledge needed 
to write a runtime for a particular board.

Besides, pretty much any compiler will work fine as a bare targeted 
compiler; the problems are all in the libraries. (The only reason you 
couldn't use Janus/Ada for that would be the fact that we never built an ARM 
code generator. But that's easy to do, especially if you're not insisting on 
perfect code -- less than a months work. The RTS would take 3 times that.)

                         Randy. 

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-18, Peter Chapin <PChapin@vtc.vsc.edu> wrote:
> I'll mention that I have a pet project to build an Ada compiler that
> targets LLVM (although the precise target is subject to change) here
>
> 	https://github.com/pchapin/augusta
>
> I don't anticipate this going anywhere quickly; it's mostly just
> intended to be a fun hobby project. My implementation language is Scala.

I saw your announcement here and so was aware of your project.

However, when writing a compiler in a language for another language, you
can only rely on people interested in both languages (and maybe a few
from the "host-language" interested in any technical challenge). If
Scala community is on the same order of magnitude as Ada community, that
probably means very few people.

For example, I'm not interested in Scala, the descriptions I saw don't
really interest me in giving it a try, and the JVM target is quite a
strong deterrent for me.

On the other hand, an Ada (partial) compiler written in Ada "scratches
the programmers' hitch" an thus is more likely to gain traction.

I guess the bottom line is that your project and mine have actually very
different aims: you want a fun hobby, I want to help with compiler
diversity.



In a similar but unrelated idea, whenever people describe me as having
a passion for programming or computers, I'm tempted to correct them: I
don't particularly enjoy programming or engineering, I'm only doing
whatever is required to enjoy the results. Hence my choice for Ada and
any software reliability technologies, so I can build tools that can
enjoy without having to constantly go back to developing/debugging
phase.

So there is no fun hobby in my projects, only means to various ends.
(For example my soon-to-be-published Ada bindings to Renderman
Interface is a means to my fun hobby of computer graphics).


Natasha

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-18, Lucretia <laguest9000@googlemail.com> wrote:
> On Wednesday, 18 June 2014 18:34:35 UTC+1, Natasha Kerensikova  wrote:
>> I wasn't aware of that. Suddenly the idea of a second free Ada compiler
>> seems within human grasp \o/
>> 
>> For some reason I'm much more frightened by parsing Ada text than by
>
> Parsing wouldn't be hard. It's the semantics that would be the hardest
> part, imo.

I'm not sure about how much to mean by "semantics", but I would expect
the runtime system to be harder than the ASIS-to-LLVM-intermediate-form
part.

Anyway, I wasn't talking about how difficult stuff is, but how
frightening it is. I would start a difficult project that I understand
and guess how to move forwards, even for decades; while I would start an
easier project when I have no idea on how to tackle it.


Natasha

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 18 Jun 2014 17:34:35 +0000 (UTC), Natasha Kerensikova wrote:
>
>> For some reason I'm much more frightened by parsing Ada text than by
>> code generation. I know the latter is probably not easier than the
>> former (I'm aware of LLVM vs nested functions), but who said fright is
>> rational?
>
> Oh, but parsing is really simple thing. You do recursive descent all the
> time. Except for expressions. For expressions you could take this:
>
> http://www.dmitry-kazakov.de/ada/components.htm#12.9

Maybe it's a vocabulary issue, but it's not the part where tokens are
carved out of input text that frighten me, but rather the first level of
interpretation: what entity is that word referring to? More
specifically, dealing with use clauses, prefix notations, overloading,
and stuff like that.

Am I mistaken in assuming an ASIS  provider takes care of that part as
well?

> Semantic analysis is a hell. Code generation, optimization is a hell within
> hell, IMO.

To clarify, I'm currently only contemplating doing the simplest
ASIS-to-LLVM-intermediate-form translator.

That means no optimization (other than what LLVM can do downstream), no
machine code generation (again other than LLVM provides), no useful
syntax error message, probably no syntax error messages at all for a
while (I'm not even sure how to deal with detecting whether a source is
legal or not), no runtime system, and no standard library.

Now I can still be talked out of this, but pointing out difficulties
outside of the scope of the draft project is not a good deterrent.

You could however point how useless it would be, so you might want to
consider it a milestone rather than a project then.


Natasha

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-18, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 06/18/2014 12:09 AM, Natasha Kerensikova wrote:
>>
>> And has been already pointed out (IIRC by Jacob Sparre Andersen), the
>> "2% argument" doesn't really counter that, since compiler avilability
>> probably drives away a significant part of those 2%ters.
>>
>> Myself, for example. I'm here only because a few years ago, sheer luck
>> made me stumble upon wikipedia page for Steelman requirements, and
>> because GNAT-AUX made Ada available freely on my platform of choice
>> (FreeBSD/intel, which I believe to be a comparatively easy target).
>
> This is more likely the reason many software engineers don't use Ada: they are 
> not aware of it.

I would certainly help a lot to have better Ada advertising, but that is
easier and faster to fix than deep technical hurdles.

>                  You stumbled upon Ada by accident; how many others who would 
> use Ada have not been so lucky? I don't think free-compiler availability is part 
> of it.

I told my story because free compiler availability played as much of a
role as advertisement.

Imagine I stumbled upon Steelman requirements three years earlier. I
would still have thought that this is exactly what I want from a
programming language, and checked out what came out of it: Ada. But
then, I would have discovered there is no Ada compiler for my usual
platform. I might have given it a try using an old linux box if the
timing as good, but then I would still have been put out by the
pascalish look. So I would have discarded it, thinking that was a nice
try.

And then I would still be doing pedantic and over-instrumented C.

>        There are free compilers for the most common development environments 
> (Windows and various forms of Unix) to allow such people to learn and experiment 
> with the language. Once they get to the point of wanting to use it on obscure 
> platform X they're already hooked.

The situation is certainly better now than when I started, as far as
host platform goes.

But still, I'm not sure playing with Ada on host platform is enough to
hook people (assuming they are in the 2% or otherwise "fertile ground"
for Ada). I would rather think they get hooked after their first "real"
project (at least I was, and extending to other favorite languages many
people I know were).

If their current real projects target Android UI, iOS, "smart home", SDR
boards, etc, after having played with Ada they would reluctantly shelf
it in favor of a language that actually does the job. Just like me in my
hypothetical alternate history above.

So I guess it's a matter of estimating how much of the "fertile ground"
matches the previous paragraph. My unfounded guess is a significant
proportion.


Natasha

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[J-P. Rosen]

Le 19/06/2014 09:34, Natasha Kerensikova a écrit :
> Maybe it's a vocabulary issue, but it's not the part where tokens are
> carved out of input text that frighten me, but rather the first level of
> interpretation: what entity is that word referring to? More
> specifically, dealing with use clauses, prefix notations, overloading,
> and stuff like that.
> 
> Am I mistaken in assuming an ASIS  provider takes care of that part as
> well?
No, you are right. ASIS gives you access to the fully decorated tree.
All overloading etc. are resolved. The goal of ASIS was precisely to
relieve tool designers from the hardest part of Ada source analysis.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Wed, 18 Jun 2014 22:51:46 +0000 (UTC), Simon Clubley wrote:

> On 2014-06-18, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>> However, off the top of my head, I don't understand why you can't parse
>> an Ada expression using recursive descent, especially if you have access
>> to the symbol table (if you need it). Do you have an example, because
>> the answer's probably obvious once you point it out. :-)
>>
> 
> The above is a bit badly worded. It should say:
> 
>|However, off the top of my head, I don't understand why you can't parse
>|an Ada expression using recursive descent, especially since you have
>|access to the symbol table (if you need it to solve the specific problem
>|you are thinking of).
> 
> IOW, I _think_ all ambiguity should be resolvable with a suitably rich
> symbol table. Clearly that's not the case - and there's probably some
> really obvious case I am missing. :-)

It should be possible, I think, purely theoretically should be. But it
would be quite difficult. Recursive descent parser is good for
self-repeating nested structures, like [flat] fractals or statements and
blocks of Ada. It is not good for structures like expressions. You can
unwind an expression into something alike and encode that transformation
into the parser, which is a guess [*]. But it does look neither simple nor
natural to me. Then there are issues of handling precedence and rudimentary
constant folding etc, which should not overburden already complicated
semantic analysis.

---------------
* There could be pitfalls. The method I am using requires two stacks.
Recursive descent parser has only one stack.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Thu, 19 Jun 2014 07:34:26 +0000 (UTC), Natasha Kerensikova wrote:

> On 2014-06-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Wed, 18 Jun 2014 17:34:35 +0000 (UTC), Natasha Kerensikova wrote:
>>
>>> For some reason I'm much more frightened by parsing Ada text than by
>>> code generation. I know the latter is probably not easier than the
>>> former (I'm aware of LLVM vs nested functions), but who said fright is
>>> rational?
>>
>> Oh, but parsing is really simple thing. You do recursive descent all the
>> time. Except for expressions. For expressions you could take this:
>>
>> http://www.dmitry-kazakov.de/ada/components.htm#12.9
> 
> Maybe it's a vocabulary issue, but it's not the part where tokens are
> carved out of input text that frighten me, but rather the first level of
> interpretation: what entity is that word referring to? More
> specifically, dealing with use clauses, prefix notations, overloading,
> and stuff like that.

That looks like sematic analysis to me, when you walk the AST finding
interpretations for each identifier there, prune matched interpretations
for type errors against competing signatures until there is single
interpretation for each, or none, or many conflicting. The most horrific
part is error messages generation. Which requires kind of mind-reading for
programmer's intention.

Earlier versions of GNAT had rather poor error messages. It became much
better later. Of course, error messages from generic instantiation are
garbage, but I doubt anybody could improve that significantly anyway.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Peter Chapin]

On 2014-06-19 03:22, Natasha Kerensikova wrote:

> I guess the bottom line is that your project and mine have actually very
> different aims: you want a fun hobby, I want to help with compiler
> diversity.

Yes, I concur with your summary. I also know that picking an
implementation language other than that which is being compiled will
tend to greatly limit contributors. On the other hand, even in my
project there will be significant amounts of Ada in the runtime system
and libraries, etc.

Actually a "strategic" goal of my project is to make people from both
communities aware of each other. While the Ada people here tend to say,
"why would you want to use [insert name of some non-Ada language] for
anything?" I'm about 100% sure the Scala people on the other side would
say, "Ada? Huh...?" However, in my view both are fine languages, each in
its own way, and it would be cool to bring the communities together even
if only in some small manner.

In any case, I certainly am not claiming that my project will provide
any useful degree of compiler diversity... at least not in the
foreseeable future.

Peter

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Peter Chapin]

On 2014-06-19 05:11, Dmitry A. Kazakov wrote:

>> Maybe it's a vocabulary issue, but it's not the part where tokens are
>> carved out of input text that frighten me, but rather the first level of
>> interpretation: what entity is that word referring to? More
>> specifically, dealing with use clauses, prefix notations, overloading,
>> and stuff like that.
> 
> That looks like sematic analysis to me, when you walk the AST finding
> interpretations for each identifier there, prune matched interpretations
> for type errors against competing signatures until there is single
> interpretation for each, or none, or many conflicting. The most horrific
> part is error messages generation. Which requires kind of mind-reading for
> programmer's intention.

My understand is that parsing Ada requires name resolution to resolve
syntactic ambiguities. This means symbol table management and dealing
with Ada's visibility rules has to be done while parsing is taking place.

This probably depends on precisely how one goes about the parse. Perhaps
it is possible to live with the ambiguity and generate a useful parse
tree anyway, deferring the rest of the analysis until later, as you say.
I'm not sure right now but it is something I'll need to figure out soon.

Peter

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Lucretia]

On Thursday, 19 June 2014 08:22:08 UTC+1, Natasha Kerensikova  wrote:

> So there is no fun hobby in my projects, only means to various ends.
> (For example my soon-to-be-published Ada bindings to Renderman
> Interface is a means to my fun hobby of computer graphics).

Now that's a potentially killer application, shame it's not written entirely in Ada, but we can blame Apple/Pixar for that :P

Luke.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Thu, 19 Jun 2014 08:08:40 -0400, Peter Chapin wrote:

> On 2014-06-19 05:11, Dmitry A. Kazakov wrote:
> 
>>> Maybe it's a vocabulary issue, but it's not the part where tokens are
>>> carved out of input text that frighten me, but rather the first level of
>>> interpretation: what entity is that word referring to? More
>>> specifically, dealing with use clauses, prefix notations, overloading,
>>> and stuff like that.
>> 
>> That looks like sematic analysis to me, when you walk the AST finding
>> interpretations for each identifier there, prune matched interpretations
>> for type errors against competing signatures until there is single
>> interpretation for each, or none, or many conflicting. The most horrific
>> part is error messages generation. Which requires kind of mind-reading for
>> programmer's intention.
> 
> My understand is that parsing Ada requires name resolution to resolve
> syntactic ambiguities. This means symbol table management and dealing
> with Ada's visibility rules has to be done while parsing is taking place.
> 
> This probably depends on precisely how one goes about the parse. Perhaps
> it is possible to live with the ambiguity and generate a useful parse
> tree anyway, deferring the rest of the analysis until later, as you say.
> I'm not sure right now but it is something I'll need to figure out soon.

You treat X.Y and X'Y as plain dyadic operators ("." and "'") and
identifiers leaving matching names to the semantics analysis. So, say,

   Ada.Finalization.Limited_Controlled'Class (X)

could become

   ("'" ("." (Ada, Finalization, Limited_Controlled), Class), X)

You need not to know any symbols at this stage, only a fixed set of
operators (".", "+", "-", "abs" etc).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Peter Chapin" <PChapin@vtc.vsc.edu> wrote in message 
news:tYmdnRDwdcBVTz_ORVn_vwA@giganews.com...
...
> My understand is that parsing Ada requires name resolution to resolve
> syntactic ambiguities.

Definitely not. Janus/Ada uses a table-driver parser that has absolutely no 
semantic information. There has to be a bit of care in tokenizing (for the 
infamous T'('A') example) but parsing is completely normal.

> This means symbol table management and dealing
> with Ada's visibility rules has to be done while parsing is taking place.

Certainly not. Janus/Ada is in fact structured into separate programs for 
parsing and semantic analysis (that's how we managed to get a compiler to 
fit on 56K Z80 machines back in the day -- the parse table took up much of 
the 56K, so there was no way to have a symbol table at the same time). We 
have a couple of "helps" in the parser for the later passes; the main one is 
numbering blocks and exception handlers, along with some capturing of labels 
[as their visibility occurs before their declaration], but otherwise it is 
free of context.

                                       Randy.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnlq54jv.i0l.lithiumcat@nat.rebma.instinctive.eu...
...
> Maybe it's a vocabulary issue, but it's not the part where tokens are
> carved out of input text that frighten me, but rather the first level of
> interpretation: what entity is that word referring to? More
> specifically, dealing with use clauses, prefix notations, overloading,
> and stuff like that.

That's the semantics.

> Am I mistaken in assuming an ASIS  provider takes care of that part as
> well?

It's supposed to, but there are enough holes that I suspect it will not be 
easy to use.

> To clarify, I'm currently only contemplating doing the simplest
> ASIS-to-LLVM-intermediate-form translator.

 That sounds like a week's work to me. :-) Well, it would be if ASIS made 
much sense, but the missing information about types and the like will make 
it into hell. I doubt there would be much advantage to starting from ASIS as 
opposed to a raw parse tree, and having your own parser would help a lot in 
the goal of making a separate compiler family. (Depending on the GNAT 
front-end to make your ASIS information is not exactly going to wean anyone 
from GNAT.)

                                            Randy.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnlq55o1.i0l.lithiumcat@nat.rebma.instinctive.eu...
...
> If their current real projects target Android UI, iOS, "smart home", SDR
> boards, etc, after having played with Ada they would reluctantly shelf
> it in favor of a language that actually does the job. Just like me in my
> hypothetical alternate history above.

Sadly, most of those environments are closed or practically so and will 
never have a place for Ada for that reason. (Apple doesn't really allow 
other languages in the app store, so there's almost no point in building an 
iOS app in Ada, even if it is technically possible. And so it goes.) Not to 
mention that a less structured language has an advantage in an environment 
where trial-and-error is the only way that software can be developed. (The 
truly bad thing is that even when an app is good enough, the authors think 
that they have to improve it, which of course leads to it becoming much 
worse over time. I find that I had to get different apps for my new phone 
because the latest versions of some of the old mainstays have become 
unusable, no longer doing the one thing that they were downloaded for.)

                                            Randy.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Robert A Duff]

Peter Chapin <PChapin@vtc.vsc.edu> writes:

> My understand is that parsing Ada requires name resolution to resolve
> syntactic ambiguities.

Yes.  The syntax rules given in the RM are ambiguous.  For example, in a
context expecting an expression, "X(Y)" could be a function_call,
type_conversion, indexed_component, or slice.  (Did I forget any?)
Likewise, in statement context, that same text could be a procedure_call
or an entry_call.

The "X" in "X.Y" could be a name or an implicit_dereference.

But...

>...This means symbol table management and dealing
> with Ada's visibility rules has to be done while parsing is taking place.

But no, it doesn't mean that, and in fact mixing semantic analysis with
parsing is highly undesirable.  The parser should build a tree, and not
any "symbol table" kinds of things.  The output of the parser should
depend ONLY on the contents of a single source file; it shouldn't need
to know about separate compilation.

Semantic analysis then walks the tree built by the parser.

The way to deal with an expression "X(Y)" is for the parser to build a
tree node that represents "something that looks like a call or a
type_conv or ...".  That is, "a name followed by a parenthesized,
comma-separated sequence of expressions".  That has been called an
"Apply" node in some compilers.

Basically, you need to write a grammar for Ada that is unambiguous, and
that allows a superset of what the RM grammar allows.

When semantic analysis sees an Apply node for X(Y), it looks up X and Y.
It might find X denotes a type, or denotes one or more functions,
or ....

I've done serious work on about 7 or 8 Ada compilers, and this is how
ALL of them worked.  (Here, I'm counting independently designed compiler
front ends, not different host/target platforms.  That is, GNAT counts
as "1 Ada Compiler" I've worked on, even though it supports many
platforms.)

> This probably depends on precisely how one goes about the parse. Perhaps
> it is possible to live with the ambiguity and generate a useful parse
> tree anyway, deferring the rest of the analysis until later, as you say.

Yes, I think that's what I was saying above.

C compilers typically work the other way (mixing parsing with semantic
analysis), to solve syntactic ambiguities related to "typedef".
IMHO any language that forces that design on a compiler is broken.
I'm not sure C forces that design; maybe the typedef problem could
be solved differently, but it doesn't look easy to me.

> I'm not sure right now but it is something I'll need to figure out soon.

- Bob

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Luke A. Guest]

"Randy Brukardt" <randy@rrsoftware.com> wrote:
(Apple doesn't really allow 
> other languages in the app store, so there's almost no point in building an 
> iOS app in Ada, even if it is technically 

Apple lifted this restriction a while ago to allow any language that can
compile to the same binary form. Interpreted apps have to package up the
interpreter and libs.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Adam Beneschan]

On Thursday, June 19, 2014 2:13:19 PM UTC-7, Robert A Duff wrote:

> Yes.  The syntax rules given in the RM are ambiguous.  For example, in a
> context expecting an expression, "X(Y)" could be a function_call,
> type_conversion, indexed_component, or slice.  (Did I forget any?)
> 
> Likewise, in statement context, that same text could be a procedure_call
> or an entry_call.

I'm not sure where entry families fit into the above, but that's another possibility.

                             -- Adam

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-19, Peter Chapin <PChapin@vtc.vsc.edu> wrote:
> Actually a "strategic" goal of my project is to make people from both
> communities aware of each other. While the Ada people here tend to say,
> "why would you want to use [insert name of some non-Ada language] for
> anything?"

I find myself thinking more and more often in those terms (except
always at the first person, I'm not claiming anything for anybody else),
a bit to my surprise.

It's just that Ada is so good in its explicitness, readability,
maintainability and reliability that I find myself reluctant to give up
such comfort.

(And I fully agree that Ada is far from perfect, it's just much more
comfortable to use than all the other languages I've come across.)

>            I'm about 100% sure the Scala people on the other side would
> say, "Ada? Huh...?" However, in my view both are fine languages, each in
> its own way, and it would be cool to bring the communities together even
> if only in some small manner.

We'll see how it goes, at least it can't hurt :-)

> In any case, I certainly am not claiming that my project will provide
> any useful degree of compiler diversity... at least not in the
> foreseeable future.

Well, I'm not claiming mine will either, I just foolishly hope it will.


Natasha

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-19, Lucretia <laguest9000@googlemail.com> wrote:
> On Thursday, 19 June 2014 08:22:08 UTC+1, Natasha Kerensikova  wrote:
>
>> So there is no fun hobby in my projects, only means to various ends.
>> (For example my soon-to-be-published Ada bindings to Renderman
>> Interface is a means to my fun hobby of computer graphics).
>
> Now that's a potentially killer application, shame it's not written
> entirely in Ada, but we can blame Apple/Pixar for that :P

I'm not sure what Apple has to do with that, but indeed, Annex E would
be lovely for such an applicaiton.

However, having seen Aqsis, Pixie and Appleseed, I would put it on a
similar hugeness scale as an Ada compiler, an OS or a web browser.


Natasha

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-19, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
> news:slrnlq54jv.i0l.lithiumcat@nat.rebma.instinctive.eu...
> ...
>> To clarify, I'm currently only contemplating doing the simplest
>> ASIS-to-LLVM-intermediate-form translator.
>
>  That sounds like a week's work to me. :-)

Great, so it might take slightly less than a lifetime to me \o/

>                                            Well, it would be if ASIS made 
> much sense, but the missing information about types and the like will make 
> it into hell.

Now that's a serious downer. But I guess I will be able to judge it by
myself when I know ASIS a bit better.

>               I doubt there would be much advantage to starting from ASIS as 
> opposed to a raw parse tree, and having your own parser would help a lot in 
> the goal of making a separate compiler family. (Depending on the GNAT 
> front-end to make your ASIS information is not exactly going to wean anyone 
> from GNAT.)

Well the plan was not to depend on ASIS-on-GNAT, but on Gela, which I
understood was an implementation completely independent from GNAT
(though I haven't checked myself).

The way I understand the whole situation is that ASIS provider diversity
would be a good thing too (though not as much as compiler diversity),
and Gela is not too far from there, so pushing Gela forward would be a
good thing both globally and for my self-improvement.

If that succeeds, it might be a good start for an independent Ada
compiler, or I might have acquired the certainty that it's not. Then the
ASIS-to-LLVM-intermediate-form vs brand-new-parser-to-LLVM-IF situation
will be much easier to assess, and in the meantime I will have acquired
knowledge and skills that are valuable for both paths.

Sounds good?


Natasha

Re: a new language, designed for safety !

[Georg Bauhaus]

On 18/06/14 18:39, Dmitry A. Kazakov wrote:
> On Wed, 18 Jun 2014 16:43:55 +0200, G.B. wrote:
>
>> On 18.06.14 14:30, Dmitry A. Kazakov wrote:
>>> On Wed, 18 Jun 2014 11:34:01 +0200, G.B. wrote:
>>>
>>>> (Pardon? A contract is a manifest piece from the equivalence
>>>> class of paper, signed by two parties.
>>>
>>> And that does not defines the parties it only constrains them, which was
>>> the point.
>>
>> In fact, you declared "contract" to be a
>>
>> "framework of constraints imposed on the implementations"
>>
>> which a contract between two legal parties is not.
>
> Legal parties? What are you talking about?

Contracts (the real ones) and liability.

Not about the term that has not even been hijacked by the language
designers---the LRM has "generic contract model" only---but about
those legal terms to which extended assertions (LRM) are a subordinate
means to an end: software business, and programers employed.

The use of "contract" is not just metaphorical, not just an analogy,
not just an abbreviation.
   I only wanted to point out that the reason of existence of
those extended assertions in Ada can be seen as related to liability
(via real contracts), not, however, as a definition of "contract".

In particular, whenever buyers of software want liability then they
are buyers, not logicians. A bargain means application of contract law.

If you think that the term "contract" should be defined by your
notion of impossibly exhaustive formal semantics, then it will
be difficult to see a point beyond artificial and tautologous
linguistic confusion. You'd substitute a notion (contract) with
some of its remote consequences in Ada (extended assertions).

I think it helps make things clearly defined if "contract" continues
to stand for what is has been standing for generations, and that
words form the LRM in the context of assertions be used for what they
cover, not for replacing a notion, "contract" rather than serve it.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[anon]

First, for the client the priority of "Safety" falls below 
"Data Integrity" and "Performance".  And for a gamer type of 
client its "Performance" and "Functionally" then "Data Integrity" 
and before "Safety". Just to give an example of how some
non-programmers feel.

Now for a compiler. its easier than most here thanks, and it is 
even easier if you use Ada itself. 

Step 1: remove OPP packages which will reduce the libraries
that are needed to the bare minimum.

Create and add the Opps packages back later once the compiler 
is working for everything else. And since OPPs does not require 
any system connections you could simply use GNAT's OPP packages 
during the testing phases, before writing your own set.


Note 0: All coding outside Lexical Analysis should use the BNF in 
"Annex P" starting with 10.1.1.

Step 2: Create the "Lexical" and "Syntactic" routines with 
Error report.

Note 1: If you write your compiler right then the "Aggregate" 
routines will become the most important routine in the Semantic 
Analysis. This is because a lot Ada code within parenthesis can 
be process as an aggregate or modified aggregate routine. An 
example list:

     argument_association              -- within pragma statement
     aggregate
     qualified_expression              -- can uses aggregate
     enumeration_type_definition
     index_constraint                  -- no "choice"
     discriminant_constraint           -- Choice is simple name
     indexed_component                 -- after prefix
     slice                             -- after prefix
     parameter_association
     actual_parameter_part
     entry_declaration                 -- after prefix, no "choice"
     entry_call_statement              -- after prefix, no "choice"
     generic_actual_part
     enumeration_representation_clause -- uses an aggregate
     code_statement                    -- uses a record aggregate


     -- modified replacing the arrow with assignment

     component_list
     discriminant_part
     discriminant_specification
     formal_part

     -- modified for "when" could handle
     -- and the expression can be sequence_of_statements

     variant
     case_statement_alternative
     formal_part
     entry_declaration
     entry_call_statement
     select_alternative
     exception_handler



Step 3: Semantic Analysis should be dome in two or three phases.


    Phase 1: Type checking, such as 

             type identifier is range 
                        simple_expression .. simple_expression

             In this case both simple_expressions must be 
             integer. And in some case you can determine if 
             expression is static (required or integer type).

    Phase 2: Range checking.  Add code to do range checking.

             In the compile I created that was a problem since 
the lower and upper ranges are not defined by the hardware, but 
by the programmer.  In other words you could define a number as

             --  a foolishly large integer 

             type Sample_Integer is range 
                     - 2 ** ( 2 ** 32 )  .. 2 ** ( 2 ** 32 ) - 1 ;

             -- or a real, in this case the compiler generates 
             -- lower and upper bounds

             type Sample_Float is digits 32767 ;

Even though the line length (RM 2.2 (15)) shall exceed 199 
characters, the compiler may have limits such as setting the 
token size to 80 characters. And forcing a limit on token size 
will force an internal compiler storage limit. Which in turn does 
force source code limits but not programming limits.

The reason I did this was to see if a compiler could truly allow
universal_integer and universal_reals and still be functional with 
only limited performance loss.


    Phase 3: Maintain a Data Dictionary instead of recalculating
types in "Code Generation". Saves compile time


Step 4: First Optimization, to reduce dead code. 

        While GNAT will report generate a warning message for 
unreference variables it does not report unreference routines. Here 
there are three options: 
            A) do nothing, 
            B) perform only if "pragma Optimize (Space)" is used 
            C) just automatically remove all dead code.

In the two later cases, this process can be simple.

Step 5: Expansion. Where "Generic" evaluated and new packages are 
created.  And complex structures are rewritten to simpler 
structures, then in some cases "Semantic" may need to be repeated 
for these routines or structures.

Step 6: Second Optimization, for speed of code. For GNAT this is 
done by the GCC back_end, which exceeds the Optimization defined 
in the RM. Here there are four options:

    A) do nothing, 
    B) perform only if "pragma Optimize (Time)" is used, 
    C) use a implementation created pragma to define Optimization
such as  "pragma Optimization ( <numeric-level> )". Then perform 
optimization at the level requested.  Could also be a command-line
option.

    D) automatically optimize code. 

Initial it is easier and faster to "do nothing" except for may be 
adding a dummy routine that can be modified later once the 
compiler works.

Step 7: Code Generation: 

If the compiler generate code based on the system configuration 
identifiers. "System_Name", "Storage_Unit" and "Memory_Size" 
Which are located in System package and can be modified by 
using one or more configuration pragmas which can alter these 
identifiers.

These configurational identifiers allow the compiler to perform
cross-compiling for different CPU and systems such as bare, Linux
or Windows and can include Apple OS, or other OS.  By loading 
using libraries to set opcodes and calls for specific CPU/OS or 
bare board.



Note 2: Use the ACVC files for your Testsuite. Helps to make 
compiler ACVC compliant from the start.


Just a Suggestion:

Since you will have to write your version of the Ada libraries such 
as "Ada.Text_IO" write it and the rename the new library to 
"Compiler.Text_IO" and etc. Then use "Compiler.Text_IO" instead of 
"Ada.Text_IO". Later if you want use can spend a few minutes 
changing "Compiler." to "Ada.".

As for using GNAT, the GPL only effects your code if you link to the 
GNU or GNAT libraries, such "Ada.Text_IO" code generation does not 
force the code to be under GPL, unless you use GNAT version of 
"Ada.Text_IO". Otherwise, GNU would own all intellectual property of 
all codes use by its compilers and that's not legal. 


Note 3. Using GNAT's obsolete pragma "pragma No_Run_time" removes 
access to most GNAT's libraries. So, it will force you to use your 
own packages instead of GNAT's.





In <erb49jp6qy6n$.5cesca6do7x3$.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>On Wed, 18 Jun 2014 17:34:35 +0000 (UTC), Natasha Kerensikova wrote:
>
>> For some reason I'm much more frightened by parsing Ada text than by
>> code generation. I know the latter is probably not easier than the
>> former (I'm aware of LLVM vs nested functions), but who said fright is
>> rational?
>
>Oh, but parsing is really simple thing. You do recursive descent all the
>time. Except for expressions. For expressions you could take this:
>
>http://www.dmitry-kazakov.de/ada/components.htm#12.9
>
>Semantic analysis is a hell. Code generation, optimization is a hell within
>hell, IMO.
>
>-- 
>Regards,
>Dmitry A. Kazakov
>http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Lucretia]

On Friday, 20 June 2014 08:07:08 UTC+1, Natasha Kerensikova  wrote:

> > Now that's a potentially killer application, shame it's not written
> > entirely in Ada, but we can blame Apple/Pixar for that :P
> 
> I'm not sure what Apple has to do with that, but indeed, Annex E would
> be lovely for such an applicaiton.

Well Steve Jobs owned a large part of Pixar, I think it's now owned by Apple.

> However, having seen Aqsis, Pixie and Appleseed, I would put it on a

Never heard of any of those, but just looked, all look impressive.

> similar hugeness scale as an Ada compiler, an OS or a web browser.

Start small then :D

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Lucretia]

On Friday, 20 June 2014 10:54:58 UTC+1, an...@att.net  wrote:

It's a shame you refuse to allow your name to show up, as we don't have any clue who we're talking to here.

> Step 1: remove OPP packages which will reduce the libraries
> that are needed to the bare minimum.
> 
> Create and add the Opps packages back later once the compiler 
> is working for everything else. And since OPPs does not require 
> any system connections you could simply use GNAT's OPP packages 
> during the testing phases, before writing your own set.

What the hell are you gibbering on about here? What's an OPP package?

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dennis Lee Bieber]

On Fri, 20 Jun 2014 04:44:19 -0700 (PDT), Lucretia
<laguest9000@googlemail.com> declaimed the following:

>On Friday, 20 June 2014 08:07:08 UTC+1, Natasha Kerensikova  wrote:
>
>> > Now that's a potentially killer application, shame it's not written
>> > entirely in Ada, but we can blame Apple/Pixar for that :P
>> 
>> I'm not sure what Apple has to do with that, but indeed, Annex E would
>> be lovely for such an applicaiton.
>
>Well Steve Jobs owned a large part of Pixar, I think it's now owned by Apple.
>
	Owned by a mouse, not a fruit... Disney bought Pixar which made Jobs
one of the largest Disney stockholders... Don't know who got his shares
now...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ada platforms and pricing, was: Re: a new language, designed for

[anon]

OPP OPPs-- Object Programming Package(s), Most here would say OOP package 
or OOP packages but that sounds like someone made a mistake.

OOP -- "Object-oriented programming", is a programming technique not a 
package.

Examples of OPPs ::=  "Ada.Containers" "Ada.Containers.*"
                       "Ada.Tags"

Plus, to me "Object-oriented programming" should of always had it own 
parent in Ada. May be, using "OOP" parent instead of using "Ada"

In <526a2abd-8720-48ba-b2c1-7b5b94b05902@googlegroups.com>, Lucretia <laguest9000@googlemail.com> writes:
>On Friday, 20 June 2014 10:54:58 UTC+1, an...@att.net  wrote:
>
>It's a shame you refuse to allow your name to show up, as we don't have any clue who we're talking to here.
>
>> Step 1: remove OPP packages which will reduce the libraries
>> that are needed to the bare minimum.
>> 
>> Create and add the Opps packages back later once the compiler 
>> is working for everything else. And since OPPs does not require 
>> any system connections you could simply use GNAT's OPP packages 
>> during the testing phases, before writing your own set.
>
>What the hell are you gibbering on about here? What's an OPP package?

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnlq7oge.i0l.lithiumcat@nat.rebma.instinctive.eu...
...
> The way I understand the whole situation is that ASIS provider diversity
> would be a good thing too (though not as much as compiler diversity),
> and Gela is not too far from there, so pushing Gela forward would be a
> good thing both globally and for my self-improvement.

That would work, of course, but all of the hard stuff (well, almost all) 
would be in the GELA ASIS front-end. And you'd have to do frequent 
maintenance on the ASIS stuff if you wanted to actually compile Ada (as 
almost every bug would be in the ASIS part). It certainly could work, but it 
would mean having to understand the GELA ASIS code in detail (not just the 
interface). For me, I'd rather fix my own code than someone else's.

> If that succeeds, it might be a good start for an independent Ada
> compiler, or I might have acquired the certainty that it's not. Then the
> ASIS-to-LLVM-intermediate-form vs brand-new-parser-to-LLVM-IF situation
> will be much easier to assess, and in the meantime I will have acquired
> knowledge and skills that are valuable for both paths.
>
> Sounds good?

Sounds possible. "Good" only applies if it works out and something useful 
comes out of it. :-) Else it's just effort that could have been used on 
something working.

                         Randy.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Natasha Kerensikova]

On 2014-06-20, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
> news:slrnlq7oge.i0l.lithiumcat@nat.rebma.instinctive.eu...
> ...
>> The way I understand the whole situation is that ASIS provider diversity
>> would be a good thing too (though not as much as compiler diversity),
>> and Gela is not too far from there, so pushing Gela forward would be a
>> good thing both globally and for my self-improvement.
>
> That would work, of course, but all of the hard stuff (well, almost all) 
> would be in the GELA ASIS front-end. And you'd have to do frequent 
> maintenance on the ASIS stuff if you wanted to actually compile Ada (as 
> almost every bug would be in the ASIS part). It certainly could work, but it 
> would mean having to understand the GELA ASIS code in detail (not just the 
> interface). For me, I'd rather fix my own code than someone else's.

Funnily, it's the first time I'm warned against re-using code instead of
re-writing it, usually I'm warned against re-writing instead of
re-using.

The thing is, writing an ASIS provider is still frightening me, and I
really thing it's not something I can complete by myself. And if I drop
a re-write attempt, it's a pure loss.

On the other hand, fixing Gela for Adacontrol is within human reach, and
it's already a gain by itself, and might be the best way to assess how
comfortable I would feel about maintaining Gela in Adacontrol and/or
compiler (or other ASIS users) versus starting a new ASIS provider from
scratch.

>> If that succeeds, it might be a good start for an independent Ada
>> compiler, or I might have acquired the certainty that it's not. Then the
>> ASIS-to-LLVM-intermediate-form vs brand-new-parser-to-LLVM-IF situation
>> will be much easier to assess, and in the meantime I will have acquired
>> knowledge and skills that are valuable for both paths.
>>
>> Sounds good?
>
> Sounds possible. "Good" only applies if it works out and something useful 
> comes out of it. :-) Else it's just effort that could have been used on 
> something working.

I meant "does such a plan sound good?". Of course you can't assess
result goodness without knowing how everything turns out. Unfortunately,
decisions have to be taken without knowing how everything turns out.
However, as far as I plans go, it seems I have enough checkpoints and
fallbacks to minimize effort loss while still moving towards meaningful
goals, unless I'm missing something (and my question is really "with
your experience in such endeavors, do you see something I'm missing?").


Thanks for your insights,
Natasha

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-18, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
> message news:lnsqus$d4j$1@dont-email.me...
>> On 2014-06-17, Randy Brukardt <randy@rrsoftware.com> wrote:
>>>
>>> It's impractical to have any such cross-compilers. Every such compiler
>>> (run-time, really) has to be tailored to the specific board in question. 
>>> We
>>> treated each embedded compiler as something that would require extensive
>>> support, and I still think we lost money on each.
>>>
>>
>> You are thinking of this as a monolithic commercial product. Things are
>> much more modular in the open source world.
>
> Not at all. Janus/Ada is structured almost as you describe below:
>

[Apologies for the delay in responding to your message; I forgot to
respond to it.]

I stand corrected. :-)

>> Taking the ARM bare metal (C language) world as an example:
>>
>> 1) At the bottom layer you have the compiler itself. This just generates
>> code for a set of ARM architecture variants such as Cortex-M3 and
>> Cortex-A8 as well as older ARM architecture variants such as the ARMv5
>> variants. It has absolutely no knowledge of any specific MCU or any
>> board which that MCU might be placed on. Things like memory layouts
>> are handled in linker scripts.
>
> Yup. But no one can do anything useful with such a thing. It's trivial to 
> take a version of Janus/Ada and use it as a cross-compiler for some board. 
> But without a runtime, hardware support, and the like, only the most 
> dedicated people could use it for anything.
>

To me, I mentally split the problem into two categories: The support
for Ada language functionality and the support for peripherals on the
specific board. I regard only the first part as really a part of the
actual compiler, but it is a required part.

However, my feeling is that the Ada RTL support, once implemented, is
pretty generic within a MCU architecture and is not really board
specific.

You may need some configuration and interface options for things like
I/O operations, with calls to user supplied I/O packages. These packages
would only concern themselves with the lowest level, interfacing to
the hardware itself and not provide any generic Ada RTL support.

In these user supplied packages, I'm thinking about things like an Ada
version of, say, putchar() which would just output the passed character
to some hardware device without concerning itself about anything other
than that.

>> 2) At the next layer up you have code to support a specific MCU. As
>> well as MCU specific startup code, this includes things like interrupt
>> handling which is MCU specific in the ARM world. This code generally
>> comes from the manufacturer of the MCU and is usually free.
>
> But it's probably not in a form that could be used for Ada. Certainly not 
> unless you're planning to require having an C compiler around as well (not 
> really good marketing for Ada).
>

There is some C code at the very lowest level of GNAT.

>> I don't know about Luke, but when I talk about Ada cross compilers,
>> I'm only really thinking about the first part (the compiler itself)
>> although you will probably need to add in Ada specific initialisation
>> code into the MCU startup code. Provided the calls into the Ada RTL
>> are cleanly documented then that's not a problem for me.
>
> You'd be very much in the minority. Remember, for the sorts of people you 
> are talking about, the compiler is going to have to work pretty much out of 
> the box, as the normal person isn't going to have the Ada knowledge needed 
> to write a runtime for a particular board.
>

I don't really see the support for the peripherals as part of the
compiler as such. For example, the various MCU and board manufacturers
may provide their own bare metal support package for a board and all
you need to do is download it from their website and build it with your
own C compiler; it's not expected to be a part of gcc.

I wonder if a halfway house could be like the situation with RTEMS.
RTEMS is written in C and so are the BSPs. However, you can run your
Ada code on top of RTEMS.

IOW, create a Ada binding to the manufacturer's code and just use Ada
for your own code. While it would really be nice to have Ada code top
to bottom, this is really no different than, say, Linux when you are
running Ada code on a C base.

I suppose it also depends on the type of hobbyist. There are some who are
as you describe and just want the complete package. There are also people
like me who just need a compiler with some core language functionality and
can then get to work reading the datasheets if the code does not exist
or is not suitable.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

I don't see anything obviously wrong with this plan. As you probably can 
tell, I'm no fan of ASIS (it's way too syntax based for the sorts of uses I 
would want to put it toward), but that doesn't necessarily make it a bad 
starting point, especially if you're more familar with using it in practice 
than I am. You will have to be prepared to maintain the GELA ASIS code, 
because you're inevitiably going to hit bugs in it.

                      Randy.

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnlqagv4.i0l.lithiumcat@nat.rebma.instinctive.eu...
> On 2014-06-20, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message
>> news:slrnlq7oge.i0l.lithiumcat@nat.rebma.instinctive.eu...
>> ...
>>> The way I understand the whole situation is that ASIS provider diversity
>>> would be a good thing too (though not as much as compiler diversity),
>>> and Gela is not too far from there, so pushing Gela forward would be a
>>> good thing both globally and for my self-improvement.
>>
>> That would work, of course, but all of the hard stuff (well, almost all)
>> would be in the GELA ASIS front-end. And you'd have to do frequent
>> maintenance on the ASIS stuff if you wanted to actually compile Ada (as
>> almost every bug would be in the ASIS part). It certainly could work, but 
>> it
>> would mean having to understand the GELA ASIS code in detail (not just 
>> the
>> interface). For me, I'd rather fix my own code than someone else's.
>
> Funnily, it's the first time I'm warned against re-using code instead of
> re-writing it, usually I'm warned against re-writing instead of
> re-using.
>
> The thing is, writing an ASIS provider is still frightening me, and I
> really thing it's not something I can complete by myself. And if I drop
> a re-write attempt, it's a pure loss.
>
> On the other hand, fixing Gela for Adacontrol is within human reach, and
> it's already a gain by itself, and might be the best way to assess how
> comfortable I would feel about maintaining Gela in Adacontrol and/or
> compiler (or other ASIS users) versus starting a new ASIS provider from
> scratch.
>
>>> If that succeeds, it might be a good start for an independent Ada
>>> compiler, or I might have acquired the certainty that it's not. Then the
>>> ASIS-to-LLVM-intermediate-form vs brand-new-parser-to-LLVM-IF situation
>>> will be much easier to assess, and in the meantime I will have acquired
>>> knowledge and skills that are valuable for both paths.
>>>
>>> Sounds good?
>>
>> Sounds possible. "Good" only applies if it works out and something useful
>> comes out of it. :-) Else it's just effort that could have been used on
>> something working.
>
> I meant "does such a plan sound good?". Of course you can't assess
> result goodness without knowing how everything turns out. Unfortunately,
> decisions have to be taken without knowing how everything turns out.
> However, as far as I plans go, it seems I have enough checkpoints and
> fallbacks to minimize effort loss while still moving towards meaningful
> goals, unless I'm missing something (and my question is really "with
> your experience in such endeavors, do you see something I'm missing?").
>
>
> Thanks for your insights,
> Natasha 

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lo7c2h$ura$1@dont-email.me...
> On 2014-06-18, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
>> message news:lnsqus$d4j$1@dont-email.me...
>>> On 2014-06-17, Randy Brukardt <randy@rrsoftware.com> wrote:
>>>>
>>>> It's impractical to have any such cross-compilers. Every such compiler
>>>> (run-time, really) has to be tailored to the specific board in 
>>>> question.
>>>> We
>>>> treated each embedded compiler as something that would require 
>>>> extensive
>>>> support, and I still think we lost money on each.
>>>>
...
>>> Taking the ARM bare metal (C language) world as an example:
>>>
>>> 1) At the bottom layer you have the compiler itself. This just generates
>>> code for a set of ARM architecture variants such as Cortex-M3 and
>>> Cortex-A8 as well as older ARM architecture variants such as the ARMv5
>>> variants. It has absolutely no knowledge of any specific MCU or any
>>> board which that MCU might be placed on. Things like memory layouts
>>> are handled in linker scripts.
>>
>> Yup. But no one can do anything useful with such a thing. It's trivial to
>> take a version of Janus/Ada and use it as a cross-compiler for some 
>> board.
>> But without a runtime, hardware support, and the like, only the most
>> dedicated people could use it for anything.
>>
>
> To me, I mentally split the problem into two categories: The support
> for Ada language functionality and the support for peripherals on the
> specific board. I regard only the first part as really a part of the
> actual compiler, but it is a required part.
>
> However, my feeling is that the Ada RTL support, once implemented, is
> pretty generic within a MCU architecture and is not really board
> specific.

That's not my experience. Remember that "basic Ada support" includes things 
like timers (Ada.Real_Time, delay statements), some method of handling 
exceptions (which generally means supporting hardware traps), and usually 
tasking (which means some method of context switching).

All of these require interrupt support on bare boards, and that never seems 
to be quite the same from board to board.

There's certainly a shared part, but the configurations are different for 
each board. And you have to be pretty familar with the boards in order to do 
those; your average tinkerer isn't likely to be able to do that.

> You may need some configuration and interface options for things like
> I/O operations, with calls to user supplied I/O packages. These packages
> would only concern themselves with the lowest level, interfacing to
> the hardware itself and not provide any generic Ada RTL support.
>
> In these user supplied packages, I'm thinking about things like an Ada
> version of, say, putchar() which would just output the passed character
> to some hardware device without concerning itself about anything other
> than that.

Fair enough. I found back in the day that you had to be able to connect that 
with Text_IO for useful output (for instance, the crash messages from the 
Janus/Ada runtime). But that's clearly a secondary need. I wasn't thinking 
about full I/O support, for instance, since it usually doesn't make sense in 
that environment.

>>> 2) At the next layer up you have code to support a specific MCU. As
>>> well as MCU specific startup code, this includes things like interrupt
>>> handling which is MCU specific in the ARM world. This code generally
>>> comes from the manufacturer of the MCU and is usually free.
>>
>> But it's probably not in a form that could be used for Ada. Certainly not
>> unless you're planning to require having an C compiler around as well 
>> (not
>> really good marketing for Ada).
>>
>
> There is some C code at the very lowest level of GNAT.

Sure, but it's compiled; you don't need a C compiler in order to be able to 
use GNAT. If you require people to use C code in their setup, they'll need 
to get the C compiler working first. At that point, most people will wonder 
why they're spending time to get Ada working rather than working on their 
project (the fun part, hopefully).

...
> I don't really see the support for the peripherals as part of the
> compiler as such. For example, the various MCU and board manufacturers
> may provide their own bare metal support package for a board and all
> you need to do is download it from their website and build it with your
> own C compiler; it's not expected to be a part of gcc.

I'm not talking about "peripherals"; I'm talking about timers and trap 
handlers (for overflow, divide-by-zero, etc.) and the like. These things are 
required for a useful subset of Ada. (No clock and no exceptions means 
you're no longer really doing Ada, just Ada syntax.) I/O is optional, but 
not these other things.

                                  Randy.

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Thu, 05 Jun 2014 11:13:46 +0200, Nasser M. Abbasi <nma@12000.org> a  
écrit:
> Even though some dynamic languages will not let one at run
> time mix apples and oranges, and will give run-time error,
> I'd rather know at compile time that I am not mixing apples
> with oranges. That is much more safe.

Which ones? Dynamic in which ways?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Mon, 23 Jun 2014 02:40:25 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Le Thu, 05 Jun 2014 11:13:46 +0200, Nasser M. Abbasi <nma@12000.org> a  
> écrit:
>> Even though some dynamic languages will not let one at run
>> time mix apples and oranges, and will give run-time error,
>> I'd rather know at compile time that I am not mixing apples
>> with oranges. That is much more safe.
>
> Which ones? Dynamic in which ways?
>

Forget the question, I miss‑understood your words (I read it as if there  
was some dynamic languages able to not allow to mix apples and oranges,  
dot).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Shark8]

On 22-Jun-14 18:43, Yannick Duchêne (Hibou57) wrote:
> Le Mon, 23 Jun 2014 02:40:25 +0200, Yannick Duchêne (Hibou57)
> <yannick_duchene@yahoo.fr> a écrit:
>
>> Le Thu, 05 Jun 2014 11:13:46 +0200, Nasser M. Abbasi <nma@12000.org> a
>> écrit:
>>> Even though some dynamic languages will not let one at run
>>> time mix apples and oranges, and will give run-time error,
>>> I'd rather know at compile time that I am not mixing apples
>>> with oranges. That is much more safe.
>>
>> Which ones? Dynamic in which ways?
>>
>
> Forget the question, I miss‑understood your words (I read it as if there
> was some dynamic languages able to not allow to mix apples and oranges,
> dot).

IIRC, Lisp's Error-handling can ensure that types are consistent, even 
though the language itself is dynamically typed.

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Tue, 10 Jun 2014 20:31:07 +0200, Pascal Obry <pascal@obry.net> a écrit:
> Why Apple choose a new language you asked? Yes probably to gain control
> of something...
Their applications underlying model? (may be) Match to their development  
methods? (may be too) Compatibility with some automated analysis tools of  
their own? There may be multiple real reasons.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Nasser M. Abbasi]

On 6/22/2014 7:51 PM, Shark8 wrote:

>
> IIRC, Lisp's Error-handling can ensure that types are consistent, even
> though the language itself is dynamically typed.
>

Julia can do that also, and it is dynamically typed. But for Julia
to check at run-time the types are correct, one must supply the type
expected from an operation. I am newbie in Julia, but I find how its
type system works a bit confusing to me:

julia> x=int8(3)  %decalre x to be int8 type
julia> typeof(x)
Int8

julia> y=int64(300000)   %y is int64
julia> typeof(y)
Int64

julia> y=x   %value of x into y
3

julia> typeof(y) %now y type changed to that of x !
Int8

julia> y=int64(300000);  %lets start again
julia> (y=x)::Int64   %but now add assertion

ERROR: type: typeassert: expected Int64, got Int8

julia> y=x  %without assertion, it works, but type conversion happens
3

So in Julia, the run-time will check the type, but the user
must add assertions ::

--Nasser

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Niklas Holsti]

On 14-06-23 02:38 , Randy Brukardt wrote:
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
> message news:lo7c2h$ura$1@dont-email.me...
>> On 2014-06-18, Randy Brukardt <randy@rrsoftware.com> wrote:
>>> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
>>> message news:lnsqus$d4j$1@dont-email.me...
>>>> On 2014-06-17, Randy Brukardt <randy@rrsoftware.com> wrote:
>>>>>
>>>>> It's impractical to have any such cross-compilers. Every such compiler
>>>>> (run-time, really) has to be tailored to the specific board in 
>>>>> question.
>>>>> We
>>>>> treated each embedded compiler as something that would require 
>>>>> extensive
>>>>> support, and I still think we lost money on each.
>>>>>
> ...
>>>> Taking the ARM bare metal (C language) world as an example:
>>>>
>>>> 1) At the bottom layer you have the compiler itself. This just generates
>>>> code for a set of ARM architecture variants such as Cortex-M3 and
>>>> Cortex-A8 as well as older ARM architecture variants such as the ARMv5
>>>> variants. It has absolutely no knowledge of any specific MCU or any
>>>> board which that MCU might be placed on. Things like memory layouts
>>>> are handled in linker scripts.
>>>
>>> Yup. But no one can do anything useful with such a thing. It's trivial to
>>> take a version of Janus/Ada and use it as a cross-compiler for some 
>>> board.
>>> But without a runtime, hardware support, and the like, only the most
>>> dedicated people could use it for anything.

 [snip]

> ...
>> I don't really see the support for the peripherals as part of the
>> compiler as such. For example, the various MCU and board manufacturers
>> may provide their own bare metal support package for a board and all
>> you need to do is download it from their website and build it with your
>> own C compiler; it's not expected to be a part of gcc.
> 
> I'm not talking about "peripherals"; I'm talking about timers and trap 
> handlers (for overflow, divide-by-zero, etc.) and the like. These things are 
> required for a useful subset of Ada. (No clock and no exceptions means 
> you're no longer really doing Ada, just Ada syntax.) I/O is optional, but 
> not these other things.

While I would like to have the standard Ada tasking, timing, and
exception support, I would most definitely prefer an Ada subset without
them, over C. As I remember, prof. McCormick's experience from the
model-railway exercise (where his students failed when they used C, but
succeeded with Ada) identified Ada's advantage over C to be in the
better scalar typing, not in the features that require a full RTL (but I
don't remember if exceptions were a factor in McCormick's experience).

I am currently working on an Ada project with a null run-time and a
proprietary small multi-threading kernel. But I still feel I am "doing
Ada", although with a different syntax for tasking. All the advantages
of the type and package system are still there, and they are, to me, the
main feature of Ada (in this application domain, at least).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: a new language, designed for safety !

[Shark8]

Interesting; thanks for the examples.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Sun, 22 Jun 2014 18:38:50 -0500, Randy Brukardt wrote:

> I'm not talking about "peripherals"; I'm talking about timers and trap 
> handlers (for overflow, divide-by-zero, etc.) and the like. These things are 
> required for a useful subset of Ada. (No clock and no exceptions means 
> you're no longer really doing Ada, just Ada syntax.) I/O is optional, but 
> not these other things.

You are right. But how a board could be of any use without some peripheral
I/O? Especially when file I/O and networking has already been ruled out!
Deaf-mute chunk of silicon...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 23 Jun 2014 09:18:11 +0300, Niklas Holsti wrote:

> I am currently working on an Ada project with a null run-time and a
> proprietary small multi-threading kernel.

Wouldn't it be helpful to have user-defined tasking for such cases? Because
there is another important case for this - co-routines. When implementing
stuff like network communication (e.g. HTTP servers) and parallel
processing we frequently have a set of state machines (one per connection)
too expensive to handle from OS tasks. Programming a state machine is
turning all design upside down. If there were user-defined task support one
could program this as if it were in proper tasks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Programming a state machine is turning all design upside down. If
> there were user-defined task support one could program this as if it
> were in proper tasks.

I find it easier to think about state machines as state machines rather
than by encoding them using the program counter! I geuss it depends on
your starting point.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[G.B.]

On 23.06.14 09:42, Dmitry A. Kazakov wrote:
> Wouldn't it be helpful to have user-defined tasking for such cases? Because
> there is another important case for this - co-routines.

Will a

   pragma Passive;

allow reuse of existing implementation efforts (at PC-less tasks)?

Re: a new language, designed for safety !

[Peter Chapin]

On 2014-06-22 20:51, Shark8 wrote:

> IIRC, Lisp's Error-handling can ensure that types are consistent, even
> though the language itself is dynamically typed.

It's quite normal for dynamic languages to do type checking, they just
do it at runtime (dynamically). That's practically the definition of
"dynamic language" to my mind. It partly accounts for the flexibility of
such languages as well as their sometimes sluggish performance.

Peter

Re: a new language, designed for safety !

[Dan'l Miller]

On Monday, June 23, 2014 9:17:47 AM UTC-5, Peter Chapin wrote:
> It's quite normal for dynamic languages to do type checking, they just
> do it at runtime (dynamically). That's practically the definition of
> "dynamic language" to my mind. It partly accounts for the flexibility of
> such languages as well as their sometimes sluggish performance.

And for that very reason, it is quite normal at run-time for dynamic languages to surprisingly raise fatal errors on some rarely-executed branch---hence the disdain earlier in this thread for not checking at compile-time whether a method can be invoked for a target object.  Check for such flagrant omissions-of-design at compile-time, not at run-time.

Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 23 Jun 2014 10:17:47 -0400, Peter Chapin wrote:

> On 2014-06-22 20:51, Shark8 wrote:
> 
>> IIRC, Lisp's Error-handling can ensure that types are consistent, even
>> though the language itself is dynamically typed.
> 
> It's quite normal for dynamic languages to do type checking, they just
> do it at runtime (dynamically). That's practically the definition of
> "dynamic language" to my mind. It partly accounts for the flexibility of
> such languages as well as their sometimes sluggish performance.

and bugs, because this is not type checking. It is checking for a subtype
constraint. A type in such a language corresponds to Ada's subtype. The
check for an operation to exist corresponds to Ada's constraint check or
tag check as in an operation with two controlled arguments.

Just like in Ada, if the failure of the check means a bug, then it is a
bug, because you are at run-time and you didn't anticipate it. BOOM!

No dynamic can ever prevent a bug. It is just too late. What a dynamic
check can is to reduce the damage of a bug. E.g. to blow up the rocket
before it landed on the developer's head.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 23 Jun 2014 12:17:38 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Programming a state machine is turning all design upside down. If
>> there were user-defined task support one could program this as if it
>> were in proper tasks.
> 
> I find it easier to think about state machines as state machines rather
> than by encoding them using the program counter! I geuss it depends on
> your starting point.

As an example consider reading from a stream without blocking. When there
is no more data available you switch to another co-routine (reading another
stream). This is programmed as if reading from the stream was blocking. The
co-routine is continued when more data become available. On top of these
stream could be a mountain of protocols or a whole Ada compiler taking the
stream as a source. Doing this as a state machine, upside-down driven by
incoming characters would be extremely tedious.

The idea of user-defined tasking is that the user would also provide the
pool to allocate the task stack and would activate/deactivate his tasks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dan'l Miller]

On Monday, June 23, 2014 12:14:24 PM UTC-5, Dmitry A. Kazakov wrote:
> On Mon, 23 Jun 2014 12:17:38 +0100, Simon Wright wrote:
> > "Dmitry A. Kazakov" writes:
> >> Programming a state machine is turning all design upside down. If
> >> there were user-defined task support one could program this as if it
> >> were in proper tasks.
> 
> > I find it easier to think about state machines as state machines rather
> > than by encoding them using the program counter! I geuss it depends on
> > your starting point.

In the spirit of lambasting the lack of direct representation of finite-state machines (FSMs) in Ada:

  A programmer should not need to go through mental gymnastics to represent a crystal-clear analysis construct (e.g., an FSM) in some sort of contortion just because someone in 1978 omitted it from an excessively-sequential imperative programming language because excessively-sequential imperative programming languages encouraging vast call-trees of subroutines per thread of execution were in vogue during the 1970s and adjacent decades.

Perhaps Ada202X can do something more than mere dotting of "i"s and crossing of "t"s so as to provide a direct intuitive representation of FSMs within Ada (assuming that Ada does not already have such an intuitive design idiom for FSMs, as potentially explored below).  Direct intuitive representation of FSMs would be highly useful in Ada's historically-most-frequent deployments:  embedded realtime systems interacting with hardware.  The Ada202X compiler could mathematically-prove some aspects of sanity of the FSM, giving compile-time errors for certain categories of glaring design errors in the FSM a la the numerous other compile-time assurances for safety-critical systems that are already part of Ada.  (Plus it would give Ada a special sauce that very few other compiled languages have in either its core language or in its standard library, Erlang & C++'s Boost notwithstanding.  Btw, Ada does need a few more claims to fame to be competitive with the other current programming-language darlings that get asked to dance on the dance-floor more often than Ms. Ada does.  Direct intuitive representation of FSMs with compile-time error-checking [as a directed graph in graph-theory] could be one of those claims to fame.)

> As an example consider reading from a stream without blocking. When there
> is no more data available you switch to another co-routine (reading another
> stream). This is programmed as if reading from the stream was blocking. The
> co-routine is continued when more data become available. On top of these
> stream could be a mountain of protocols or a whole Ada compiler taking the
> stream as a source. Doing this as a state machine, upside-down driven by
> incoming characters would be extremely tedious.
> 
> The idea of user-defined tasking is that the user would also provide the
> pool to allocate the task stack and would activate/deactivate his tasks.

In the spirit of humbly learning something new and appreciating any potential beauty:

  Dmitry, do you advocate the use of "co-routines" (as Ada tasks, if I understand you correctly) for the modeling of arbitrarily-complex finite-state machines (FSMs)?  If so (and if it scales), perhaps you can explain the design idiom more completely so that it handles FSMs of arbitrary complexity.  Or perhaps you can provide a URL to an academic paper that describes representing FSMs of arbitrary complexity via "co-routines".

It seems that your usage here of "co-routines" to represent FSMs somewhat resembles C.A.R. Hoare's monitors, but perhaps I am taking your "co-routines" in a different direction than you intend.  If resembling Hoare's monitors (or POSIX's condition variables) [and assuming that each Ada task in the set of co-routines takes on the role of each state in an FSM], how does this idiom scale well in so far as not having immensely-complex conditional-branching tests for representing each task's/state's traversal of a link/edge in arbitrarily-complex FSMs.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1vrc8mmlbvd6f$.1vak7oiubwsaj$.dlg@40tude.net...
> On Sun, 22 Jun 2014 18:38:50 -0500, Randy Brukardt wrote:
>
>> I'm not talking about "peripherals"; I'm talking about timers and trap
>> handlers (for overflow, divide-by-zero, etc.) and the like. These things 
>> are
>> required for a useful subset of Ada. (No clock and no exceptions means
>> you're no longer really doing Ada, just Ada syntax.) I/O is optional, but
>> not these other things.
>
> You are right. But how a board could be of any use without some peripheral
> I/O? Especially when file I/O and networking has already been ruled out!
> Deaf-mute chunk of silicon...

Right, but I was thinking of the rather elaborate language-defined I/O 
facilities. I doubt that there is much use for Ada.Directories on the 
typical embedded board. You need some sort of low-level facilities tailored 
for the devices, it often makes as much sense for the programmer to provide 
those as the compiler vendor. Perhaps some package of very low-level 
facilities would help (hopefully one that could be per-CPU architecture as 
opposed to per-board), but that's it and that would not have much to do with 
Ada per-se.

                                    Randy.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 23 Jun 2014 12:21:11 -0700 (PDT), Dan'l Miller wrote:

> On Monday, June 23, 2014 12:14:24 PM UTC-5, Dmitry A. Kazakov wrote:
>> On Mon, 23 Jun 2014 12:17:38 +0100, Simon Wright wrote:
>>> "Dmitry A. Kazakov" writes:
>>>> Programming a state machine is turning all design upside down. If
>>>> there were user-defined task support one could program this as if it
>>>> were in proper tasks.
>> 
>>> I find it easier to think about state machines as state machines rather
>>> than by encoding them using the program counter! I geuss it depends on
>>> your starting point.
> 
> In the spirit of lambasting the lack of direct representation of
> finite-state machines (FSMs) in Ada:

Egh? Ada lacks nothing for programming FSM. It has:

1. gotos and labels
2. access to subprogram type
3. dispatching

Ada has enumeration types so that states could be named. Ada has the case
statement checking all alternatives. Ada has ranges in case statement in
order to specify subsets of states and subtypes to name such subsets.

Thus either possible way of implementing FSM is fully, totally, and
exhaustively supported in Ada.

>> As an example consider reading from a stream without blocking. When there
>> is no more data available you switch to another co-routine (reading another
>> stream). This is programmed as if reading from the stream was blocking. The
>> co-routine is continued when more data become available. On top of these
>> stream could be a mountain of protocols or a whole Ada compiler taking the
>> stream as a source. Doing this as a state machine, upside-down driven by
>> incoming characters would be extremely tedious.
>> 
>> The idea of user-defined tasking is that the user would also provide the
>> pool to allocate the task stack and would activate/deactivate his tasks.
> 
> In the spirit of humbly learning something new and appreciating any
> potential beauty:
> 
> Dmitry, do you advocate the use of "co-routines" (as Ada tasks, if I
> understand you correctly) for the modeling of arbitrarily-complex
> finite-state machines (FSMs)?  If so (and if it scales), perhaps you can
> explain the design idiom more completely so that it handles FSMs of
> arbitrary complexity.

The idiom is: unless at gunpoint, never ever use FSM.

> It seems that your usage here of "co-routines" to represent FSMs

No, I don't want to represent state machine. I want to get rid of it
completely. More generally, I don't want a data-driven architecture. FSA as
a programming pattern, is an instance of data-driven architecture.

> somewhat
> resembles C.A.R. Hoare's monitors, but perhaps I am taking your
> "co-routines" in a different direction than you intend.

I intent to reuse normal Ada code that deploys I/O (like file I/O, socket
I/O etc, which is 99.999%, for the rest 0.001% cases where asynchronous
non-blocking I/O is used. It does not work now because blocking I/O
requires a task to await for data it expect. That is, the I/O is blocking. 

With asynchronous I/O, usually from many channels simultaneously, you don't
have a task to block, you are forced to deploy a set state of machines
activated each time data gets available on some I/O channel. You select the
machine servicing the channel, feed the machine with data, perform
transitions until there is no more data, store the machine state, look for
another channel etc. Now consider what this becomes when you have to output
also asynchronously! as you perform transitions. This is the case for HTTP
and other network protocol servers. Where with normal I/O you have:

   loop
      read input
      process
      write output
   end loop;

here you'd have an utter mess. It is a disgusting software pattern
extremely low-level and difficult to use, absolutely unmaintainable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 23 Jun 2014 15:08:47 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1vrc8mmlbvd6f$.1vak7oiubwsaj$.dlg@40tude.net...
>> On Sun, 22 Jun 2014 18:38:50 -0500, Randy Brukardt wrote:
>>
>>> I'm not talking about "peripherals"; I'm talking about timers and trap
>>> handlers (for overflow, divide-by-zero, etc.) and the like. These things 
>>> are
>>> required for a useful subset of Ada. (No clock and no exceptions means
>>> you're no longer really doing Ada, just Ada syntax.) I/O is optional, but
>>> not these other things.
>>
>> You are right. But how a board could be of any use without some peripheral
>> I/O? Especially when file I/O and networking has already been ruled out!
>> Deaf-mute chunk of silicon...
> 
> Right, but I was thinking of the rather elaborate language-defined I/O 
> facilities. I doubt that there is much use for Ada.Directories on the 
> typical embedded board.

It is rather common to have a USB flash attached, formatted FAT or
something. So Ada.Directories is not so outlandish as it may appear...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 23 Jun 2014 12:17:38 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Programming a state machine is turning all design upside down. If
>>> there were user-defined task support one could program this as if it
>>> were in proper tasks.
>> 
>> I find it easier to think about state machines as state machines rather
>> than by encoding them using the program counter! I geuss it depends on
>> your starting point.
>
> As an example consider reading from a stream without blocking. When there
> is no more data available you switch to another co-routine (reading another
> stream). This is programmed as if reading from the stream was blocking. The
> co-routine is continued when more data become available. On top of these
> stream could be a mountain of protocols or a whole Ada compiler taking the
> stream as a source. Doing this as a state machine, upside-down driven by
> incoming characters would be extremely tedious.

I can see this would be tedious. As I said, it depends where you're
coming from; I was thinking in terms of buttons being pressed/switches
being closed/limits being reached (which are probably closer to what
small embedded systems are more commonly used for).

> The idea of user-defined tasking is that the user would also provide the
> pool to allocate the task stack and would activate/deactivate his tasks.

Something like green threads?

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> The idiom is: unless at gunpoint, never ever use FSM.

There are times when state machines aren't appropriate and there are
times when they are exactly the idiom you should be using.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Egh? Ada lacks nothing for programming FSM. It has:
>
> 1. gotos and labels
> 2. access to subprogram type
> 3. dispatching
>
> Ada has enumeration types so that states could be named. Ada has the case
> statement checking all alternatives. Ada has ranges in case statement in
> order to specify subsets of states and subtypes to name such subsets.
>
> Thus either possible way of implementing FSM is fully, totally, and
> exhaustively supported in Ada.

You're describing the assembly language of state machines. Higher-level
constructs are needed.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Shark8]

On 23-Jun-14 13:21, Dan'l Miller wrote:
> In the spirit of lambasting the lack of direct representation
> of finite-state machines (FSMs) in Ada:

Wtf, there's a direct representation for state-machines:

Type State is ([...]);
Type Event is ([...]);

-- Here it is!
FSM : Array(State, Event) of State:= ([...]);

...and that's Ada-83.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dan'l Miller]

On Monday, June 23, 2014 4:52:16 PM UTC-5, Simon Wright wrote:
> "Dmitry A. Kazakov" writes:
> 
> > Egh? Ada lacks nothing for programming FSM. It has:
> > 1. gotos and labels
> > 2. access to subprogram type
> > 3. dispatching
> 
> > Ada has enumeration types so that states could be named. Ada has the case
> > statement checking all alternatives. Ada has ranges in case statement in
> > order to specify subsets of states and subtypes to name such subsets.
> 
> > Thus either possible way of implementing FSM is fully, totally, and
> > exhaustively supported in Ada.
> 
> You're describing the assembly language of state machines. Higher-level
> constructs are needed.

Simon, those were my (unexpressed) thoughts exactly upon reading Dmitry's description of the contortions needed to represent FSMs in Ada, C, C++, and so forth (ignoring the different contortions in Erlang and Boost.MSM and F#/OCaml).  Btw, here are the F#/OCaml and Erlang contortions that look quite different than {Ada, C, C++}'s traditional implementation of FSMs as conditional branches cased over a set of enumerations:  http://theburningmonk.com/2012/07/a-simple-finite-state-machine-in-erlang-and-f of which only the F# variant *might* be argued to be a perhaps-more-intuitive improvement due to syntactic compactness over a sophisticated richness of an asynchrony feature-set.  FSMs in Ada202X should be drastically more intuitive & direct than even the F# and Erlang representations.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Nasser M. Abbasi]

On 6/23/2014 4:48 PM, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> The idiom is: unless at gunpoint, never ever use FSM.
>
> There are times when state machines aren't appropriate and there are
> times when they are exactly the idiom you should be using.
>

I remember once struggling with so many IF/ELSEIF/ENDIF/WHILE, etc...
trying to implement something, and then I learned about FSM programming.

This was an application level, not low level system programming. Once
I setup things as FSM, things went smooth sailing.  Needed an
initial state, final state, setup a diagram that tells me the
event that causes which state to jump to which state. Once I drew
this diagram, the coding part was easy. One can even setup a
matrix that represent the algorithm.

For example, writing TCP/IP algorithm and other network
algorithms is nearly impossible without using the help of FSM.
Here are diagrams:

http://userpages.umbc.edu/~jeehye/cmsc491b/lectures/tcpstate/sld001.htm
http://en.wikipedia.org/wiki/Border_Gateway_Protocol
http://telescript.denayer.wenk.be/~hcr/cn/idoceo/tcp_linkstates.html

I think also for parsing text, setting up a FSM makes parsing things
much easier, and I used it for that also. FSM can be used for many other
things if one can identify all the states and all the events that
causes each state to switch to different state.

http://en.wikipedia.org/wiki/Finite-state_machine
  
--Nasser

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Jeffrey Carter]

> On 6/23/2014 4:48 PM, Simon Wright wrote:
>>
>> There are times when state machines aren't appropriate and there are
>> times when they are exactly the idiom you should be using.
>>
>
> I remember once struggling with so many IF/ELSEIF/ENDIF/WHILE, etc...
> trying to implement something, and then I learned about FSM programming.
>
> This was an application level, not low level system programming. Once
> I setup things as FSM, things went smooth sailing.  Needed an
> initial state, final state, setup a diagram that tells me the
> event that causes which state to jump to which state. Once I drew
> this diagram, the coding part was easy. One can even setup a
> matrix that represent the algorithm.

State machines are a high-level language for specifying behavior. Translation to 
code is mechanical; in other words, one can write a compiler to convert a state 
machine into code. What the code looks like is as immaterial as what the 
intermediate representation for Ada looks like

-- 
Jeff Carter
"Crucifixion's a doddle."
Monty Python's Life of Brian
82

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 23 Jun 2014 21:40:40 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> The idea of user-defined tasking is that the user would also provide the
>> pool to allocate the task stack and would activate/deactivate his tasks.
> 
> Something like green threads?

That's one, but also and important an ability not to use any system
resources like TCB, stack, pool. The intended use would be massively
parallel threads of control. You don't want to pollute the system stack
with these. This is why I want control where task's local objects gets
allocated. And possibly what the default storage pool is. The idea is to be
able to built a sandbox for these "tasks."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Mon, 23 Jun 2014 22:48:24 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> The idiom is: unless at gunpoint, never ever use FSM.
> 
> There are times when state machines aren't appropriate and there are
> times when they are exactly the idiom you should be using.

Right, the times when you are at gunpoint. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Maciej Sobczak]

> When implementing
> stuff like network communication (e.g. HTTP servers) and parallel
> processing we frequently have a set of state machines (one per connection)
> too expensive to handle from OS tasks.

Right.

> Programming a state machine is
> turning all design upside down.

Or not, depending on how the connection (and its state) is perceived in the whole system. If you want your connections to have a life that is independent on other connections (that might be a valid idea in a non-critical HTTP server), then it might be useful to express that independence at a code level, with a code that seems to be confined to a single task of handling that single connection. But if you want a connection handling that manages the system as a whole (traffic shaping based on the overall performance is an example obvious reason for this), then state machines seem to be spot-on.

Also, the communication paradigm influences whether this is a problem or not - in messaging systems, where message is a unit of transfer and processing, this is not a problem at all. HTTP servers can be treated in the same way, as they are not stream-oriented, but request-oriented.

> If there were user-defined task support one
> could program this as if it were in proper tasks.

Maybe not "proper tasks", but something similar that has an explicit interface to "push" its execution forward up to the next "switching point", so that the application can decide on its own when that "pushing" should take place.
The difference is that normal tasks are propelled by the run-time (for example by the OS-level thread) and the application has no influence on this, whereas what is needed here is the task-like language feature that can be propelled at the discretion of the application. Now that could be useful, but this explicit interface for pushing the task forward is what would make it distinct from "proper tasks".

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Tue, 24 Jun 2014 00:52:33 -0700 (PDT), Maciej Sobczak wrote:

>> If there were user-defined task support one
>> could program this as if it were in proper tasks.
> 
> Maybe not "proper tasks", but something similar that has an explicit
> interface to "push" its execution forward up to the next "switching
> point", so that the application can decide on its own when that "pushing"
> should take place.

It is alike to all software architectures based on callbacks or events,
e.g. GUI. It is fairly easy to program with callbacks so long there is not
much logic behind actions triggered by callbacks and there is little
coupling between the actions and no ordering of the actions is needed.

For complex logic it is becomes almost impossible to structure the design
along callback decomposition. It is no matter if callbacks are subprograms
or full objects (procedural vs. OO decomposition), because the lines are
already drawn. You cannot change anything. It is knitting standing on your
head.

Instead of the mess you wanted to put weight rather on the logic of the
actions, their ordering and effects, than on the callbacks (I/O events).
For this the individual callbacks which are logically coupled and ordered
need to be represented as such in the source code, visually close to each
other, best of all, as a thread of control where events pushing the actions
are actually irrelevant to the logic.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Wright]

Shark8 <OneWingedShark@gmail.com> writes:

> On 23-Jun-14 13:21, Dan'l Miller wrote:
>> In the spirit of lambasting the lack of direct representation
>> of finite-state machines (FSMs) in Ada:
>
> Wtf, there's a direct representation for state-machines:
>
> Type State is ([...]);
> Type Event is ([...]);
>
> -- Here it is!
> FSM : Array(State, Event) of State:= ([...]);
>
> ...and that's Ada-83.

You'd need the Action (access procedure (...)) to be executed on the
transition, too.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dan'l Miller]

On Tuesday, June 24, 2014 5:24:03 AM UTC-5, Simon Wright wrote:
> Shark8 writes:
> > On 23-Jun-14 13:21, Dan'l Miller wrote:
> >> In the spirit of lambasting the lack of direct representation
> >> of finite-state machines (FSMs) in Ada:
>
> > Wtf, there's a direct representation for state-machines:

  No, Shark8, that is the epitome of *not* direct representation of state-machines as a first-class citizen in {Ada, C, C++, ...}, because the compiler has absolutely no clue that all the enumerations & branching are representing an FSM.  For example, (without an enormous amount of temporal-logic analysis, program slicing, and term-rewriting) the compiler cannot directly observe:  oh, the programmer wrote a Moore machine (see below), but I can optimize the whole FSM by transforming it to a Mealy machine, or vice versa.  As another example, (without an enormous amount of temporal-logic analysis, program slicing, and term-rewriting) the compiler cannot perform any graph-theoretic transforms on the FSM, because the FSM is contorted into excessively-sequential imperative code instead of declarative.

> > Type State is ([...]);
> > Type Event is ([...]);
> > -- Here it is!
> > FSM : Array(State, Event) of State:= ([...]);
> > ...and that's Ada-83.
>
> You'd need the Action (access procedure (...)) to be executed on the
> transition, too.

  Moore FSM:  actions only on the entry of states  http://en.wikipedia.org/wiki/Moore_machine
  He was representing a Moore machine, which tends to increase the quantity of states to discern context in the real-world.

  Mealy FSM:  actions upon transition to next state  http://en.wikipedia.org/wiki/Mealy_machine
  You are representing a Mealy machine, which is the more-mainstream modern FSM, because pairs of states (i.e., the origin & destination of each transition) provide a more natural (i.e., more expressive & more compact) way to discern context.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-23, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Mon, 23 Jun 2014 15:08:47 -0500, Randy Brukardt wrote:
>> 
>> Right, but I was thinking of the rather elaborate language-defined I/O 
>> facilities. I doubt that there is much use for Ada.Directories on the 
>> typical embedded board.
>
> It is rather common to have a USB flash attached, formatted FAT or
> something. So Ada.Directories is not so outlandish as it may appear...
>

RTEMS has generic directory support as well although USB support was
a work in progress when I last looked at USB support in RTEMS.

I'm beginning to think the most viable approach for Ada in these
embedded environments is to forget about Ada from top to bottom
and instead focus on Ada at the embedded application level and
run that Ada application on top of a C language RTOS base, just
as you can currently do with RTEMS.

That's not the ideal approach, but it's probably the most pragmatic
approach.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-22, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
> message news:lo7c2h$ura$1@dont-email.me...
>>
>> To me, I mentally split the problem into two categories: The support
>> for Ada language functionality and the support for peripherals on the
>> specific board. I regard only the first part as really a part of the
>> actual compiler, but it is a required part.
>>
>> However, my feeling is that the Ada RTL support, once implemented, is
>> pretty generic within a MCU architecture and is not really board
>> specific.
>
> That's not my experience. Remember that "basic Ada support" includes things 
> like timers (Ada.Real_Time, delay statements), some method of handling 
> exceptions (which generally means supporting hardware traps), and usually 
> tasking (which means some method of context switching).
>
> All of these require interrupt support on bare boards, and that never seems 
> to be quite the same from board to board.
>

In the ARM world, that's more of a MCU specific issue instead of a board
specific issue. What could be done is to split the Ada RTL into cleanly
separated generic and hardware specific parts and provide a clean detailed
specification for implementing the hardware specific part.

> There's certainly a shared part, but the configurations are different for 
> each board. And you have to be pretty familar with the boards in order to do 
> those; your average tinkerer isn't likely to be able to do that.
>

Some board specific configuration issues which might matter could be
things like memory layout which can be handled with linker scripts.

>> You may need some configuration and interface options for things like
>> I/O operations, with calls to user supplied I/O packages. These packages
>> would only concern themselves with the lowest level, interfacing to
>> the hardware itself and not provide any generic Ada RTL support.
>>
>> In these user supplied packages, I'm thinking about things like an Ada
>> version of, say, putchar() which would just output the passed character
>> to some hardware device without concerning itself about anything other
>> than that.
>
> Fair enough. I found back in the day that you had to be able to connect that 
> with Text_IO for useful output (for instance, the crash messages from the 
> Janus/Ada runtime). But that's clearly a secondary need. I wasn't thinking 
> about full I/O support, for instance, since it usually doesn't make sense in 
> that environment.
>

Sorry, I wasn't clear above.

What I meant was that Text_IO (or something like it) would be
implemented, but at the lowest level, the Text_IO package would just
call a user supplied routine to actually output the character(s) to the
hardware and that user supplied routine would not care about, or even
know anything about, the structure of the Ada RTL package calling it.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Shark8]

On 24-Jun-14 05:25, Dan'l Miller wrote:
> No, Shark8, that is the epitome of *not* direct representation of state-machines
> as a first-class citizen in {Ada, C, C++, ...}, because the compiler has
> absolutely no clue that all the enumerations & branching are representing an FSM.

I said direct representation, not first-class citizen -- or are you 
saying that both must be present?

Also, why should the compiler 'need' to be aware of what's going on? 
It's already got the rules that ensure correctness: no state/event can 
be omitted. (Ensuring that all transitions are correct-implementation 
are of the same class as misprinted specs where 'and' was used instead 
or 'or'.)

Something where state-machines are first-class citizens seems like an 
appropriate use for a DSL.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Wright]

"Dan'l Miller" <optikos@verizon.net> writes:

> On Tuesday, June 24, 2014 5:24:03 AM UTC-5, Simon Wright wrote:
>> Shark8 writes:

>> > Type State is ([...]);
>> > Type Event is ([...]);
>> > -- Here it is!
>> > FSM : Array(State, Event) of State:= ([...]);
>> > ...and that's Ada-83.
>>
>> You'd need the Action (access procedure (...)) to be executed on the
>> transition, too.
>
>   Moore FSM: actions only on the entry of states
> http://en.wikipedia.org/wiki/Moore_machine
>   He was representing a Moore machine, which tends to increase the
> quantity of states to discern context in the real-world.
>
>   Mealy FSM: actions upon transition to next state
> http://en.wikipedia.org/wiki/Mealy_machine
>   You are representing a Mealy machine, which is the more-mainstream
> modern FSM, because pairs of states (i.e., the origin & destination of
> each transition) provide a more natural (i.e., more expressive & more
> compact) way to discern context.

My state machine processor[1] allows both, whichever the analyst feels
more natural. I have no evidence as to whether this helps the reader at
all (or hinders tham, come to that).

[1] http://coldframe.sourceforge.net/coldframe/event-modelling.html

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dan'l Miller]

On Tuesday, June 24, 2014 10:55:15 AM UTC-5, Shark8 wrote:
> On 24-Jun-14 05:25, Dan'l Miller wrote:
> Something where state-machines are first-class citizens seems like an 
> appropriate use for a DSL.

Ah, yes, domain-specific languages (DSLs) are yet another area that Ada202X could address as a claim to fame that would differentiate Ada202X from, say, C++ and Java and Swift, given that OCaml with p4, MetaOCaml, and Seed7 are already (imperfectly) blazing portions of that DSL trail.  Stage-n source code that teaches the Ada202X compiler a DSL at stage n to produce stage-n+1 source-code generation feeding into stage n+1 Ada202X compilation would put Ada back on the map.  Plus, full-fledged support for multistage programming via DSLs within an extensive multistage Ada202X compiler would likely solve not only the FSM problemspace well, but also could permit errors to be domain-specific errors to be detected at compile-time (at either stage-n or at stage-n+1 compilation) instead of at run-time, allowing Ada202X to one-up the dynamic-programming world.

For example, the dynamism of Objective-C & Swift at run-time would be moved to one of the later stages of multi-stage programming.

As another example, one of the A#1 uses of Objective-C's & Swift's *run-time* check of whether a method is implemented for a target object is for a GUI infrastructure and the app-domain usage there of to defer which object in a hierarchy of nested 2D widgets to process an event (e.g., mouse-click; button press; keystroke) at not necessarily the leaf widget and not necessarily the root widget/canvas, but rather any leaf-or-intermediate-or-root widget-node from leaf to root.  Some events are appropriately naturally discarded if no handler processes that event by the time that the leaf-to-roof walk completes for that containment chain of widgets at those coordinates (or in the case of keyboard:  the widget with focus).  But some events would be considered an error if no widget handled them during the leaf-to-root walk of widgets at those coordinates (or in the case of keyboard:  the widget with focus).  Hence, GUIs have a cross-cutting analogue of what is abstract versus concrete in OO polymorphism, but for GUIs the tree is not a tree of types of classes; rather for GUIs the tree is a containment tree as a likely-heterogenous n-ary tree of different types of widgets.  That eventual concreteness could be enforced across each leaf-to-root walk of a containment tree of widgets for a given window or for a given dialog box.  This is where a multistage compiler could really shine (and perhaps a multistage compiler with GUI-expressivity DSL capabilities), because it can analyze where any events that need to be handled are not handled along one or more leaf-to-root walks of that containment tree.  This is currently a run-time error-case in Objective-C and Swift, but need not be, because with the correct compile-time-philosophy-based programming-language such as Ada202X (and perhaps with a DSL among a multistage Ada202X compilation) has not been brought to bear on that problemspace.  Imagine putting Ada back on the map as the premier language for a whole new problemspace, mainstreaming compile-time checks for what has been until now various domain-specific run-time errors in all of the plethora of mainstream programming languages, which is precisely the special sauce that put Ada on the map back in the late 1970s and throughout the 1980s as the one to beat.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dan'l Miller]

On Tuesday, June 24, 2014 1:06:45 PM UTC-5, Dan'l Miller wrote:
> ... GUI infrastructure and the app-domain usage there of to defer which object in a hierarchy of nested 2D widgets to process an event (e.g., mouse-click; button press; keystroke) ...

Btw, the meta-object compiler (MOC) in C++'s Qt framework is a fixed GUI-specific DSL that is in effect one stage of a multistage C++ compiler.  [Qt is pronounced "cute", which is (a stunted amount of) recursive cuteness, btw.]  Qt's MOC is designed primarily to add reflection to C++ to support Qt's socket-&-slot binding.  But the concept is ripe for genericization in Ada202X as a generalized DSL language (a la OCaml with p4) and as a generalized multistage compiler (a la MetaOCaml):
1) so that writing a MOC-equivalent for Ada202X would be merely an app-domain usage of (a stage of compilation in) Ada202X; and
2) so that adding compile-time checking of event dispatch in a heterogenous hierarchy of GUI widgets instead of Objective-C's & Swift's run-time-only fatal-error [200 postings ago in this thread] would be merely an app-domain usage of (a stage of compilation in) Ada202X; and
3) so that a first-class-citizen representation of an FSM would be merely an app-domain usage of (a stage of compilation in) Ada202X;
4) [add here your next 1000 highly-useful DSLs here as a stage of compilation in Ada202X, preferably :-) not a 1000 deep all in the same language-translation unit].

Does everyone see how this could put Ada202X back in the driver's seat vis a vis mindshare of compiled programming languages, very similarly to Green & Ada-83 being in the driver's seat of state-of-the-art during the late 1970s and throughout the 1980s?

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Shark8]

Sounds ambitious, but an intriguing idea nonetheless.
Perhaps you could hammer-out a couple of pages of explanation 
(problem/solution) and then submit to Ada-Comment.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dan'l Miller]

On Tuesday, June 24, 2014 1:49:40 PM UTC-5, Shark8 wrote:
> Sounds ambitious, but an intriguing idea nonetheless.
> Perhaps you could hammer-out a couple of pages of explanation 
> (problem/solution) and then submit to Ada-Comment.

It won't be finished any time real soon, but I will see what I can put together.

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Tue, 10 Jun 2014 14:42:56 +0200, Lucretia <laguest9000@googlemail.com>  
a écrit:
>> (The other reasons include the restricted set of host and target
>> platforms for Ada when compared to C and the fact the nicely
>
> the fact that the FSF version has been crippled on purpose to stop the  
> building of certain said targets, you mean?

Please, what do you mean? How crippled?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Thu, 12 Jun 2014 09:01:10 +0200, Simon Clubley  
<clubley@remove_me.eisner.decus.org-earth.ufp> a écrit:

> On 2014-06-11, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
>> On 06/11/2014 12:32 AM, Simon Clubley wrote:
>>> On 2014-06-10, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>  
>>> wrote:
>>>>
>>>> If it's targeted by a C compiler then it's targeted by an Ada  
>>>> compiler.
>>>
>>> That doesn't make sense.
>>>
>>> Some random examples:
>>>
>>> What about the various microcontrollers you can buy which have C
>>> available but not a Ada compiler ?
>>>
>>> What about IBM's AS/400 or MVS systems ?
>>>
>>> What about a usable version of Ada for the PIC32MX ?
>>
>> What about the AdaMagic compiler that uses ANSI C as its intermediate
>> language?
>>
>
> The AdaMagic compiler is utterly unsuitable here.
>
> In a world where development environments are available for free, you
> are not going to persuade people to try Ada by telling them they have
> to pay mega dollars/mega pounds for a Ada to C compiler.
>
> When you are doing development in a corporate environment on production
> systems, then a paid for solution makes very good sense. When you are
> trying to persuade new people to adopt Ada, it does not.
>
> Simon.
>

Even if it's (or would be) low cost?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Georg Bauhaus]

On 25/06/14 08:42, Yannick Duchêne (Hibou57) wrote:
>>
>> In a world where development environments are available for free, you
>> are not going to persuade people to try Ada by telling them they have
>> to pay mega dollars/mega pounds for a Ada to C compiler.
>>
>> When you are doing development in a corporate environment on production
>> systems, then a paid for solution makes very good sense. When you are
>> trying to persuade new people to adopt Ada, it does not.
>>
>> Simon.
>>
>
> Even if it's (or would be) low cost?

Maybe, when considering low budget production software,
the use of respectively Oracle's free one (MySQL) and
Oracle's paid one (Database) show the extent to which
low cost solutions can compete with free ones. (Similarly
for IBM's etc.)

Re: a new language, designed for safety !

[Simon Clubley]

On 2014-06-25, Yannick Duchêne <yannick_duchene@yahoo.fr> wrote:
> Le Thu, 12 Jun 2014 09:01:10 +0200, Simon Clubley  
><clubley@remove_me.eisner.decus.org-earth.ufp> a écrit:
>
>> On 2014-06-11, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
>>>
>>> What about the AdaMagic compiler that uses ANSI C as its intermediate
>>> language?
>>>
>>
>> The AdaMagic compiler is utterly unsuitable here.
>>
>> In a world where development environments are available for free, you
>> are not going to persuade people to try Ada by telling them they have
>> to pay mega dollars/mega pounds for a Ada to C compiler.
>>
>> When you are doing development in a corporate environment on production
>> systems, then a paid for solution makes very good sense. When you are
>> trying to persuade new people to adopt Ada, it does not.
>>
>
> Even if it's (or would be) low cost?
>

First, as I wrote in a followup at the time, the above message was more
abrupt than I intended.

To answer your question, in order to make people hand over their own
money when free options exist, you have to have a unique selling point.

For someone who has heard of "this language called Ada" but doesn't know
anything else about it, then the question to answer is: why pay money
for a Ada compiler when other options exist for free ?

As I mentioned above, the situation in a corporate environment is very
different from when someone is paying for their interests out of their
own pocket.

It doesn't help matters when (for example) the latest Barnes is about
50 quid (that's the selling price on Amazon) but under half that price
for things like C++ language books.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Niklas Holsti]

On 14-06-23 10:42 , Dmitry A. Kazakov wrote:
> On Mon, 23 Jun 2014 09:18:11 +0300, Niklas Holsti wrote:
> 
>> I am currently working on an Ada project with a null run-time and a
>> proprietary small multi-threading kernel.
> 
> Wouldn't it be helpful to have user-defined tasking for such cases?

I haven't felt a need for that.

> Because there is another important case for this - co-routines.

I don'like them, at least not as substitutes for tasking. They can be a
way to interface and interleave two or more sequential algorithms in one
task, in a controlled way.

> When implementing
> stuff like network communication (e.g. HTTP servers) and parallel
> processing we frequently have a set of state machines (one per connection)
> too expensive to handle from OS tasks. Programming a state machine is
> turning all design upside down. If there were user-defined task support one
> could program this as if it were in proper tasks.

The proposals for "lightweight" tasks that I have seen have more
constraints and ugly limitations than I would like. Even Ravenscar
constraints are often annoying. Better OS support for Ada tasking would
be preferable. I'm not convinced that the best and fastest designs for
Ada tasking systems have been discovered yet.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Mon, 16 Jun 2014 14:08:07 +0200, Peter Chapin <PChapin@vtc.vsc.edu> a  
écrit:

> On 2014-06-16 02:19, Georg Bauhaus wrote:
>
>> But look at how Apple did use some more syntax in its version
>> of Go. Similarly, Scala, I think, is only superficially
>> catering to the ever popular omissive style.
>
> Excessive terseness is bad for readability but so is excessive
> verbosity. There is a sweet spot somewhere between the extremes; finding
> it is tricky […]

If readability is about trusting what you see, there is just a fuzzy good  
area; that's not tricky, there is just no exact point which is the good  
one, and you have to rely on something above readability, I mean, a formal  
model and a proof a program does not break the model.

There will always be a limit to what you can get from readability as much  
as there is a limit to what you can get from simple typing like what get  
in typed languages. That's better than worse, but there is still a limit,  
so useless to try too much hard to get all from it.

Yes, I know that's easier to say than to do (I just like to dream of it),  
especially when formal methods are still in their infancy and there is no  
standard in this area (I wish there would a standard formal language and  
standard logical framework… but we are very far from this).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Wed, 11 Jun 2014 09:17:45 +0200, Pascal Obry <pascal@obry.net> a écrit:

> Le mardi 10 juin 2014 à 21:04 +0000, Simon Clubley a écrit :
>> The real problem is that when a company pulls a stunt like that you can
>> never be sure what other things might be waiting around the corner so
>> you can become reluctant to use any freely available packages that
>> company might have direct control over.
>
> That's strange thinking as GPL is about freedom! So moving to GPL is
> going into the right direction to me.
>
> Many commercial devices (televisions, internet boxes, routers...) are
> using a Linux kernel or VLC player those days.

A commercial device is not the same case as a commercial software.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Wed, 11 Jun 2014 00:09:16 +0200, Luke A. Guest <laguest@archeia.com> a  
écrit:

> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>> The one ACT supplied library I used to use was GtkAda which had a GMGPL
>> style licence until around GTK 2.4 (IIRC) when it was suddenly changed
>> to pure GPL overnight by ACT.
>>
>> I made a point _never_ to use anything under the direct control of ACT
>> after that experience. (For gcc, I use the FSF gcc branch only).
>
> Exactly.
>
> I have similar concerns now they are the ones 'controlling' the future is
> ASIS, as there's no external agency defining the packages, […]

Isn't it an ISO standard? Or it isn't anymore?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Fri, 13 Jun 2014 03:28:28 +0200, Luke A. Guest <laguest@archeia.com> a  
écrit:

> Shark8 <OneWingedShark@gmail.com> wrote:
>> On 10-Jun-14 16:09, Luke A. Guest wrote:
>>> I have similar concerns now they are the ones 'controlling' the future  
>>> is
>>> ASIS,
>>
>> I remember you saying something like that.
>> Is DIANA an acceptable alternative? (Its definition is not w/i the  
>> purview of AdaCore.)
>
> No, DIANA was an attempt to standardise on a compiler intermediate
> representation (IR) for Ada compilers. It's too old, dated and there are
> better IR's now.

What is an “IR”, please?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Tue, 10 Jun 2014 17:33:07 +0200, Lucretia <laguest9000@googlemail.com>  
a écrit:
> That's not the only problem, I know of people who have left Ada and gone  
> to Java because of bugs in GNAT which won't get fixed unless someone  
> pays for it, e.g. go back to my previous point of cost.

I believe too that's one of the biggest issue (both the bugs and the price  
to get them fixed).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Tue, 17 Jun 2014 21:46:26 +0200, Jacob Sparre Andersen  
<jacob@jacob-sparre.dk> a écrit:

> Jeffrey Carter wrote:
>
>> As I've said before, Ada will never be used willingly by the 98% of of
>> developers who aren't software engineers.
>
> But shouldn't we still attempt to reach the remaining 2%?
>
> Comparing the number of JavaScript and Ada developers on GitHub
> indicates that there is space to multiply the number of Ada developers
> by 50.

One can't compare a count of JavaScript developers with a count of Ada  
developers, as JavaScript is the native and required language for a common  
platform, which is the web platform.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Shark8]

On 25-Jun-14 16:41, Yannick Duchêne (Hibou57) wrote:
> Le Fri, 13 Jun 2014 03:28:28 +0200, Luke A. Guest <laguest@archeia.com>
> a écrit:
>
>> Shark8 <OneWingedShark@gmail.com> wrote:
>>> On 10-Jun-14 16:09, Luke A. Guest wrote:
>>>> I have similar concerns now they are the ones 'controlling' the
>>>> future is
>>>> ASIS,
>>>
>>> I remember you saying something like that.
>>> Is DIANA an acceptable alternative? (Its definition is not w/i the
>>> purview of AdaCore.)
>>
>> No, DIANA was an attempt to standardise on a compiler intermediate
>> representation (IR) for Ada compilers. It's too old, dated and there are
>> better IR's now.
>
> What is an “IR”, please?
>

IR => Intermediate Representation.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Thu, 19 Jun 2014 22:59:38 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:

> "Peter Chapin" <PChapin@vtc.vsc.edu> wrote in message
> news:tYmdnRDwdcBVTz_ORVn_vwA@giganews.com...
> ...
>> My understand is that parsing Ada requires name resolution to resolve
>> syntactic ambiguities.
>
> Definitely not. Janus/Ada uses a table-driver parser that has absolutely  
> no
> semantic information. There has to be a bit of care in tokenizing (for  
> the
> infamous T'('A') example) but parsing is completely normal.

If “definitely not”, how do you make “F(A)” and “G(A)” distinct, when F is  
a sub‑program  and G an array? (the most famous example). Don't you use  
name resolution there? Or else do you use an intermediate construct, like  
array access temporarily seen as a function? If not this, how?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Sat, 21 Jun 2014 10:35:52 +0200, Natasha Kerensikova  
<lithiumcat@instinctive.eu> a écrit:

> On 2014-06-20, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message
>> news:slrnlq7oge.i0l.lithiumcat@nat.rebma.instinctive.eu...
>> ...
>>> The way I understand the whole situation is that ASIS provider  
>>> diversity
>>> would be a good thing too (though not as much as compiler diversity),
>>> and Gela is not too far from there, so pushing Gela forward would be a
>>> good thing both globally and for my self-improvement.
>>
>> That would work, of course, but all of the hard stuff (well, almost all)
>> would be in the GELA ASIS front-end. And you'd have to do frequent
>> maintenance on the ASIS stuff if you wanted to actually compile Ada (as
>> almost every bug would be in the ASIS part). It certainly could work,  
>> but it
>> would mean having to understand the GELA ASIS code in detail (not just  
>> the
>> interface). For me, I'd rather fix my own code than someone else's.
>
> Funnily, it's the first time I'm warned against re-using code instead of
> re-writing it, usually I'm warned against re-writing instead of
> re-using.

The “why” often matters more the “how”, and about “reusing”, which is an  
“how”, one should not lose track of the “why”, and the “why” does not  
always suggest to reuse. See an old paper on this, here:
http://www.joelonsoftware.com/articles/fog0000000007.html
In Defense of Not-Invented-Here Syndrome, by Joel Spolsky


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Mon, 23 Jun 2014 09:42:23 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Mon, 23 Jun 2014 09:18:11 +0300, Niklas Holsti wrote:
>
>> I am currently working on an Ada project with a null run-time and a
>> proprietary small multi-threading kernel.
>
> Wouldn't it be helpful to have user-defined tasking for such cases?  
> Because
> there is another important case for this - co-routines. When implementing
> stuff like network communication (e.g. HTTP servers) and parallel
> processing we frequently have a set of state machines (one per  
> connection)
> too expensive to handle from OS tasks. Programming a state machine is
> turning all design upside down. If there were user-defined task support  
> one
> could program this as if it were in proper tasks.

That's what I expected to come with Ada 2012, but it was not there.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Tue, 24 Jun 2014 09:52:33 +0200, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:
>> Programming a state machine is
>> turning all design upside down.
>
> Or not, depending on how the connection (and its state) is perceived in  
> the whole system.

Rather depends on the side you are on. You can write a readable routine's  
algorithm from the side of the routine, then have to rewrite it  
upside‑down to be able to integrate it, due to the lack of coroutines, and  
then it's not readable any‑more.

When I was using C, I used to implement per‑coroutine stack (with limit  
check!, cheese) and stack‑switching for that purpose, but you can't do it  
with Ada, as it does not allow this kind of low level hacking.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Mon, 23 Jun 2014 22:14:13 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Mon, 23 Jun 2014 12:21:11 -0700 (PDT), Dan'l Miller wrote:
>
>> On Monday, June 23, 2014 12:14:24 PM UTC-5, Dmitry A. Kazakov wrote:
>>> On Mon, 23 Jun 2014 12:17:38 +0100, Simon Wright wrote:
>>>> "Dmitry A. Kazakov" writes:
>>>>> Programming a state machine is turning all design upside down. If
>>>>> there were user-defined task support one could program this as if it
>>>>> were in proper tasks.
>>>
>>>> I find it easier to think about state machines as state machines  
>>>> rather
>>>> than by encoding them using the program counter! I geuss it depends on
>>>> your starting point.
>>
>> In the spirit of lambasting the lack of direct representation of
>> finite-state machines (FSMs) in Ada:
>
> Egh? Ada lacks nothing for programming FSM. It has:
>
> 1. gotos and labels
> 2. access to subprogram type
> 3. dispatching

Yes, labels, except the syntax of labels in (on purpose?) so ugly it  
prevent it's frequent use.

“State_Foo:” is more intuitive less ugly than “<<State_Foo>>”. The “goto”  
statement is luckily fine. When I say it's ugly, that's because there is  
too much garbage around the label and the label name does not come first  
(there is the “<<” before it).

This syntax would be OK for an emphasis, but within a state machine, one  
often have many labels and it's not a good idea to make them all looks  
like emphases.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Jun 2014 05:24:47 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Yes, labels, except the syntax of labels in (on purpose?) so ugly it  
> prevent it's frequent use.
>
> “State_Foo:” is more intuitive less ugly than “<<State_Foo>>”. […]

That's why I prefer cases switch in a loop whenever a state machine is the  
most intuitive or readable choice (rarely, but it already happened).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Tue, 24 Jun 2014 13:25:38 +0200, Dan'l Miller <optikos@verizon.net> a  
écrit:

> On Tuesday, June 24, 2014 5:24:03 AM UTC-5, Simon Wright wrote:
>> Shark8 writes:
>> > On 23-Jun-14 13:21, Dan'l Miller wrote:
>> >> In the spirit of lambasting the lack of direct representation
>> >> of finite-state machines (FSMs) in Ada:
>>
>> > Wtf, there's a direct representation for state-machines:
>
>   No, Shark8, that is the epitome of *not* direct representation of  
> state-machines as a first-class citizen in {Ada, C, C++, ...}, because  
> the compiler has absolutely no clue that all the enumerations &  
> branching are representing an FSM.  For example, (without an enormous  
> amount of temporal-logic analysis, program slicing, and term-rewriting)  
> the compiler cannot directly observe:  oh, the programmer wrote a Moore  
> machine (see below), but I can optimize the whole FSM by transforming it  
> to a Mealy machine, or vice versa.  As another example, (without an  
> enormous amount of temporal-logic analysis, program slicing, and  
> term-rewriting) the compiler cannot perform any graph-theoretic  
> transforms on the FSM, because the FSM is contorted into  
> excessively-sequential imperative code instead of declarative.

Yes, that's what made me wonder if loop with cases switch is really that  
good for a state machine, as you get a three‑steps‑goto: assign the sate  
variable, continue the loop, select case of the state variable. But  
goto‑labels are so ugly with Ada…

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: a new language, designed for safety !

[Luke A. Guest]

Yannick Duchêne (Hibou57 ) <yannick_duchene@yahoo.fr> wrote:
> Le Wed, 11 Jun 2014 00:09:16 +0200, Luke A. Guest <laguest@archeia.com> a  
> écrit:
> 
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> 
>>> The one ACT supplied library I used to use was GtkAda which had a GMGPL
>>> style licence until around GTK 2.4 (IIRC) when it was suddenly changed
>>> to pure GPL overnight by ACT.
>>> 
>>> I made a point _never_ to use anything under the direct control of ACT
>>> after that experience. (For gcc, I use the FSF gcc branch only).
>> 
>> Exactly.
>> 
>> I have similar concerns now they are the ones 'controlling' the futureis
>> ASIS, as there's no external agency defining the packages, […]
> 
> Isn't it an ISO standard? Or it isn't anymore?
> 

No they've abandoned it. AdaCore is the one extending it. 

I downloaded ASIS GPL the other day, to their credit AdaCore have
documented the extensions to 2005 and 2012 in the root as readme files.
 
So this shouldn't be a problem for other ASIS implementations with more
permissive licences if the interfaces are copied from the readme's into
their source.

Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Jun 2014 09:39:00 +0200, Luke A. Guest <laguest@archeia.com> a  
écrit:

> Yannick Duchêne (Hibou57 ) <yannick_duchene@yahoo.fr> wrote:
>>> I have similar concerns now they are the ones 'controlling' the  
>>> futureis
>>> ASIS, as there's no external agency defining the packages, […]
>>
>> Isn't it an ISO standard? Or it isn't anymore?
>>
>
> No they've abandoned it.

Why? (with my apologizes to reply with a question again)

I though the ASIS standardisation process was going with that of Ada and  
so there was an ISO ASIS standard coming next to each ISO Ada standard.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[G.B.]

On 26.06.14 04:50, Yannick Duchêne (Hibou57) wrote:
> When I was using C, I used to implement per‑coroutine stack (with limit
> check!, cheese) and stack‑switching for that purpose, but you can't do
> it with Ada, as it does not allow this kind of low level hacking.

Given that Ada allows hacking at a level lower than C
---address arithmetic is not restricted by the type
of offsets, for example---what is it that you have been
doing in C that you think cannot be done in Ada?

Re: a new language, designed for safety !

[Luke A. Guest]

Yannick Duchêne (Hibou57 ) <yannick_duchene@yahoo.fr> wrote:
> Le Thu, 26 Jun 2014 09:39:00 +0200, Luke A. Guest <laguest@archeia.com> a  
> écrit:
> 
>> Yannick Duchêne (Hibou57 ) <yannick_duchene@yahoo.fr> wrote:
>>>> I have similar concerns now they are the ones 'controlling' the  
>>>> futureis
>>>> ASIS, as there's no external agency defining the packages, […]
>>> 
>>> Isn't it an ISO standard? Or it isn't anymore?
>>> 
>> 
>> No they've abandoned it.
> 
> Why? (with my apologizes to reply with a question again)
> 
> I though the ASIS standardisation process was going with that of Ada and 
> so there was an ISO ASIS standard coming next to each ISO Ada standard.
> 


Do a search of this group as I asked and was told biut can't remember the
reasons.

Re: a new language, designed for safety !

[J-P. Rosen]

Le 26/06/2014 00:40, Yannick Duchêne (Hibou57) a écrit :
>> I have similar concerns now they are the ones 'controlling' the future is
>> ASIS, as there's no external agency defining the packages, […]
> 
> Isn't it an ISO standard? Or it isn't anymore?
There is a standard for Ada 95. There was a decision not to make a
standard for Ada 2005, now that Ada2012 is out.

The ARG decided to standardize existing practice rather than try
inventing. There should be a standard, but only after it is stabilized
on the side of the providers (TBH: AdaCore). But AdaCore developments
are made available to some members of the ARG (!) to check that they are
acceptable.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: a new language, designed for safety !

[J-P. Rosen]

Le 26/06/2014 00:41, Yannick Duchêne (Hibou57) a écrit :
>> No, DIANA was an attempt to standardise on a compiler intermediate
>> representation (IR) for Ada compilers. It's too old, dated and there are
>> better IR's now.
> 
> What is an “IR”, please?
Intermediate Representation...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Jun 2014 12:04:47 +0200, G.B.  
<rm-dash-bau-haus@dash.futureapps.de> a écrit:

> On 26.06.14 04:50, Yannick Duchêne (Hibou57) wrote:
>> When I was using C, I used to implement per‑coroutine stack (with limit
>> check!, cheese) and stack‑switching for that purpose, but you can't do
>> it with Ada, as it does not allow this kind of low level hacking.
>
> Given that Ada allows hacking at a level lower than C
> ---address arithmetic is not restricted by the type
> of offsets, for example---what is it that you have been
> doing in C that you think cannot be done in Ada?

You can do low level with Ada (often better than with C), yes, except you  
can't (and that's for good) interfere with the runtime as much easily as  
you can with C. There is no setjump/longjump equivalent in Ada, and  
switching between stacks allocated on the heap would be more hazardous  
with an Ada compiler than with a C compiler.

Anyway, that trick I used and which is not at all recommendable for  
serious works, was surely not portable (I can't remember what the C  
compiler was… DOS or Windows specific).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Shark8]

On 25-Jun-14 20:04, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 19 Jun 2014 22:59:38 +0200, Randy Brukardt
> <randy@rrsoftware.com> a écrit:
>
>> "Peter Chapin" <PChapin@vtc.vsc.edu> wrote in message
>> news:tYmdnRDwdcBVTz_ORVn_vwA@giganews.com...
>> ...
>>> My understand is that parsing Ada requires name resolution to resolve
>>> syntactic ambiguities.
>>
>> Definitely not. Janus/Ada uses a table-driver parser that has
>> absolutely no
>> semantic information. There has to be a bit of care in tokenizing (for
>> the
>> infamous T'('A') example) but parsing is completely normal.
>
> If “definitely not”, how do you make “F(A)” and “G(A)” distinct, when F
> is a sub‑program  and G an array? (the most famous example). Don't you
> use name resolution there? Or else do you use an intermediate construct,
> like array access temporarily seen as a function? If not this, how?

You don't need to make them distinct, at least not at the 
tokenizer-level. Determining what Some_Name(Some_Parameter) is within 
the realm of the semantic-analysis as Some_Name could refer to: a type, 
a subprogram, an array... Some_Parameter could be a value or a subtype 
[if Some_Name is a range-subtype], and all of these permutations are 
semantic responsibility rather than syntactic.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Yannick Duchêne (Hibou57)]

Le Fri, 27 Jun 2014 00:24:42 +0200, Shark8 <OneWingedShark@gmail.com> a  
écrit:
>> If “definitely not”, how do you make “F(A)” and “G(A)” distinct, when F
>> is a sub‑program  and G an array? (the most famous example). Don't you
>> use name resolution there? Or else do you use an intermediate construct,
>> like array access temporarily seen as a function? If not this, how?
>
> You don't need to make them distinct, at least not at the  
> tokenizer-level. Determining what Some_Name(Some_Parameter) is within  
> the realm of the semantic-analysis as Some_Name could refer to: a type,  
> a subprogram, an array... Some_Parameter could be a value or a subtype  
> [if Some_Name is a range-subtype], and all of these permutations are  
> semantic responsibility rather than syntactic.

I see. I had in mind the syntax described in the RM, as in

     6.4 Subprogram Calls

     unction_call ::=
          function_name
        | function_prefix actual_parameter_part

I forget it makes clear `function_name` stands for the token `name`,  
interpreted as `function_name` and `name` directs to:

     4.1 Names

     name ::=
           direct_name | explicit_dereference
         | indexed_component | slice
         | selected_component | attribute_reference
         | type_conversion | function_call
         | character_literal | qualified_expression
         | generalized_reference | generalized_indexing


Yes, indeed, the syntax and its interpretation are well distinguished.

I was misled by some visual memory :P .


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Shark8]

On 26-Jun-14 16:44, Yannick Duchêne (Hibou57) wrote:
> Le Fri, 27 Jun 2014 00:24:42 +0200, Shark8 <OneWingedShark@gmail.com> a
> écrit:
>>> If “definitely not”, how do you make “F(A)” and “G(A)” distinct, when F
>
> I was misled by some visual memory :P .

Not a problem -- it happens to all of us.
But it's also [sometimes] good to go over simple-things; after all, if 
you can't explain it to someone then that's a big flag that you likely 
don't fully understand the issue at hand.

Re: Ada platforms and pricing, was: Re: a new language,

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

Source 
    type Integer_1024 is - 2 ** 1023 .. ( 2 ** 1023 ) - 1 ;

Parser

  Lexical ( output )
    -- At this point the compiler only knows key words, symbols, 
    -- identifiers and numbers ( Integers, Reals )

    token_type
    token_identifier := "Integer_1024"
    token_is
    token_minus
    token_Number := 2 
    token_exponent
    token_Number := 1023
    token_double_dot
    token_left_parenthesis
    token_Number := 2 
    token_exponent
    token_Number := 1023
    token_right_parenthesis
    token_minus
    token_Number := 1
    token_semicolon

  Syntactic ( output )
    Scan tokens and reports syntactic errors
    Flag =>   No_Errors



In <K41rv.162760$Fd3.161991@fx26.iad>, Shark8 <OneWingedShark@gmail.com> writes:
>On 25-Jun-14 20:04, Yannick Duchêne (Hibou57) wrote:
>> Le Thu, 19 Jun 2014 22:59:38 +0200, Randy Brukardt
>> <randy@rrsoftware.com> a écrit:
>>
>>> "Peter Chapin" <PChapin@vtc.vsc.edu> wrote in message
>>> news:tYmdnRDwdcBVTz_ORVn_vwA@giganews.com...
>>> ...
>>>> My understand is that parsing Ada requires name resolution to resolve
>>>> syntactic ambiguities.
>>>
>>> Definitely not. Janus/Ada uses a table-driver parser that has
>>> absolutely no
>>> semantic information. There has to be a bit of care in tokenizing (for
>>> the
>>> infamous T'('A') example) but parsing is completely normal.
>>
>> If “definitely not”, how do you make “F(A)” and “G(A)” distinct, when F
>> is a sub‑program  and G an array? (the most famous example). Don't you
>> use name resolution there? Or else do you use an intermediate construct,
>> like array access temporarily seen as a function? If not this, how?
>
>You don't need to make them distinct, at least not at the 
>tokenizer-level. Determining what Some_Name(Some_Parameter) is within 
>the realm of the semantic-analysis as Some_Name could refer to: a type, 
>a subprogram, an array... Some_Parameter could be a value or a subtype 
>[if Some_Name is a range-subtype], and all of these permutations are 
>semantic responsibility rather than syntactic.

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> For complex logic it is becomes almost impossible to structure the
> design along callback decomposition. It is no matter if callbacks are
> subprograms or full objects (procedural vs. OO decomposition), because
> the lines are already drawn. You cannot change anything. It is
> knitting standing on your head.
>
> Instead of the mess you wanted to put weight rather on the logic of
> the actions, their ordering and effects, than on the callbacks (I/O
> events).  For this the individual callbacks which are logically
> coupled and ordered need to be represented as such in the source code,
> visually close to each other, best of all, as a thread of control
> where events pushing the actions are actually irrelevant to the logic.

I think we must be arguing from different premises.

In the system I was involved with, which involved state machines,
callbacks, and events, we had very little control over the order in
which the callbacks occurred. You can't tell when a radar searching for
a target will detect it. You can't tell the exact time at which a
missile will leave the launcher after you've given the launch
command. You can't tell when the human in the loop will decide it was a
mistake and abort. And all of these external inputs were managed via
callbacks.

Of course, you can be sure (relatively) that a missile won't launch
before it's commanded to!

Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

[Dmitry A. Kazakov]

On Tue, 01 Jul 2014 11:28:42 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> For complex logic it is becomes almost impossible to structure the
>> design along callback decomposition. It is no matter if callbacks are
>> subprograms or full objects (procedural vs. OO decomposition), because
>> the lines are already drawn. You cannot change anything. It is
>> knitting standing on your head.
>>
>> Instead of the mess you wanted to put weight rather on the logic of
>> the actions, their ordering and effects, than on the callbacks (I/O
>> events).  For this the individual callbacks which are logically
>> coupled and ordered need to be represented as such in the source code,
>> visually close to each other, best of all, as a thread of control
>> where events pushing the actions are actually irrelevant to the logic.
> 
> I think we must be arguing from different premises.
> 
> In the system I was involved with, which involved state machines,
> callbacks, and events, we had very little control over the order in
> which the callbacks occurred.

That is why you don't want them. I described an example of a multiple
connection server, but a target tracking system might be as good.

Once you identified a target you might wish to arrange all code dealing
with the target in a single module, a "task". It is no different to a
"task" servicing a connection. In both cases the driving force of the
"task" is the I/O events. As events happen (callback invoked) they should
be identified (the client for a connection, the target for a tracking
system) and then the "task" servicing the object released. The service code
does not see any callbacks. If acts as if it performed a blocking I/O
operation = waiting for the next expected thing to happen. E.g.

   loop
       select
          Get_Coordinates (X, Y, Z);
       or delay Tracking_Timeout;
          Display ("You lost me!");
          exit;
      end select;
      ...
   end loop;

> You can't tell when a radar searching for
> a target will detect it. You can't tell the exact time at which a
> missile will leave the launcher after you've given the launch
> command. You can't tell when the human in the loop will decide it was a
> mistake and abort.

Yes

> And all of these external inputs were managed via callbacks.

No. That is exactly the point. A design around callbacks is necessarily too
low-level and exposed to all sorts of issues difficult to resolve.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: a new language, designed for safety !

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:logs26$5sl$1@dont-email.me...
> Le 26/06/2014 00:40, Yannick Duchêne (Hibou57) a écrit :
>>> I have similar concerns now they are the ones 'controlling' the future 
>>> is
>>> ASIS, as there's no external agency defining the packages, [.]
>>
>> Isn't it an ISO standard? Or it isn't anymore?
> There is a standard for Ada 95. There was a decision not to make a
> standard for Ada 2005, now that Ada2012 is out.
>
> The ARG decided to standardize existing practice rather than try
> inventing. There should be a standard, but only after it is stabilized
> on the side of the providers (TBH: AdaCore). But AdaCore developments
> are made available to some members of the ARG (!) to check that they are
> acceptable.

Since the vendors were ignoring what the ARG was trying to do, and there is 
very little use of "standard" ASIS anyway (most applications only work with 
one implementation -- we really only need a standard for applications that 
will be ported from one implementation to another), it isn't worth anyone's 
effort to make a standard. Vendors claim that their customers don't care 
about a standard for ASIS. If ASIS customers were to demand that their 
vendors supported a standard, then things would be different, but there is 
no evidence of that (beyond Mr. Rosen -- which is surely not enough).

The ASIS 95 standard is quite a mess; it wouldn't be possible to create an 
ASIS implementation just from reading the standard. One would have to see 
what other implementations do. (That's true to some extent for all 
standards, but the ASIS standard is worse. And, at least for the Ada 
standard we have the ACATS to provide some additional insight into what a 
correct implementation needs to do.)

                              Randy.