* a new language, designed for safety ! @ 2014-06-03 1:37 Nasser M. Abbasi 2014-06-04 0:21 ` Luke A. Guest ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Nasser M. Abbasi @ 2014-06-03 1:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-03 1:37 a new language, designed for safety ! Nasser M. Abbasi @ 2014-06-04 0:21 ` Luke A. Guest 2014-06-04 1:19 ` Dan'l Miller 2014-06-04 5:44 ` Jeffrey Carter 2014-06-04 15:25 ` Dan'l Miller 2014-06-09 10:03 ` Pascal Obry 2 siblings, 2 replies; 285+ messages in thread From: Luke A. Guest @ 2014-06-04 0:21 UTC (permalink / raw) Quel surprise, it's YAC (yet another C) ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 0:21 ` Luke A. Guest @ 2014-06-04 1:19 ` Dan'l Miller 2014-06-04 4:05 ` Dan'l Miller 2014-06-04 4:12 ` Dan'l Miller 2014-06-04 5:44 ` Jeffrey Carter 1 sibling, 2 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-04 1:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 1:19 ` Dan'l Miller @ 2014-06-04 4:05 ` Dan'l Miller 2014-06-04 6:59 ` Georg Bauhaus 2014-06-04 4:12 ` Dan'l Miller 1 sibling, 1 reply; 285+ messages in thread From: Dan'l Miller @ 2014-06-04 4:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 4:05 ` Dan'l Miller @ 2014-06-04 6:59 ` Georg Bauhaus 0 siblings, 0 replies; 285+ messages in thread From: Georg Bauhaus @ 2014-06-04 6:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 1:19 ` Dan'l Miller 2014-06-04 4:05 ` Dan'l Miller @ 2014-06-04 4:12 ` Dan'l Miller 1 sibling, 0 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-04 4:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 0:21 ` Luke A. Guest 2014-06-04 1:19 ` Dan'l Miller @ 2014-06-04 5:44 ` Jeffrey Carter 1 sibling, 0 replies; 285+ messages in thread From: Jeffrey Carter @ 2014-06-04 5:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-03 1:37 a new language, designed for safety ! Nasser M. Abbasi 2014-06-04 0:21 ` Luke A. Guest @ 2014-06-04 15:25 ` Dan'l Miller 2014-06-04 19:43 ` Robert A Duff 2014-06-05 8:26 ` Georg Bauhaus 2014-06-09 10:03 ` Pascal Obry 2 siblings, 2 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-04 15:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 15:25 ` Dan'l Miller @ 2014-06-04 19:43 ` Robert A Duff 2014-06-04 21:32 ` Simon Clubley 2014-06-05 9:13 ` Nasser M. Abbasi 2014-06-05 8:26 ` Georg Bauhaus 1 sibling, 2 replies; 285+ messages in thread From: Robert A Duff @ 2014-06-04 19:43 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 19:43 ` Robert A Duff @ 2014-06-04 21:32 ` Simon Clubley 2014-06-05 9:13 ` Nasser M. Abbasi 1 sibling, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-04 21:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 19:43 ` Robert A Duff 2014-06-04 21:32 ` Simon Clubley @ 2014-06-05 9:13 ` Nasser M. Abbasi 2014-06-05 15:33 ` Adam Beneschan ` (3 more replies) 1 sibling, 4 replies; 285+ messages in thread From: Nasser M. Abbasi @ 2014-06-05 9:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-05 9:13 ` Nasser M. Abbasi @ 2014-06-05 15:33 ` Adam Beneschan 2014-06-05 19:19 ` Jeffrey Carter 2014-06-05 15:55 ` Adam Beneschan ` (2 subsequent siblings) 3 siblings, 1 reply; 285+ messages in thread From: Adam Beneschan @ 2014-06-05 15:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-05 15:33 ` Adam Beneschan @ 2014-06-05 19:19 ` Jeffrey Carter 0 siblings, 0 replies; 285+ messages in thread From: Jeffrey Carter @ 2014-06-05 19:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-05 9:13 ` Nasser M. Abbasi 2014-06-05 15:33 ` Adam Beneschan @ 2014-06-05 15:55 ` Adam Beneschan 2014-06-05 19:15 ` sbelmont700 2014-06-05 22:40 ` Robert A Duff 2014-06-23 0:40 ` Yannick Duchêne (Hibou57) 3 siblings, 1 reply; 285+ messages in thread From: Adam Beneschan @ 2014-06-05 15:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-05 15:55 ` Adam Beneschan @ 2014-06-05 19:15 ` sbelmont700 0 siblings, 0 replies; 285+ messages in thread From: sbelmont700 @ 2014-06-05 19:15 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-05 9:13 ` Nasser M. Abbasi 2014-06-05 15:33 ` Adam Beneschan 2014-06-05 15:55 ` Adam Beneschan @ 2014-06-05 22:40 ` Robert A Duff 2014-06-06 15:13 ` Dan'l Miller 2014-06-23 0:40 ` Yannick Duchêne (Hibou57) 3 siblings, 1 reply; 285+ messages in thread From: Robert A Duff @ 2014-06-05 22:40 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-05 22:40 ` Robert A Duff @ 2014-06-06 15:13 ` Dan'l Miller 2014-06-06 17:51 ` G.B. 2014-06-06 18:52 ` Robert A Duff 0 siblings, 2 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-06 15:13 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-06 15:13 ` Dan'l Miller @ 2014-06-06 17:51 ` G.B. 2014-06-06 18:39 ` Niklas Holsti 2014-06-06 18:52 ` Robert A Duff 1 sibling, 1 reply; 285+ messages in thread From: G.B. @ 2014-06-06 17:51 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-06 17:51 ` G.B. @ 2014-06-06 18:39 ` Niklas Holsti 2014-06-06 19:43 ` Robert A Duff 2014-06-08 9:40 ` Georg Bauhaus 0 siblings, 2 replies; 285+ messages in thread From: Niklas Holsti @ 2014-06-06 18:39 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-06 18:39 ` Niklas Holsti @ 2014-06-06 19:43 ` Robert A Duff 2014-06-06 20:42 ` Dmitry A. Kazakov 2014-06-08 9:40 ` Georg Bauhaus 1 sibling, 1 reply; 285+ messages in thread From: Robert A Duff @ 2014-06-06 19:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-06 19:43 ` Robert A Duff @ 2014-06-06 20:42 ` Dmitry A. Kazakov 0 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-06 20:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-06 18:39 ` Niklas Holsti 2014-06-06 19:43 ` Robert A Duff @ 2014-06-08 9:40 ` Georg Bauhaus 2014-06-08 13:56 ` Robert A Duff 1 sibling, 1 reply; 285+ messages in thread From: Georg Bauhaus @ 2014-06-08 9:40 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-08 9:40 ` Georg Bauhaus @ 2014-06-08 13:56 ` Robert A Duff 2014-06-08 16:13 ` Dan'l Miller 0 siblings, 1 reply; 285+ messages in thread From: Robert A Duff @ 2014-06-08 13:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-08 13:56 ` Robert A Duff @ 2014-06-08 16:13 ` Dan'l Miller 2014-06-08 17:22 ` J-P. Rosen 2014-06-08 19:36 ` Dmitry A. Kazakov 0 siblings, 2 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-08 16:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-08 16:13 ` Dan'l Miller @ 2014-06-08 17:22 ` J-P. Rosen 2014-06-08 19:36 ` Dmitry A. Kazakov 1 sibling, 0 replies; 285+ messages in thread From: J-P. Rosen @ 2014-06-08 17:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-08 16:13 ` Dan'l Miller 2014-06-08 17:22 ` J-P. Rosen @ 2014-06-08 19:36 ` Dmitry A. Kazakov 2014-06-09 5:30 ` Niklas Holsti 1 sibling, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-08 19:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-08 19:36 ` Dmitry A. Kazakov @ 2014-06-09 5:30 ` Niklas Holsti 2014-06-09 7:06 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Niklas Holsti @ 2014-06-09 5:30 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-09 5:30 ` Niklas Holsti @ 2014-06-09 7:06 ` Dmitry A. Kazakov 2014-06-09 16:07 ` Dan'l Miller 0 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-09 7:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-09 7:06 ` Dmitry A. Kazakov @ 2014-06-09 16:07 ` Dan'l Miller 2014-06-10 7:44 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Dan'l Miller @ 2014-06-09 16:07 UTC (permalink / raw) 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].) ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-09 16:07 ` Dan'l Miller @ 2014-06-10 7:44 ` Dmitry A. Kazakov 2014-06-10 16:31 ` Dan'l Miller 0 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-10 7:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 7:44 ` Dmitry A. Kazakov @ 2014-06-10 16:31 ` Dan'l Miller 2014-06-10 16:52 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Dan'l Miller @ 2014-06-10 16:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 16:31 ` Dan'l Miller @ 2014-06-10 16:52 ` Dmitry A. Kazakov 0 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-10 16:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-06 15:13 ` Dan'l Miller 2014-06-06 17:51 ` G.B. @ 2014-06-06 18:52 ` Robert A Duff 2014-06-06 22:50 ` Simon Clubley 1 sibling, 1 reply; 285+ messages in thread From: Robert A Duff @ 2014-06-06 18:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-06 18:52 ` Robert A Duff @ 2014-06-06 22:50 ` Simon Clubley 0 siblings, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-06 22:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-05 9:13 ` Nasser M. Abbasi ` (2 preceding siblings ...) 2014-06-05 22:40 ` Robert A Duff @ 2014-06-23 0:40 ` Yannick Duchêne (Hibou57) 2014-06-23 0:43 ` Yannick Duchêne (Hibou57) 3 siblings, 1 reply; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-23 0:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-23 0:40 ` Yannick Duchêne (Hibou57) @ 2014-06-23 0:43 ` Yannick Duchêne (Hibou57) 2014-06-23 0:51 ` Shark8 0 siblings, 1 reply; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-23 0:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-23 0:43 ` Yannick Duchêne (Hibou57) @ 2014-06-23 0:51 ` Shark8 2014-06-23 1:47 ` Nasser M. Abbasi 2014-06-23 14:17 ` Peter Chapin 0 siblings, 2 replies; 285+ messages in thread From: Shark8 @ 2014-06-23 0:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-23 0:51 ` Shark8 @ 2014-06-23 1:47 ` Nasser M. Abbasi 2014-06-23 6:46 ` Shark8 2014-06-23 14:17 ` Peter Chapin 1 sibling, 1 reply; 285+ messages in thread From: Nasser M. Abbasi @ 2014-06-23 1:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-23 1:47 ` Nasser M. Abbasi @ 2014-06-23 6:46 ` Shark8 0 siblings, 0 replies; 285+ messages in thread From: Shark8 @ 2014-06-23 6:46 UTC (permalink / raw) Interesting; thanks for the examples. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-23 0:51 ` Shark8 2014-06-23 1:47 ` Nasser M. Abbasi @ 2014-06-23 14:17 ` Peter Chapin 2014-06-23 15:39 ` Dan'l Miller 2014-06-23 17:04 ` Dmitry A. Kazakov 1 sibling, 2 replies; 285+ messages in thread From: Peter Chapin @ 2014-06-23 14:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-23 14:17 ` Peter Chapin @ 2014-06-23 15:39 ` Dan'l Miller 2014-06-23 17:04 ` Dmitry A. Kazakov 1 sibling, 0 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-23 15:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-23 14:17 ` Peter Chapin 2014-06-23 15:39 ` Dan'l Miller @ 2014-06-23 17:04 ` Dmitry A. Kazakov 1 sibling, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-23 17:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-04 15:25 ` Dan'l Miller 2014-06-04 19:43 ` Robert A Duff @ 2014-06-05 8:26 ` Georg Bauhaus 1 sibling, 0 replies; 285+ messages in thread From: Georg Bauhaus @ 2014-06-05 8:26 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-03 1:37 a new language, designed for safety ! Nasser M. Abbasi 2014-06-04 0:21 ` Luke A. Guest 2014-06-04 15:25 ` Dan'l Miller @ 2014-06-09 10:03 ` Pascal Obry 2014-06-10 9:36 ` Stephen Leake 2 siblings, 1 reply; 285+ messages in thread From: Pascal Obry @ 2014-06-09 10:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-09 10:03 ` Pascal Obry @ 2014-06-10 9:36 ` Stephen Leake 2014-06-10 10:48 ` Luke A. Guest ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Stephen Leake @ 2014-06-10 9:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 9:36 ` Stephen Leake @ 2014-06-10 10:48 ` Luke A. Guest 2014-06-10 18:31 ` Pascal Obry 2014-06-10 12:28 ` Simon Clubley 2014-06-11 8:27 ` Maciej Sobczak 2 siblings, 1 reply; 285+ messages in thread From: Luke A. Guest @ 2014-06-10 10:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 10:48 ` Luke A. Guest @ 2014-06-10 18:31 ` Pascal Obry 2014-06-23 1:01 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 285+ messages in thread From: Pascal Obry @ 2014-06-10 18:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 18:31 ` Pascal Obry @ 2014-06-23 1:01 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-23 1:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 9:36 ` Stephen Leake 2014-06-10 10:48 ` Luke A. Guest @ 2014-06-10 12:28 ` Simon Clubley 2014-06-10 12:42 ` Lucretia 2014-06-11 8:27 ` Maciej Sobczak 2 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-10 12:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 12:28 ` Simon Clubley @ 2014-06-10 12:42 ` Lucretia 2014-06-10 12:50 ` J-P. Rosen ` (3 more replies) 0 siblings, 4 replies; 285+ messages in thread From: Lucretia @ 2014-06-10 12:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 12:42 ` Lucretia @ 2014-06-10 12:50 ` J-P. Rosen 2014-06-10 13:00 ` Lucretia 2014-06-10 20:22 ` Simon Clubley ` (2 subsequent siblings) 3 siblings, 1 reply; 285+ messages in thread From: J-P. Rosen @ 2014-06-10 12:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 12:50 ` J-P. Rosen @ 2014-06-10 13:00 ` Lucretia 2014-06-10 14:43 ` Brad Moore 0 siblings, 1 reply; 285+ messages in thread From: Lucretia @ 2014-06-10 13:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 13:00 ` Lucretia @ 2014-06-10 14:43 ` Brad Moore 2014-06-10 15:15 ` J-P. Rosen ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Brad Moore @ 2014-06-10 14:43 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 14:43 ` Brad Moore @ 2014-06-10 15:15 ` J-P. Rosen 2014-06-10 20:28 ` Simon Clubley 2014-06-10 15:33 ` Lucretia 2014-06-12 23:56 ` Shark8 2 siblings, 1 reply; 285+ messages in thread From: J-P. Rosen @ 2014-06-10 15:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 15:15 ` J-P. Rosen @ 2014-06-10 20:28 ` Simon Clubley 2014-06-10 20:39 ` Pascal Obry ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-10 20:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 20:28 ` Simon Clubley @ 2014-06-10 20:39 ` Pascal Obry 2014-06-10 21:04 ` Simon Clubley 2014-06-10 22:09 ` Luke A. Guest 2014-06-11 0:16 ` Jeffrey Carter 2 siblings, 1 reply; 285+ messages in thread From: Pascal Obry @ 2014-06-10 20:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 20:39 ` Pascal Obry @ 2014-06-10 21:04 ` Simon Clubley 2014-06-11 7:17 ` Pascal Obry 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-10 21:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 21:04 ` Simon Clubley @ 2014-06-11 7:17 ` Pascal Obry 2014-06-25 22:37 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 285+ messages in thread From: Pascal Obry @ 2014-06-11 7:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 7:17 ` Pascal Obry @ 2014-06-25 22:37 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-25 22:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 20:28 ` Simon Clubley 2014-06-10 20:39 ` Pascal Obry @ 2014-06-10 22:09 ` Luke A. Guest 2014-06-12 23:58 ` Shark8 2014-06-25 22:40 ` Yannick Duchêne (Hibou57) 2014-06-11 0:16 ` Jeffrey Carter 2 siblings, 2 replies; 285+ messages in thread From: Luke A. Guest @ 2014-06-10 22:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 22:09 ` Luke A. Guest @ 2014-06-12 23:58 ` Shark8 2014-06-13 1:28 ` Luke A. Guest 2014-06-25 22:40 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 285+ messages in thread From: Shark8 @ 2014-06-12 23:58 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 23:58 ` Shark8 @ 2014-06-13 1:28 ` Luke A. Guest 2014-06-25 22:41 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 285+ messages in thread From: Luke A. Guest @ 2014-06-13 1:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 1:28 ` Luke A. Guest @ 2014-06-25 22:41 ` Yannick Duchêne (Hibou57) 2014-06-26 1:36 ` Shark8 2014-06-26 10:19 ` J-P. Rosen 0 siblings, 2 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-25 22:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-25 22:41 ` Yannick Duchêne (Hibou57) @ 2014-06-26 1:36 ` Shark8 2014-06-26 10:19 ` J-P. Rosen 1 sibling, 0 replies; 285+ messages in thread From: Shark8 @ 2014-06-26 1:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-25 22:41 ` Yannick Duchêne (Hibou57) 2014-06-26 1:36 ` Shark8 @ 2014-06-26 10:19 ` J-P. Rosen 1 sibling, 0 replies; 285+ messages in thread From: J-P. Rosen @ 2014-06-26 10:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 22:09 ` Luke A. Guest 2014-06-12 23:58 ` Shark8 @ 2014-06-25 22:40 ` Yannick Duchêne (Hibou57) 2014-06-26 7:39 ` Luke A. Guest 2014-06-26 10:18 ` J-P. Rosen 1 sibling, 2 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-25 22:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-25 22:40 ` Yannick Duchêne (Hibou57) @ 2014-06-26 7:39 ` Luke A. Guest 2014-06-26 7:42 ` Yannick Duchêne (Hibou57) 2014-06-26 10:18 ` J-P. Rosen 1 sibling, 1 reply; 285+ messages in thread From: Luke A. Guest @ 2014-06-26 7:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-26 7:39 ` Luke A. Guest @ 2014-06-26 7:42 ` Yannick Duchêne (Hibou57) 2014-06-26 10:07 ` Luke A. Guest 0 siblings, 1 reply; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 7:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-26 7:42 ` Yannick Duchêne (Hibou57) @ 2014-06-26 10:07 ` Luke A. Guest 0 siblings, 0 replies; 285+ messages in thread From: Luke A. Guest @ 2014-06-26 10:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-25 22:40 ` Yannick Duchêne (Hibou57) 2014-06-26 7:39 ` Luke A. Guest @ 2014-06-26 10:18 ` J-P. Rosen 2014-07-02 22:06 ` Randy Brukardt 1 sibling, 1 reply; 285+ messages in thread From: J-P. Rosen @ 2014-06-26 10:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-26 10:18 ` J-P. Rosen @ 2014-07-02 22:06 ` Randy Brukardt 0 siblings, 0 replies; 285+ messages in thread From: Randy Brukardt @ 2014-07-02 22:06 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 20:28 ` Simon Clubley 2014-06-10 20:39 ` Pascal Obry 2014-06-10 22:09 ` Luke A. Guest @ 2014-06-11 0:16 ` Jeffrey Carter 2014-06-11 7:29 ` Simon Clubley 2 siblings, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-11 0:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 0:16 ` Jeffrey Carter @ 2014-06-11 7:29 ` Simon Clubley 2014-06-11 19:22 ` Jeffrey Carter 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-11 7:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 7:29 ` Simon Clubley @ 2014-06-11 19:22 ` Jeffrey Carter 2014-06-12 11:48 ` Simon Clubley 0 siblings, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-11 19:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 19:22 ` Jeffrey Carter @ 2014-06-12 11:48 ` Simon Clubley 2014-06-12 16:59 ` Jeffrey Carter 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-12 11:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 11:48 ` Simon Clubley @ 2014-06-12 16:59 ` Jeffrey Carter 0 siblings, 0 replies; 285+ messages in thread From: Jeffrey Carter @ 2014-06-12 16:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 14:43 ` Brad Moore 2014-06-10 15:15 ` J-P. Rosen @ 2014-06-10 15:33 ` Lucretia 2014-06-10 16:31 ` Dmitry A. Kazakov ` (2 more replies) 2014-06-12 23:56 ` Shark8 2 siblings, 3 replies; 285+ messages in thread From: Lucretia @ 2014-06-10 15:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 15:33 ` Lucretia @ 2014-06-10 16:31 ` Dmitry A. Kazakov 2014-06-10 19:34 ` Tero Koskinen 2014-06-10 19:49 ` J-P. Rosen 2014-06-25 22:43 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-10 16:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 16:31 ` Dmitry A. Kazakov @ 2014-06-10 19:34 ` Tero Koskinen 2014-06-11 6:46 ` Natasha Kerensikova ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Tero Koskinen @ 2014-06-10 19:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 19:34 ` Tero Koskinen @ 2014-06-11 6:46 ` Natasha Kerensikova 2014-06-11 8:45 ` Dmitry A. Kazakov 2014-06-11 12:11 ` björn lundin 2 siblings, 0 replies; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-11 6:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 19:34 ` Tero Koskinen 2014-06-11 6:46 ` Natasha Kerensikova @ 2014-06-11 8:45 ` Dmitry A. Kazakov 2014-06-11 9:05 ` Simon Wright 2014-06-11 12:09 ` Simon Clubley 2014-06-11 12:11 ` björn lundin 2 siblings, 2 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-11 8:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 8:45 ` Dmitry A. Kazakov @ 2014-06-11 9:05 ` Simon Wright 2014-06-11 12:09 ` Simon Clubley 1 sibling, 0 replies; 285+ messages in thread From: Simon Wright @ 2014-06-11 9:05 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 8:45 ` Dmitry A. Kazakov 2014-06-11 9:05 ` Simon Wright @ 2014-06-11 12:09 ` Simon Clubley 2014-06-11 12:34 ` Dmitry A. Kazakov 1 sibling, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-11 12:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 12:09 ` Simon Clubley @ 2014-06-11 12:34 ` Dmitry A. Kazakov 2014-06-11 12:42 ` björn lundin 2014-06-11 13:04 ` Lucretia 0 siblings, 2 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-11 12:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 12:34 ` Dmitry A. Kazakov @ 2014-06-11 12:42 ` björn lundin 2014-06-11 13:04 ` Lucretia 1 sibling, 0 replies; 285+ messages in thread From: björn lundin @ 2014-06-11 12:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 12:34 ` Dmitry A. Kazakov 2014-06-11 12:42 ` björn lundin @ 2014-06-11 13:04 ` Lucretia 1 sibling, 0 replies; 285+ messages in thread From: Lucretia @ 2014-06-11 13:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 19:34 ` Tero Koskinen 2014-06-11 6:46 ` Natasha Kerensikova 2014-06-11 8:45 ` Dmitry A. Kazakov @ 2014-06-11 12:11 ` björn lundin 2 siblings, 0 replies; 285+ messages in thread From: björn lundin @ 2014-06-11 12:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 15:33 ` Lucretia 2014-06-10 16:31 ` Dmitry A. Kazakov @ 2014-06-10 19:49 ` J-P. Rosen 2014-06-10 22:09 ` Luke A. Guest 2014-06-25 22:43 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 285+ messages in thread From: J-P. Rosen @ 2014-06-10 19:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 19:49 ` J-P. Rosen @ 2014-06-10 22:09 ` Luke A. Guest 2014-06-11 9:01 ` Simon Wright 2014-06-16 16:22 ` Randy Brukardt 0 siblings, 2 replies; 285+ messages in thread From: Luke A. Guest @ 2014-06-10 22:09 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 22:09 ` Luke A. Guest @ 2014-06-11 9:01 ` Simon Wright 2014-06-16 16:22 ` Randy Brukardt 1 sibling, 0 replies; 285+ messages in thread From: Simon Wright @ 2014-06-11 9:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 22:09 ` Luke A. Guest 2014-06-11 9:01 ` Simon Wright @ 2014-06-16 16:22 ` Randy Brukardt 2014-06-16 17:11 ` Ada platforms and pricing, was: " Simon Clubley 2014-06-16 21:31 ` Luke A. Guest 1 sibling, 2 replies; 285+ messages in thread From: Randy Brukardt @ 2014-06-16 16:22 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-16 16:22 ` Randy Brukardt @ 2014-06-16 17:11 ` Simon Clubley 2014-06-17 19:34 ` Randy Brukardt 2014-06-17 20:27 ` Luke A. Guest 2014-06-16 21:31 ` Luke A. Guest 1 sibling, 2 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-16 17:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-16 17:11 ` Ada platforms and pricing, was: " Simon Clubley @ 2014-06-17 19:34 ` Randy Brukardt 2014-06-17 20:16 ` Jeffrey Carter 2014-06-18 19:57 ` Simon Clubley 2014-06-17 20:27 ` Luke A. Guest 1 sibling, 2 replies; 285+ messages in thread From: Randy Brukardt @ 2014-06-17 19:34 UTC (permalink / raw) "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 :-). ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-17 19:34 ` Randy Brukardt @ 2014-06-17 20:16 ` Jeffrey Carter 2014-06-18 5:56 ` Georg Bauhaus 2014-06-18 19:57 ` Simon Clubley 1 sibling, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-17 20:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-17 20:16 ` Jeffrey Carter @ 2014-06-18 5:56 ` Georg Bauhaus 2014-06-18 6:34 ` Nasser M. Abbasi 0 siblings, 1 reply; 285+ messages in thread From: Georg Bauhaus @ 2014-06-18 5:56 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 5:56 ` Georg Bauhaus @ 2014-06-18 6:34 ` Nasser M. Abbasi 0 siblings, 0 replies; 285+ messages in thread From: Nasser M. Abbasi @ 2014-06-18 6:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-17 19:34 ` Randy Brukardt 2014-06-17 20:16 ` Jeffrey Carter @ 2014-06-18 19:57 ` Simon Clubley 2014-06-19 3:46 ` Randy Brukardt 1 sibling, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-18 19:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 19:57 ` Simon Clubley @ 2014-06-19 3:46 ` Randy Brukardt 2014-06-22 19:50 ` Simon Clubley 0 siblings, 1 reply; 285+ messages in thread From: Randy Brukardt @ 2014-06-19 3:46 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 3:46 ` Randy Brukardt @ 2014-06-22 19:50 ` Simon Clubley 2014-06-22 23:38 ` Randy Brukardt 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-22 19:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-22 19:50 ` Simon Clubley @ 2014-06-22 23:38 ` Randy Brukardt 2014-06-23 6:18 ` Niklas Holsti ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Randy Brukardt @ 2014-06-22 23:38 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-22 23:38 ` Randy Brukardt @ 2014-06-23 6:18 ` Niklas Holsti 2014-06-23 7:42 ` Dmitry A. Kazakov 2014-06-23 7:31 ` Dmitry A. Kazakov 2014-06-24 12:13 ` Simon Clubley 2 siblings, 1 reply; 285+ messages in thread From: Niklas Holsti @ 2014-06-23 6:18 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 6:18 ` Niklas Holsti @ 2014-06-23 7:42 ` Dmitry A. Kazakov 2014-06-23 11:17 ` Simon Wright ` (4 more replies) 0 siblings, 5 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-23 7:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 7:42 ` Dmitry A. Kazakov @ 2014-06-23 11:17 ` Simon Wright 2014-06-23 17:14 ` Dmitry A. Kazakov 2014-06-23 11:48 ` G.B. ` (3 subsequent siblings) 4 siblings, 1 reply; 285+ messages in thread From: Simon Wright @ 2014-06-23 11:17 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 11:17 ` Simon Wright @ 2014-06-23 17:14 ` Dmitry A. Kazakov 2014-06-23 19:21 ` Dan'l Miller 2014-06-23 20:40 ` Simon Wright 0 siblings, 2 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-23 17:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 17:14 ` Dmitry A. Kazakov @ 2014-06-23 19:21 ` Dan'l Miller 2014-06-23 20:14 ` Dmitry A. Kazakov 2014-06-24 1:01 ` Shark8 2014-06-23 20:40 ` Simon Wright 1 sibling, 2 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-23 19:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 19:21 ` Dan'l Miller @ 2014-06-23 20:14 ` Dmitry A. Kazakov 2014-06-23 21:48 ` Simon Wright ` (2 more replies) 2014-06-24 1:01 ` Shark8 1 sibling, 3 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-23 20:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 20:14 ` Dmitry A. Kazakov @ 2014-06-23 21:48 ` Simon Wright 2014-06-24 1:18 ` Nasser M. Abbasi 2014-06-24 7:51 ` Dmitry A. Kazakov 2014-06-23 21:52 ` Simon Wright 2014-06-26 3:24 ` Yannick Duchêne (Hibou57) 2 siblings, 2 replies; 285+ messages in thread From: Simon Wright @ 2014-06-23 21:48 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 21:48 ` Simon Wright @ 2014-06-24 1:18 ` Nasser M. Abbasi 2014-06-24 2:15 ` Jeffrey Carter 2014-06-24 7:51 ` Dmitry A. Kazakov 1 sibling, 1 reply; 285+ messages in thread From: Nasser M. Abbasi @ 2014-06-24 1:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 1:18 ` Nasser M. Abbasi @ 2014-06-24 2:15 ` Jeffrey Carter 0 siblings, 0 replies; 285+ messages in thread From: Jeffrey Carter @ 2014-06-24 2:15 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 21:48 ` Simon Wright 2014-06-24 1:18 ` Nasser M. Abbasi @ 2014-06-24 7:51 ` Dmitry A. Kazakov 1 sibling, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-24 7:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 20:14 ` Dmitry A. Kazakov 2014-06-23 21:48 ` Simon Wright @ 2014-06-23 21:52 ` Simon Wright 2014-06-24 1:04 ` Dan'l Miller 2014-06-26 3:24 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 285+ messages in thread From: Simon Wright @ 2014-06-23 21:52 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 21:52 ` Simon Wright @ 2014-06-24 1:04 ` Dan'l Miller 0 siblings, 0 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-24 1:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 20:14 ` Dmitry A. Kazakov 2014-06-23 21:48 ` Simon Wright 2014-06-23 21:52 ` Simon Wright @ 2014-06-26 3:24 ` Yannick Duchêne (Hibou57) 2014-06-26 3:27 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 3:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-26 3:24 ` Yannick Duchêne (Hibou57) @ 2014-06-26 3:27 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 3:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 19:21 ` Dan'l Miller 2014-06-23 20:14 ` Dmitry A. Kazakov @ 2014-06-24 1:01 ` Shark8 2014-06-24 10:24 ` Simon Wright 1 sibling, 1 reply; 285+ messages in thread From: Shark8 @ 2014-06-24 1:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 1:01 ` Shark8 @ 2014-06-24 10:24 ` Simon Wright 2014-06-24 11:25 ` Dan'l Miller 0 siblings, 1 reply; 285+ messages in thread From: Simon Wright @ 2014-06-24 10:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 10:24 ` Simon Wright @ 2014-06-24 11:25 ` Dan'l Miller 2014-06-24 15:55 ` Shark8 ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-24 11:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 11:25 ` Dan'l Miller @ 2014-06-24 15:55 ` Shark8 2014-06-24 18:06 ` Dan'l Miller 2014-06-24 16:48 ` Simon Wright 2014-06-26 3:41 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 285+ messages in thread From: Shark8 @ 2014-06-24 15:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 15:55 ` Shark8 @ 2014-06-24 18:06 ` Dan'l Miller 2014-06-24 18:44 ` Dan'l Miller 2014-06-24 18:49 ` Shark8 0 siblings, 2 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-24 18:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 18:06 ` Dan'l Miller @ 2014-06-24 18:44 ` Dan'l Miller 2014-06-24 18:49 ` Shark8 1 sibling, 0 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-24 18:44 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 18:06 ` Dan'l Miller 2014-06-24 18:44 ` Dan'l Miller @ 2014-06-24 18:49 ` Shark8 2014-06-24 21:25 ` Dan'l Miller 1 sibling, 1 reply; 285+ messages in thread From: Shark8 @ 2014-06-24 18:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 18:49 ` Shark8 @ 2014-06-24 21:25 ` Dan'l Miller 0 siblings, 0 replies; 285+ messages in thread From: Dan'l Miller @ 2014-06-24 21:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 11:25 ` Dan'l Miller 2014-06-24 15:55 ` Shark8 @ 2014-06-24 16:48 ` Simon Wright 2014-06-26 3:41 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 285+ messages in thread From: Simon Wright @ 2014-06-24 16:48 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 11:25 ` Dan'l Miller 2014-06-24 15:55 ` Shark8 2014-06-24 16:48 ` Simon Wright @ 2014-06-26 3:41 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 3:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 17:14 ` Dmitry A. Kazakov 2014-06-23 19:21 ` Dan'l Miller @ 2014-06-23 20:40 ` Simon Wright 2014-06-24 7:48 ` Dmitry A. Kazakov 1 sibling, 1 reply; 285+ messages in thread From: Simon Wright @ 2014-06-23 20:40 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 20:40 ` Simon Wright @ 2014-06-24 7:48 ` Dmitry A. Kazakov 0 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-24 7:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 7:42 ` Dmitry A. Kazakov 2014-06-23 11:17 ` Simon Wright @ 2014-06-23 11:48 ` G.B. 2014-06-24 7:52 ` Maciej Sobczak ` (2 subsequent siblings) 4 siblings, 0 replies; 285+ messages in thread From: G.B. @ 2014-06-23 11:48 UTC (permalink / raw) 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)? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 7:42 ` Dmitry A. Kazakov 2014-06-23 11:17 ` Simon Wright 2014-06-23 11:48 ` G.B. @ 2014-06-24 7:52 ` Maciej Sobczak 2014-06-24 8:33 ` Dmitry A. Kazakov 2014-06-26 2:50 ` Yannick Duchêne (Hibou57) 2014-06-25 17:24 ` Niklas Holsti 2014-06-26 2:43 ` Yannick Duchêne (Hibou57) 4 siblings, 2 replies; 285+ messages in thread From: Maciej Sobczak @ 2014-06-24 7:52 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 7:52 ` Maciej Sobczak @ 2014-06-24 8:33 ` Dmitry A. Kazakov 2014-07-01 10:28 ` Simon Wright 2014-06-26 2:50 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-24 8:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 8:33 ` Dmitry A. Kazakov @ 2014-07-01 10:28 ` Simon Wright 2014-07-01 12:41 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Simon Wright @ 2014-07-01 10:28 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-07-01 10:28 ` Simon Wright @ 2014-07-01 12:41 ` Dmitry A. Kazakov 0 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-07-01 12:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-24 7:52 ` Maciej Sobczak 2014-06-24 8:33 ` Dmitry A. Kazakov @ 2014-06-26 2:50 ` Yannick Duchêne (Hibou57) 2014-06-26 10:04 ` G.B. 1 sibling, 1 reply; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 2:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-26 2:50 ` Yannick Duchêne (Hibou57) @ 2014-06-26 10:04 ` G.B. 2014-06-26 18:20 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 285+ messages in thread From: G.B. @ 2014-06-26 10:04 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-26 10:04 ` G.B. @ 2014-06-26 18:20 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 18:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 7:42 ` Dmitry A. Kazakov ` (2 preceding siblings ...) 2014-06-24 7:52 ` Maciej Sobczak @ 2014-06-25 17:24 ` Niklas Holsti 2014-06-26 2:43 ` Yannick Duchêne (Hibou57) 4 siblings, 0 replies; 285+ messages in thread From: Niklas Holsti @ 2014-06-25 17:24 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 7:42 ` Dmitry A. Kazakov ` (3 preceding siblings ...) 2014-06-25 17:24 ` Niklas Holsti @ 2014-06-26 2:43 ` Yannick Duchêne (Hibou57) 4 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 2:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-22 23:38 ` Randy Brukardt 2014-06-23 6:18 ` Niklas Holsti @ 2014-06-23 7:31 ` Dmitry A. Kazakov 2014-06-23 20:08 ` Randy Brukardt 2014-06-24 12:13 ` Simon Clubley 2 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-23 7:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 7:31 ` Dmitry A. Kazakov @ 2014-06-23 20:08 ` Randy Brukardt 2014-06-23 20:20 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Randy Brukardt @ 2014-06-23 20:08 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 20:08 ` Randy Brukardt @ 2014-06-23 20:20 ` Dmitry A. Kazakov 2014-06-24 11:56 ` Simon Clubley 0 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-23 20:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-23 20:20 ` Dmitry A. Kazakov @ 2014-06-24 11:56 ` Simon Clubley 0 siblings, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-24 11:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-22 23:38 ` Randy Brukardt 2014-06-23 6:18 ` Niklas Holsti 2014-06-23 7:31 ` Dmitry A. Kazakov @ 2014-06-24 12:13 ` Simon Clubley 2 siblings, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-24 12:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-16 17:11 ` Ada platforms and pricing, was: " Simon Clubley 2014-06-17 19:34 ` Randy Brukardt @ 2014-06-17 20:27 ` Luke A. Guest 2014-06-18 7:09 ` Natasha Kerensikova 1 sibling, 1 reply; 285+ messages in thread From: Luke A. Guest @ 2014-06-17 20:27 UTC (permalink / raw) You have nailed it completely. I think we are the only people in this group who seem to grasp this concept. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-17 20:27 ` Luke A. Guest @ 2014-06-18 7:09 ` Natasha Kerensikova 2014-06-18 10:32 ` J-P. Rosen 2014-06-18 17:01 ` Ada platforms and pricing, was: Re: a new language, designed for safety ! Jeffrey Carter 0 siblings, 2 replies; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-18 7:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 7:09 ` Natasha Kerensikova @ 2014-06-18 10:32 ` J-P. Rosen 2014-06-18 11:50 ` Brian Drummond 2014-06-18 17:34 ` Natasha Kerensikova 2014-06-18 17:01 ` Ada platforms and pricing, was: Re: a new language, designed for safety ! Jeffrey Carter 1 sibling, 2 replies; 285+ messages in thread From: J-P. Rosen @ 2014-06-18 10:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 10:32 ` J-P. Rosen @ 2014-06-18 11:50 ` Brian Drummond 2014-06-18 17:34 ` Natasha Kerensikova 1 sibling, 0 replies; 285+ messages in thread From: Brian Drummond @ 2014-06-18 11:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 10:32 ` J-P. Rosen 2014-06-18 11:50 ` Brian Drummond @ 2014-06-18 17:34 ` Natasha Kerensikova 2014-06-18 17:56 ` Peter Chapin ` (2 more replies) 1 sibling, 3 replies; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-18 17:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 17:34 ` Natasha Kerensikova @ 2014-06-18 17:56 ` Peter Chapin 2014-06-19 7:22 ` Natasha Kerensikova 2014-06-18 18:24 ` Lucretia 2014-06-18 18:47 ` Dmitry A. Kazakov 2 siblings, 1 reply; 285+ messages in thread From: Peter Chapin @ 2014-06-18 17:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 17:56 ` Peter Chapin @ 2014-06-19 7:22 ` Natasha Kerensikova 2014-06-19 12:02 ` Peter Chapin 2014-06-19 13:33 ` Lucretia 0 siblings, 2 replies; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-19 7:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 7:22 ` Natasha Kerensikova @ 2014-06-19 12:02 ` Peter Chapin 2014-06-20 7:03 ` Natasha Kerensikova 2014-06-19 13:33 ` Lucretia 1 sibling, 1 reply; 285+ messages in thread From: Peter Chapin @ 2014-06-19 12:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 12:02 ` Peter Chapin @ 2014-06-20 7:03 ` Natasha Kerensikova 0 siblings, 0 replies; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-20 7:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 7:22 ` Natasha Kerensikova 2014-06-19 12:02 ` Peter Chapin @ 2014-06-19 13:33 ` Lucretia 2014-06-20 7:07 ` Natasha Kerensikova 1 sibling, 1 reply; 285+ messages in thread From: Lucretia @ 2014-06-19 13:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 13:33 ` Lucretia @ 2014-06-20 7:07 ` Natasha Kerensikova 2014-06-20 11:44 ` Lucretia 0 siblings, 1 reply; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-20 7:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-20 7:07 ` Natasha Kerensikova @ 2014-06-20 11:44 ` Lucretia 2014-06-20 12:47 ` Dennis Lee Bieber 0 siblings, 1 reply; 285+ messages in thread From: Lucretia @ 2014-06-20 11:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-20 11:44 ` Lucretia @ 2014-06-20 12:47 ` Dennis Lee Bieber 0 siblings, 0 replies; 285+ messages in thread From: Dennis Lee Bieber @ 2014-06-20 12:47 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 17:34 ` Natasha Kerensikova 2014-06-18 17:56 ` Peter Chapin @ 2014-06-18 18:24 ` Lucretia 2014-06-19 7:26 ` Natasha Kerensikova 2014-06-18 18:47 ` Dmitry A. Kazakov 2 siblings, 1 reply; 285+ messages in thread From: Lucretia @ 2014-06-18 18:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 18:24 ` Lucretia @ 2014-06-19 7:26 ` Natasha Kerensikova 0 siblings, 0 replies; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-19 7:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 17:34 ` Natasha Kerensikova 2014-06-18 17:56 ` Peter Chapin 2014-06-18 18:24 ` Lucretia @ 2014-06-18 18:47 ` Dmitry A. Kazakov 2014-06-18 20:17 ` Simon Clubley ` (3 more replies) 2 siblings, 4 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-18 18:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 18:47 ` Dmitry A. Kazakov @ 2014-06-18 20:17 ` Simon Clubley 2014-06-18 22:51 ` Simon Clubley 2014-06-19 3:35 ` Randy Brukardt ` (2 subsequent siblings) 3 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-18 20:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 20:17 ` Simon Clubley @ 2014-06-18 22:51 ` Simon Clubley 2014-06-19 8:51 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-18 22:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 22:51 ` Simon Clubley @ 2014-06-19 8:51 ` Dmitry A. Kazakov 0 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-19 8:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 18:47 ` Dmitry A. Kazakov 2014-06-18 20:17 ` Simon Clubley @ 2014-06-19 3:35 ` Randy Brukardt 2014-06-19 7:34 ` Natasha Kerensikova 2014-06-20 9:54 ` anon 3 siblings, 0 replies; 285+ messages in thread From: Randy Brukardt @ 2014-06-19 3:35 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 18:47 ` Dmitry A. Kazakov 2014-06-18 20:17 ` Simon Clubley 2014-06-19 3:35 ` Randy Brukardt @ 2014-06-19 7:34 ` Natasha Kerensikova 2014-06-19 8:19 ` J-P. Rosen ` (2 more replies) 2014-06-20 9:54 ` anon 3 siblings, 3 replies; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-19 7:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 7:34 ` Natasha Kerensikova @ 2014-06-19 8:19 ` J-P. Rosen 2014-06-19 9:11 ` Dmitry A. Kazakov 2014-06-19 21:03 ` Randy Brukardt 2 siblings, 0 replies; 285+ messages in thread From: J-P. Rosen @ 2014-06-19 8:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 7:34 ` Natasha Kerensikova 2014-06-19 8:19 ` J-P. Rosen @ 2014-06-19 9:11 ` Dmitry A. Kazakov 2014-06-19 12:08 ` Peter Chapin 2014-06-19 21:03 ` Randy Brukardt 2 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-19 9:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 9:11 ` Dmitry A. Kazakov @ 2014-06-19 12:08 ` Peter Chapin 2014-06-19 13:48 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Peter Chapin @ 2014-06-19 12:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 12:08 ` Peter Chapin @ 2014-06-19 13:48 ` Dmitry A. Kazakov 2014-06-19 20:59 ` Randy Brukardt 2014-06-19 21:13 ` Ada platforms and pricing, was: Re: a new language, designed for safety ! Robert A Duff 2 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-19 13:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 12:08 ` Peter Chapin 2014-06-19 13:48 ` Dmitry A. Kazakov @ 2014-06-19 20:59 ` Randy Brukardt 2014-06-26 2:04 ` Yannick Duchêne (Hibou57) 2014-06-19 21:13 ` Ada platforms and pricing, was: Re: a new language, designed for safety ! Robert A Duff 2 siblings, 1 reply; 285+ messages in thread From: Randy Brukardt @ 2014-06-19 20:59 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 20:59 ` Randy Brukardt @ 2014-06-26 2:04 ` Yannick Duchêne (Hibou57) 2014-06-26 22:24 ` Shark8 0 siblings, 1 reply; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 2:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-26 2:04 ` Yannick Duchêne (Hibou57) @ 2014-06-26 22:24 ` Shark8 2014-06-26 22:44 ` Yannick Duchêne (Hibou57) 2014-06-27 12:43 ` Ada platforms and pricing, was: Re: a new language, anon 0 siblings, 2 replies; 285+ messages in thread From: Shark8 @ 2014-06-26 22:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-26 22:24 ` Shark8 @ 2014-06-26 22:44 ` Yannick Duchêne (Hibou57) 2014-06-26 22:51 ` Shark8 2014-06-27 12:43 ` Ada platforms and pricing, was: Re: a new language, anon 1 sibling, 1 reply; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 22:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-26 22:44 ` Yannick Duchêne (Hibou57) @ 2014-06-26 22:51 ` Shark8 0 siblings, 0 replies; 285+ messages in thread From: Shark8 @ 2014-06-26 22:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, 2014-06-26 22:24 ` Shark8 2014-06-26 22:44 ` Yannick Duchêne (Hibou57) @ 2014-06-27 12:43 ` anon 1 sibling, 0 replies; 285+ messages in thread From: anon @ 2014-06-27 12:43 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 12:08 ` Peter Chapin 2014-06-19 13:48 ` Dmitry A. Kazakov 2014-06-19 20:59 ` Randy Brukardt @ 2014-06-19 21:13 ` Robert A Duff 2014-06-19 23:47 ` Adam Beneschan 2 siblings, 1 reply; 285+ messages in thread From: Robert A Duff @ 2014-06-19 21:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 21:13 ` Ada platforms and pricing, was: Re: a new language, designed for safety ! Robert A Duff @ 2014-06-19 23:47 ` Adam Beneschan 0 siblings, 0 replies; 285+ messages in thread From: Adam Beneschan @ 2014-06-19 23:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 7:34 ` Natasha Kerensikova 2014-06-19 8:19 ` J-P. Rosen 2014-06-19 9:11 ` Dmitry A. Kazakov @ 2014-06-19 21:03 ` Randy Brukardt 2014-06-20 7:26 ` Natasha Kerensikova 2 siblings, 1 reply; 285+ messages in thread From: Randy Brukardt @ 2014-06-19 21:03 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 21:03 ` Randy Brukardt @ 2014-06-20 7:26 ` Natasha Kerensikova 2014-06-20 19:50 ` Randy Brukardt 0 siblings, 1 reply; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-20 7:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-20 7:26 ` Natasha Kerensikova @ 2014-06-20 19:50 ` Randy Brukardt 2014-06-21 8:35 ` Natasha Kerensikova 0 siblings, 1 reply; 285+ messages in thread From: Randy Brukardt @ 2014-06-20 19:50 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-20 19:50 ` Randy Brukardt @ 2014-06-21 8:35 ` Natasha Kerensikova 2014-06-22 23:26 ` Randy Brukardt 2014-06-26 2:16 ` Yannick Duchêne (Hibou57) 0 siblings, 2 replies; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-21 8:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-21 8:35 ` Natasha Kerensikova @ 2014-06-22 23:26 ` Randy Brukardt 2014-06-26 2:16 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 285+ messages in thread From: Randy Brukardt @ 2014-06-22 23:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-21 8:35 ` Natasha Kerensikova 2014-06-22 23:26 ` Randy Brukardt @ 2014-06-26 2:16 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 2:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 18:47 ` Dmitry A. Kazakov ` (2 preceding siblings ...) 2014-06-19 7:34 ` Natasha Kerensikova @ 2014-06-20 9:54 ` anon 2014-06-20 12:25 ` Lucretia 3 siblings, 1 reply; 285+ messages in thread From: anon @ 2014-06-20 9:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-20 9:54 ` anon @ 2014-06-20 12:25 ` Lucretia 2014-06-20 19:32 ` Ada platforms and pricing, was: Re: a new language, designed for anon 0 siblings, 1 reply; 285+ messages in thread From: Lucretia @ 2014-06-20 12:25 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for 2014-06-20 12:25 ` Lucretia @ 2014-06-20 19:32 ` anon 0 siblings, 0 replies; 285+ messages in thread From: anon @ 2014-06-20 19:32 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 7:09 ` Natasha Kerensikova 2014-06-18 10:32 ` J-P. Rosen @ 2014-06-18 17:01 ` Jeffrey Carter 2014-06-19 7:53 ` Natasha Kerensikova 1 sibling, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-18 17:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-18 17:01 ` Ada platforms and pricing, was: Re: a new language, designed for safety ! Jeffrey Carter @ 2014-06-19 7:53 ` Natasha Kerensikova 2014-06-19 21:10 ` Randy Brukardt 0 siblings, 1 reply; 285+ messages in thread From: Natasha Kerensikova @ 2014-06-19 7:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 7:53 ` Natasha Kerensikova @ 2014-06-19 21:10 ` Randy Brukardt 2014-06-19 22:27 ` Luke A. Guest 0 siblings, 1 reply; 285+ messages in thread From: Randy Brukardt @ 2014-06-19 21:10 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! 2014-06-19 21:10 ` Randy Brukardt @ 2014-06-19 22:27 ` Luke A. Guest 0 siblings, 0 replies; 285+ messages in thread From: Luke A. Guest @ 2014-06-19 22:27 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 16:22 ` Randy Brukardt 2014-06-16 17:11 ` Ada platforms and pricing, was: " Simon Clubley @ 2014-06-16 21:31 ` Luke A. Guest 2014-06-16 23:02 ` Jeffrey Carter 1 sibling, 1 reply; 285+ messages in thread From: Luke A. Guest @ 2014-06-16 21:31 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 21:31 ` Luke A. Guest @ 2014-06-16 23:02 ` Jeffrey Carter 2014-06-17 11:14 ` gvdschoot 2014-06-17 12:56 ` Simon Clubley 0 siblings, 2 replies; 285+ messages in thread From: Jeffrey Carter @ 2014-06-16 23:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 23:02 ` Jeffrey Carter @ 2014-06-17 11:14 ` gvdschoot 2014-06-17 17:42 ` Jeffrey Carter 2014-06-17 12:56 ` Simon Clubley 1 sibling, 1 reply; 285+ messages in thread From: gvdschoot @ 2014-06-17 11:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 11:14 ` gvdschoot @ 2014-06-17 17:42 ` Jeffrey Carter 0 siblings, 0 replies; 285+ messages in thread From: Jeffrey Carter @ 2014-06-17 17:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 23:02 ` Jeffrey Carter 2014-06-17 11:14 ` gvdschoot @ 2014-06-17 12:56 ` Simon Clubley 2014-06-17 17:43 ` Jeffrey Carter 2014-06-17 19:41 ` Randy Brukardt 1 sibling, 2 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-17 12:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 12:56 ` Simon Clubley @ 2014-06-17 17:43 ` Jeffrey Carter 2014-06-17 19:46 ` Jacob Sparre Andersen 2014-06-17 19:41 ` Randy Brukardt 1 sibling, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-17 17:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 17:43 ` Jeffrey Carter @ 2014-06-17 19:46 ` Jacob Sparre Andersen 2014-06-26 1:20 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 285+ messages in thread From: Jacob Sparre Andersen @ 2014-06-17 19:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 19:46 ` Jacob Sparre Andersen @ 2014-06-26 1:20 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-26 1:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 12:56 ` Simon Clubley 2014-06-17 17:43 ` Jeffrey Carter @ 2014-06-17 19:41 ` Randy Brukardt 2014-06-17 20:08 ` Jeffrey Carter 1 sibling, 1 reply; 285+ messages in thread From: Randy Brukardt @ 2014-06-17 19:41 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 19:41 ` Randy Brukardt @ 2014-06-17 20:08 ` Jeffrey Carter 2014-06-18 5:46 ` Georg Bauhaus 0 siblings, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-17 20:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 20:08 ` Jeffrey Carter @ 2014-06-18 5:46 ` Georg Bauhaus 2014-06-18 8:02 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Georg Bauhaus @ 2014-06-18 5:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-18 5:46 ` Georg Bauhaus @ 2014-06-18 8:02 ` Dmitry A. Kazakov 2014-06-18 9:34 ` G.B. 0 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-18 8:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-18 8:02 ` Dmitry A. Kazakov @ 2014-06-18 9:34 ` G.B. 2014-06-18 12:30 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: G.B. @ 2014-06-18 9:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-18 9:34 ` G.B. @ 2014-06-18 12:30 ` Dmitry A. Kazakov 2014-06-18 14:43 ` G.B. 0 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-18 12:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-18 12:30 ` Dmitry A. Kazakov @ 2014-06-18 14:43 ` G.B. 2014-06-18 16:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: G.B. @ 2014-06-18 14:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-18 14:43 ` G.B. @ 2014-06-18 16:39 ` Dmitry A. Kazakov 2014-06-20 8:27 ` Georg Bauhaus 0 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-18 16:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-18 16:39 ` Dmitry A. Kazakov @ 2014-06-20 8:27 ` Georg Bauhaus 0 siblings, 0 replies; 285+ messages in thread From: Georg Bauhaus @ 2014-06-20 8:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 15:33 ` Lucretia 2014-06-10 16:31 ` Dmitry A. Kazakov 2014-06-10 19:49 ` J-P. Rosen @ 2014-06-25 22:43 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-25 22:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 14:43 ` Brad Moore 2014-06-10 15:15 ` J-P. Rosen 2014-06-10 15:33 ` Lucretia @ 2014-06-12 23:56 ` Shark8 2 siblings, 0 replies; 285+ messages in thread From: Shark8 @ 2014-06-12 23:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 12:42 ` Lucretia 2014-06-10 12:50 ` J-P. Rosen @ 2014-06-10 20:22 ` Simon Clubley 2014-06-10 21:14 ` Simon Clubley ` (2 more replies) 2014-06-12 23:53 ` Shark8 2014-06-25 6:28 ` Yannick Duchêne (Hibou57) 3 siblings, 3 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-10 20:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 20:22 ` Simon Clubley @ 2014-06-10 21:14 ` Simon Clubley 2014-06-10 22:09 ` Luke A. Guest 2014-06-10 22:09 ` Luke A. Guest 2014-06-11 0:05 ` Jeffrey Carter 2 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-10 21:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 21:14 ` Simon Clubley @ 2014-06-10 22:09 ` Luke A. Guest 0 siblings, 0 replies; 285+ messages in thread From: Luke A. Guest @ 2014-06-10 22:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 20:22 ` Simon Clubley 2014-06-10 21:14 ` Simon Clubley @ 2014-06-10 22:09 ` Luke A. Guest 2014-06-11 0:05 ` Jeffrey Carter 2 siblings, 0 replies; 285+ messages in thread From: Luke A. Guest @ 2014-06-10 22:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 20:22 ` Simon Clubley 2014-06-10 21:14 ` Simon Clubley 2014-06-10 22:09 ` Luke A. Guest @ 2014-06-11 0:05 ` Jeffrey Carter 2014-06-11 7:32 ` Simon Clubley 2 siblings, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-11 0:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 0:05 ` Jeffrey Carter @ 2014-06-11 7:32 ` Simon Clubley 2014-06-11 16:50 ` G.B. 2014-06-11 19:20 ` Jeffrey Carter 0 siblings, 2 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-11 7:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 7:32 ` Simon Clubley @ 2014-06-11 16:50 ` G.B. 2014-06-11 19:20 ` Jeffrey Carter 1 sibling, 0 replies; 285+ messages in thread From: G.B. @ 2014-06-11 16:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 7:32 ` Simon Clubley 2014-06-11 16:50 ` G.B. @ 2014-06-11 19:20 ` Jeffrey Carter 2014-06-12 7:01 ` Simon Clubley 1 sibling, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-11 19:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 19:20 ` Jeffrey Carter @ 2014-06-12 7:01 ` Simon Clubley 2014-06-12 17:46 ` Jeffrey Carter 2014-06-25 6:42 ` Yannick Duchêne (Hibou57) 0 siblings, 2 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-12 7:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 7:01 ` Simon Clubley @ 2014-06-12 17:46 ` Jeffrey Carter 2014-06-12 21:40 ` Simon Clubley 2014-06-25 6:42 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-12 17:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 17:46 ` Jeffrey Carter @ 2014-06-12 21:40 ` Simon Clubley 2014-06-13 6:37 ` J-P. Rosen 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-12 21:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 21:40 ` Simon Clubley @ 2014-06-13 6:37 ` J-P. Rosen 2014-06-13 12:03 ` Simon Clubley 0 siblings, 1 reply; 285+ messages in thread From: J-P. Rosen @ 2014-06-13 6:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 6:37 ` J-P. Rosen @ 2014-06-13 12:03 ` Simon Clubley 2014-06-13 15:34 ` Lucretia 2014-06-13 22:21 ` Brian Drummond 0 siblings, 2 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-13 12:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 12:03 ` Simon Clubley @ 2014-06-13 15:34 ` Lucretia 2014-06-13 17:00 ` Simon Clubley 2014-06-13 22:21 ` Brian Drummond 1 sibling, 1 reply; 285+ messages in thread From: Lucretia @ 2014-06-13 15:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 15:34 ` Lucretia @ 2014-06-13 17:00 ` Simon Clubley 0 siblings, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-13 17:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 12:03 ` Simon Clubley 2014-06-13 15:34 ` Lucretia @ 2014-06-13 22:21 ` Brian Drummond 2014-06-14 20:41 ` Simon Clubley 1 sibling, 1 reply; 285+ messages in thread From: Brian Drummond @ 2014-06-13 22:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 22:21 ` Brian Drummond @ 2014-06-14 20:41 ` Simon Clubley 2014-06-15 6:26 ` Tero Koskinen 2014-06-15 18:10 ` Luke A. Guest 0 siblings, 2 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-14 20:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-14 20:41 ` Simon Clubley @ 2014-06-15 6:26 ` Tero Koskinen 2014-06-16 0:11 ` Simon Clubley 2014-06-15 18:10 ` Luke A. Guest 1 sibling, 1 reply; 285+ messages in thread From: Tero Koskinen @ 2014-06-15 6:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 6:26 ` Tero Koskinen @ 2014-06-16 0:11 ` Simon Clubley 0 siblings, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-16 0:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-14 20:41 ` Simon Clubley 2014-06-15 6:26 ` Tero Koskinen @ 2014-06-15 18:10 ` Luke A. Guest 2014-06-16 0:00 ` Simon Clubley 1 sibling, 1 reply; 285+ messages in thread From: Luke A. Guest @ 2014-06-15 18:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 18:10 ` Luke A. Guest @ 2014-06-16 0:00 ` Simon Clubley 0 siblings, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 7:01 ` Simon Clubley 2014-06-12 17:46 ` Jeffrey Carter @ 2014-06-25 6:42 ` Yannick Duchêne (Hibou57) 2014-06-25 7:29 ` Georg Bauhaus 2014-06-25 12:17 ` Simon Clubley 1 sibling, 2 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-25 6:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-25 6:42 ` Yannick Duchêne (Hibou57) @ 2014-06-25 7:29 ` Georg Bauhaus 2014-06-25 12:17 ` Simon Clubley 1 sibling, 0 replies; 285+ messages in thread From: Georg Bauhaus @ 2014-06-25 7:29 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-25 6:42 ` Yannick Duchêne (Hibou57) 2014-06-25 7:29 ` Georg Bauhaus @ 2014-06-25 12:17 ` Simon Clubley 1 sibling, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-25 12:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 12:42 ` Lucretia 2014-06-10 12:50 ` J-P. Rosen 2014-06-10 20:22 ` Simon Clubley @ 2014-06-12 23:53 ` Shark8 2014-06-13 4:28 ` Simon Clubley 2014-06-25 6:28 ` Yannick Duchêne (Hibou57) 3 siblings, 1 reply; 285+ messages in thread From: Shark8 @ 2014-06-12 23:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 23:53 ` Shark8 @ 2014-06-13 4:28 ` Simon Clubley 2014-06-13 8:17 ` gvdschoot 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-13 4:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 4:28 ` Simon Clubley @ 2014-06-13 8:17 ` gvdschoot 2014-06-13 13:16 ` Simon Wright 0 siblings, 1 reply; 285+ messages in thread From: gvdschoot @ 2014-06-13 8:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 8:17 ` gvdschoot @ 2014-06-13 13:16 ` Simon Wright 2014-06-13 14:13 ` gvdschoot 2014-06-15 6:33 ` Tero Koskinen 0 siblings, 2 replies; 285+ messages in thread From: Simon Wright @ 2014-06-13 13:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 13:16 ` Simon Wright @ 2014-06-13 14:13 ` gvdschoot 2014-06-13 15:52 ` Shark8 2014-06-13 17:04 ` Simon Clubley 2014-06-15 6:33 ` Tero Koskinen 1 sibling, 2 replies; 285+ messages in thread From: gvdschoot @ 2014-06-13 14:13 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 14:13 ` gvdschoot @ 2014-06-13 15:52 ` Shark8 2014-06-13 17:04 ` Simon Clubley 1 sibling, 0 replies; 285+ messages in thread From: Shark8 @ 2014-06-13 15:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 14:13 ` gvdschoot 2014-06-13 15:52 ` Shark8 @ 2014-06-13 17:04 ` Simon Clubley 2014-06-13 20:10 ` Simon Wright 1 sibling, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-13 17:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 17:04 ` Simon Clubley @ 2014-06-13 20:10 ` Simon Wright 0 siblings, 0 replies; 285+ messages in thread From: Simon Wright @ 2014-06-13 20:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 13:16 ` Simon Wright 2014-06-13 14:13 ` gvdschoot @ 2014-06-15 6:33 ` Tero Koskinen 2014-06-15 7:47 ` gvdschoot 1 sibling, 1 reply; 285+ messages in thread From: Tero Koskinen @ 2014-06-15 6:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 6:33 ` Tero Koskinen @ 2014-06-15 7:47 ` gvdschoot 2014-06-15 8:13 ` gvdschoot ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: gvdschoot @ 2014-06-15 7:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 7:47 ` gvdschoot @ 2014-06-15 8:13 ` gvdschoot 2014-06-15 8:18 ` Nasser M. Abbasi 2014-06-16 0:35 ` Simon Clubley 2 siblings, 0 replies; 285+ messages in thread From: gvdschoot @ 2014-06-15 8:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 7:47 ` gvdschoot 2014-06-15 8:13 ` gvdschoot @ 2014-06-15 8:18 ` Nasser M. Abbasi 2014-06-16 0:16 ` Simon Clubley 2014-06-16 0:35 ` Simon Clubley 2 siblings, 1 reply; 285+ messages in thread From: Nasser M. Abbasi @ 2014-06-15 8:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 8:18 ` Nasser M. Abbasi @ 2014-06-16 0:16 ` Simon Clubley 0 siblings, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-16 0:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 7:47 ` gvdschoot 2014-06-15 8:13 ` gvdschoot 2014-06-15 8:18 ` Nasser M. Abbasi @ 2014-06-16 0:35 ` Simon Clubley 2014-06-16 6:08 ` Georg Bauhaus 2 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-16 0:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 0:35 ` Simon Clubley @ 2014-06-16 6:08 ` Georg Bauhaus 2014-06-16 6:19 ` Georg Bauhaus 2014-06-16 6:22 ` gvdschoot 0 siblings, 2 replies; 285+ messages in thread From: Georg Bauhaus @ 2014-06-16 6:08 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 6:08 ` Georg Bauhaus @ 2014-06-16 6:19 ` Georg Bauhaus 2014-06-16 12:08 ` Peter Chapin 2014-06-16 12:30 ` Simon Clubley 2014-06-16 6:22 ` gvdschoot 1 sibling, 2 replies; 285+ messages in thread From: Georg Bauhaus @ 2014-06-16 6:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 6:19 ` Georg Bauhaus @ 2014-06-16 12:08 ` Peter Chapin 2014-06-25 22:28 ` Yannick Duchêne (Hibou57) 2014-06-16 12:30 ` Simon Clubley 1 sibling, 1 reply; 285+ messages in thread From: Peter Chapin @ 2014-06-16 12:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 12:08 ` Peter Chapin @ 2014-06-25 22:28 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-25 22:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 6:19 ` Georg Bauhaus 2014-06-16 12:08 ` Peter Chapin @ 2014-06-16 12:30 ` Simon Clubley 1 sibling, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-16 12:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 6:08 ` Georg Bauhaus 2014-06-16 6:19 ` Georg Bauhaus @ 2014-06-16 6:22 ` gvdschoot 1 sibling, 0 replies; 285+ messages in thread From: gvdschoot @ 2014-06-16 6:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 12:42 ` Lucretia ` (2 preceding siblings ...) 2014-06-12 23:53 ` Shark8 @ 2014-06-25 6:28 ` Yannick Duchêne (Hibou57) 3 siblings, 0 replies; 285+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-06-25 6:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-10 9:36 ` Stephen Leake 2014-06-10 10:48 ` Luke A. Guest 2014-06-10 12:28 ` Simon Clubley @ 2014-06-11 8:27 ` Maciej Sobczak 2014-06-11 19:39 ` Peter Chapin 2 siblings, 1 reply; 285+ messages in thread From: Maciej Sobczak @ 2014-06-11 8:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 8:27 ` Maciej Sobczak @ 2014-06-11 19:39 ` Peter Chapin 2014-06-11 19:52 ` Luke A. Guest 2014-06-12 8:16 ` Georg Bauhaus 0 siblings, 2 replies; 285+ messages in thread From: Peter Chapin @ 2014-06-11 19:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 19:39 ` Peter Chapin @ 2014-06-11 19:52 ` Luke A. Guest 2014-06-12 1:39 ` Peter Chapin 2014-06-12 8:16 ` Georg Bauhaus 1 sibling, 1 reply; 285+ messages in thread From: Luke A. Guest @ 2014-06-11 19:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 19:52 ` Luke A. Guest @ 2014-06-12 1:39 ` Peter Chapin 2014-06-12 2:46 ` Dan'l Miller 0 siblings, 1 reply; 285+ messages in thread From: Peter Chapin @ 2014-06-12 1:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 1:39 ` Peter Chapin @ 2014-06-12 2:46 ` Dan'l Miller 2014-06-12 11:24 ` Peter Chapin 0 siblings, 1 reply; 285+ messages in thread From: Dan'l Miller @ 2014-06-12 2:46 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 2:46 ` Dan'l Miller @ 2014-06-12 11:24 ` Peter Chapin 2014-06-12 11:36 ` Lucretia 2014-06-12 14:48 ` björn lundin 0 siblings, 2 replies; 285+ messages in thread From: Peter Chapin @ 2014-06-12 11:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 11:24 ` Peter Chapin @ 2014-06-12 11:36 ` Lucretia 2014-06-12 14:48 ` björn lundin 1 sibling, 0 replies; 285+ messages in thread From: Lucretia @ 2014-06-12 11:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 11:24 ` Peter Chapin 2014-06-12 11:36 ` Lucretia @ 2014-06-12 14:48 ` björn lundin 2014-06-12 22:12 ` Simon Clubley 1 sibling, 1 reply; 285+ messages in thread From: björn lundin @ 2014-06-12 14:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 14:48 ` björn lundin @ 2014-06-12 22:12 ` Simon Clubley 2014-06-13 8:36 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-12 22:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-12 22:12 ` Simon Clubley @ 2014-06-13 8:36 ` Dmitry A. Kazakov 2014-06-13 15:55 ` Shark8 ` (2 more replies) 0 siblings, 3 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-13 8:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 8:36 ` Dmitry A. Kazakov @ 2014-06-13 15:55 ` Shark8 2014-06-13 16:13 ` Dmitry A. Kazakov 2014-06-13 20:57 ` Robert A Duff 2014-06-14 21:05 ` Maciej Sobczak 2 siblings, 1 reply; 285+ messages in thread From: Shark8 @ 2014-06-13 15:55 UTC (permalink / raw) 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?) ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 15:55 ` Shark8 @ 2014-06-13 16:13 ` Dmitry A. Kazakov 0 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-13 16:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 8:36 ` Dmitry A. Kazakov 2014-06-13 15:55 ` Shark8 @ 2014-06-13 20:57 ` Robert A Duff 2014-06-14 7:27 ` Georg Bauhaus ` (2 more replies) 2014-06-14 21:05 ` Maciej Sobczak 2 siblings, 3 replies; 285+ messages in thread From: Robert A Duff @ 2014-06-13 20:57 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 20:57 ` Robert A Duff @ 2014-06-14 7:27 ` Georg Bauhaus 2014-06-14 21:02 ` Simon Clubley 2014-06-16 16:39 ` Randy Brukardt 2 siblings, 0 replies; 285+ messages in thread From: Georg Bauhaus @ 2014-06-14 7:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 20:57 ` Robert A Duff 2014-06-14 7:27 ` Georg Bauhaus @ 2014-06-14 21:02 ` Simon Clubley 2014-06-16 16:39 ` Randy Brukardt 2 siblings, 0 replies; 285+ messages in thread From: Simon Clubley @ 2014-06-14 21:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 20:57 ` Robert A Duff 2014-06-14 7:27 ` Georg Bauhaus 2014-06-14 21:02 ` Simon Clubley @ 2014-06-16 16:39 ` Randy Brukardt 2014-06-16 17:13 ` Dmitry A. Kazakov ` (2 more replies) 2 siblings, 3 replies; 285+ messages in thread From: Randy Brukardt @ 2014-06-16 16:39 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 16:39 ` Randy Brukardt @ 2014-06-16 17:13 ` Dmitry A. Kazakov 2014-06-16 17:24 ` Simon Clubley 2014-06-16 21:53 ` Robert A Duff 2 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-16 17:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 16:39 ` Randy Brukardt 2014-06-16 17:13 ` Dmitry A. Kazakov @ 2014-06-16 17:24 ` Simon Clubley 2014-06-16 19:13 ` Simon Wright 2014-06-16 21:53 ` Robert A Duff 2 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-16 17:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 17:24 ` Simon Clubley @ 2014-06-16 19:13 ` Simon Wright 2014-06-16 20:25 ` Simon Clubley 0 siblings, 1 reply; 285+ messages in thread From: Simon Wright @ 2014-06-16 19:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 19:13 ` Simon Wright @ 2014-06-16 20:25 ` Simon Clubley 2014-06-17 16:10 ` Simon Wright 0 siblings, 1 reply; 285+ messages in thread From: Simon Clubley @ 2014-06-16 20:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 20:25 ` Simon Clubley @ 2014-06-17 16:10 ` Simon Wright 0 siblings, 0 replies; 285+ messages in thread From: Simon Wright @ 2014-06-17 16:10 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 16:39 ` Randy Brukardt 2014-06-16 17:13 ` Dmitry A. Kazakov 2014-06-16 17:24 ` Simon Clubley @ 2014-06-16 21:53 ` Robert A Duff 2014-06-16 23:02 ` Jeffrey Carter 2 siblings, 1 reply; 285+ messages in thread From: Robert A Duff @ 2014-06-16 21:53 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 21:53 ` Robert A Duff @ 2014-06-16 23:02 ` Jeffrey Carter 2014-06-16 23:42 ` Robert A Duff 0 siblings, 1 reply; 285+ messages in thread From: Jeffrey Carter @ 2014-06-16 23:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 23:02 ` Jeffrey Carter @ 2014-06-16 23:42 ` Robert A Duff 2014-06-17 19:18 ` Randy Brukardt 0 siblings, 1 reply; 285+ messages in thread From: Robert A Duff @ 2014-06-16 23:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-16 23:42 ` Robert A Duff @ 2014-06-17 19:18 ` Randy Brukardt 0 siblings, 0 replies; 285+ messages in thread From: Randy Brukardt @ 2014-06-17 19:18 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-13 8:36 ` Dmitry A. Kazakov 2014-06-13 15:55 ` Shark8 2014-06-13 20:57 ` Robert A Duff @ 2014-06-14 21:05 ` Maciej Sobczak 2014-06-15 6:52 ` Dmitry A. Kazakov 2 siblings, 1 reply; 285+ messages in thread From: Maciej Sobczak @ 2014-06-14 21:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-14 21:05 ` Maciej Sobczak @ 2014-06-15 6:52 ` Dmitry A. Kazakov 2014-06-15 10:04 ` Georg Bauhaus 2014-06-17 8:18 ` Maciej Sobczak 0 siblings, 2 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-15 6:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 6:52 ` Dmitry A. Kazakov @ 2014-06-15 10:04 ` Georg Bauhaus 2014-06-15 12:25 ` Dmitry A. Kazakov 2014-06-17 8:18 ` Maciej Sobczak 1 sibling, 1 reply; 285+ messages in thread From: Georg Bauhaus @ 2014-06-15 10:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 10:04 ` Georg Bauhaus @ 2014-06-15 12:25 ` Dmitry A. Kazakov 0 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-15 12:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-15 6:52 ` Dmitry A. Kazakov 2014-06-15 10:04 ` Georg Bauhaus @ 2014-06-17 8:18 ` Maciej Sobczak 2014-06-17 9:13 ` Dmitry A. Kazakov 1 sibling, 1 reply; 285+ messages in thread From: Maciej Sobczak @ 2014-06-17 8:18 UTC (permalink / raw) > > 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 8:18 ` Maciej Sobczak @ 2014-06-17 9:13 ` Dmitry A. Kazakov 2014-06-18 7:55 ` Maciej Sobczak 0 siblings, 1 reply; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-17 9:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-17 9:13 ` Dmitry A. Kazakov @ 2014-06-18 7:55 ` Maciej Sobczak 2014-06-18 8:31 ` Dmitry A. Kazakov 0 siblings, 1 reply; 285+ messages in thread From: Maciej Sobczak @ 2014-06-18 7:55 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-18 7:55 ` Maciej Sobczak @ 2014-06-18 8:31 ` Dmitry A. Kazakov 0 siblings, 0 replies; 285+ messages in thread From: Dmitry A. Kazakov @ 2014-06-18 8:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
* Re: a new language, designed for safety ! 2014-06-11 19:39 ` Peter Chapin 2014-06-11 19:52 ` Luke A. Guest @ 2014-06-12 8:16 ` Georg Bauhaus 1 sibling, 0 replies; 285+ messages in thread From: Georg Bauhaus @ 2014-06-12 8:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 285+ messages in thread
end of thread, other threads:[~2014-07-02 22:06 UTC | newest] Thread overview: 285+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-03 1:37 a new language, designed for safety ! Nasser M. Abbasi 2014-06-04 0:21 ` Luke A. Guest 2014-06-04 1:19 ` Dan'l Miller 2014-06-04 4:05 ` Dan'l Miller 2014-06-04 6:59 ` Georg Bauhaus 2014-06-04 4:12 ` Dan'l Miller 2014-06-04 5:44 ` Jeffrey Carter 2014-06-04 15:25 ` Dan'l Miller 2014-06-04 19:43 ` Robert A Duff 2014-06-04 21:32 ` Simon Clubley 2014-06-05 9:13 ` Nasser M. Abbasi 2014-06-05 15:33 ` Adam Beneschan 2014-06-05 19:19 ` Jeffrey Carter 2014-06-05 15:55 ` Adam Beneschan 2014-06-05 19:15 ` sbelmont700 2014-06-05 22:40 ` Robert A Duff 2014-06-06 15:13 ` Dan'l Miller 2014-06-06 17:51 ` G.B. 2014-06-06 18:39 ` Niklas Holsti 2014-06-06 19:43 ` Robert A Duff 2014-06-06 20:42 ` Dmitry A. Kazakov 2014-06-08 9:40 ` Georg Bauhaus 2014-06-08 13:56 ` Robert A Duff 2014-06-08 16:13 ` Dan'l Miller 2014-06-08 17:22 ` J-P. Rosen 2014-06-08 19:36 ` Dmitry A. Kazakov 2014-06-09 5:30 ` Niklas Holsti 2014-06-09 7:06 ` Dmitry A. Kazakov 2014-06-09 16:07 ` Dan'l Miller 2014-06-10 7:44 ` Dmitry A. Kazakov 2014-06-10 16:31 ` Dan'l Miller 2014-06-10 16:52 ` Dmitry A. Kazakov 2014-06-06 18:52 ` Robert A Duff 2014-06-06 22:50 ` Simon Clubley 2014-06-23 0:40 ` Yannick Duchêne (Hibou57) 2014-06-23 0:43 ` Yannick Duchêne (Hibou57) 2014-06-23 0:51 ` Shark8 2014-06-23 1:47 ` Nasser M. Abbasi 2014-06-23 6:46 ` Shark8 2014-06-23 14:17 ` Peter Chapin 2014-06-23 15:39 ` Dan'l Miller 2014-06-23 17:04 ` Dmitry A. Kazakov 2014-06-05 8:26 ` Georg Bauhaus 2014-06-09 10:03 ` Pascal Obry 2014-06-10 9:36 ` Stephen Leake 2014-06-10 10:48 ` Luke A. Guest 2014-06-10 18:31 ` Pascal Obry 2014-06-23 1:01 ` Yannick Duchêne (Hibou57) 2014-06-10 12:28 ` Simon Clubley 2014-06-10 12:42 ` Lucretia 2014-06-10 12:50 ` J-P. Rosen 2014-06-10 13:00 ` Lucretia 2014-06-10 14:43 ` Brad Moore 2014-06-10 15:15 ` J-P. Rosen 2014-06-10 20:28 ` Simon Clubley 2014-06-10 20:39 ` Pascal Obry 2014-06-10 21:04 ` Simon Clubley 2014-06-11 7:17 ` Pascal Obry 2014-06-25 22:37 ` Yannick Duchêne (Hibou57) 2014-06-10 22:09 ` Luke A. Guest 2014-06-12 23:58 ` Shark8 2014-06-13 1:28 ` Luke A. Guest 2014-06-25 22:41 ` Yannick Duchêne (Hibou57) 2014-06-26 1:36 ` Shark8 2014-06-26 10:19 ` J-P. Rosen 2014-06-25 22:40 ` Yannick Duchêne (Hibou57) 2014-06-26 7:39 ` Luke A. Guest 2014-06-26 7:42 ` Yannick Duchêne (Hibou57) 2014-06-26 10:07 ` Luke A. Guest 2014-06-26 10:18 ` J-P. Rosen 2014-07-02 22:06 ` Randy Brukardt 2014-06-11 0:16 ` Jeffrey Carter 2014-06-11 7:29 ` Simon Clubley 2014-06-11 19:22 ` Jeffrey Carter 2014-06-12 11:48 ` Simon Clubley 2014-06-12 16:59 ` Jeffrey Carter 2014-06-10 15:33 ` Lucretia 2014-06-10 16:31 ` Dmitry A. Kazakov 2014-06-10 19:34 ` Tero Koskinen 2014-06-11 6:46 ` Natasha Kerensikova 2014-06-11 8:45 ` Dmitry A. Kazakov 2014-06-11 9:05 ` Simon Wright 2014-06-11 12:09 ` Simon Clubley 2014-06-11 12:34 ` Dmitry A. Kazakov 2014-06-11 12:42 ` björn lundin 2014-06-11 13:04 ` Lucretia 2014-06-11 12:11 ` björn lundin 2014-06-10 19:49 ` J-P. Rosen 2014-06-10 22:09 ` Luke A. Guest 2014-06-11 9:01 ` Simon Wright 2014-06-16 16:22 ` Randy Brukardt 2014-06-16 17:11 ` Ada platforms and pricing, was: " Simon Clubley 2014-06-17 19:34 ` Randy Brukardt 2014-06-17 20:16 ` Jeffrey Carter 2014-06-18 5:56 ` Georg Bauhaus 2014-06-18 6:34 ` Nasser M. Abbasi 2014-06-18 19:57 ` Simon Clubley 2014-06-19 3:46 ` Randy Brukardt 2014-06-22 19:50 ` Simon Clubley 2014-06-22 23:38 ` Randy Brukardt 2014-06-23 6:18 ` Niklas Holsti 2014-06-23 7:42 ` Dmitry A. Kazakov 2014-06-23 11:17 ` Simon Wright 2014-06-23 17:14 ` Dmitry A. Kazakov 2014-06-23 19:21 ` Dan'l Miller 2014-06-23 20:14 ` Dmitry A. Kazakov 2014-06-23 21:48 ` Simon Wright 2014-06-24 1:18 ` Nasser M. Abbasi 2014-06-24 2:15 ` Jeffrey Carter 2014-06-24 7:51 ` Dmitry A. Kazakov 2014-06-23 21:52 ` Simon Wright 2014-06-24 1:04 ` Dan'l Miller 2014-06-26 3:24 ` Yannick Duchêne (Hibou57) 2014-06-26 3:27 ` Yannick Duchêne (Hibou57) 2014-06-24 1:01 ` Shark8 2014-06-24 10:24 ` Simon Wright 2014-06-24 11:25 ` Dan'l Miller 2014-06-24 15:55 ` Shark8 2014-06-24 18:06 ` Dan'l Miller 2014-06-24 18:44 ` Dan'l Miller 2014-06-24 18:49 ` Shark8 2014-06-24 21:25 ` Dan'l Miller 2014-06-24 16:48 ` Simon Wright 2014-06-26 3:41 ` Yannick Duchêne (Hibou57) 2014-06-23 20:40 ` Simon Wright 2014-06-24 7:48 ` Dmitry A. Kazakov 2014-06-23 11:48 ` G.B. 2014-06-24 7:52 ` Maciej Sobczak 2014-06-24 8:33 ` Dmitry A. Kazakov 2014-07-01 10:28 ` Simon Wright 2014-07-01 12:41 ` Dmitry A. Kazakov 2014-06-26 2:50 ` Yannick Duchêne (Hibou57) 2014-06-26 10:04 ` G.B. 2014-06-26 18:20 ` Yannick Duchêne (Hibou57) 2014-06-25 17:24 ` Niklas Holsti 2014-06-26 2:43 ` Yannick Duchêne (Hibou57) 2014-06-23 7:31 ` Dmitry A. Kazakov 2014-06-23 20:08 ` Randy Brukardt 2014-06-23 20:20 ` Dmitry A. Kazakov 2014-06-24 11:56 ` Simon Clubley 2014-06-24 12:13 ` Simon Clubley 2014-06-17 20:27 ` Luke A. Guest 2014-06-18 7:09 ` Natasha Kerensikova 2014-06-18 10:32 ` J-P. Rosen 2014-06-18 11:50 ` Brian Drummond 2014-06-18 17:34 ` Natasha Kerensikova 2014-06-18 17:56 ` Peter Chapin 2014-06-19 7:22 ` Natasha Kerensikova 2014-06-19 12:02 ` Peter Chapin 2014-06-20 7:03 ` Natasha Kerensikova 2014-06-19 13:33 ` Lucretia 2014-06-20 7:07 ` Natasha Kerensikova 2014-06-20 11:44 ` Lucretia 2014-06-20 12:47 ` Dennis Lee Bieber 2014-06-18 18:24 ` Lucretia 2014-06-19 7:26 ` Natasha Kerensikova 2014-06-18 18:47 ` Dmitry A. Kazakov 2014-06-18 20:17 ` Simon Clubley 2014-06-18 22:51 ` Simon Clubley 2014-06-19 8:51 ` Dmitry A. Kazakov 2014-06-19 3:35 ` Randy Brukardt 2014-06-19 7:34 ` Natasha Kerensikova 2014-06-19 8:19 ` J-P. Rosen 2014-06-19 9:11 ` Dmitry A. Kazakov 2014-06-19 12:08 ` Peter Chapin 2014-06-19 13:48 ` Dmitry A. Kazakov 2014-06-19 20:59 ` Randy Brukardt 2014-06-26 2:04 ` Yannick Duchêne (Hibou57) 2014-06-26 22:24 ` Shark8 2014-06-26 22:44 ` Yannick Duchêne (Hibou57) 2014-06-26 22:51 ` Shark8 2014-06-27 12:43 ` Ada platforms and pricing, was: Re: a new language, anon 2014-06-19 21:13 ` Ada platforms and pricing, was: Re: a new language, designed for safety ! Robert A Duff 2014-06-19 23:47 ` Adam Beneschan 2014-06-19 21:03 ` Randy Brukardt 2014-06-20 7:26 ` Natasha Kerensikova 2014-06-20 19:50 ` Randy Brukardt 2014-06-21 8:35 ` Natasha Kerensikova 2014-06-22 23:26 ` Randy Brukardt 2014-06-26 2:16 ` Yannick Duchêne (Hibou57) 2014-06-20 9:54 ` anon 2014-06-20 12:25 ` Lucretia 2014-06-20 19:32 ` Ada platforms and pricing, was: Re: a new language, designed for anon 2014-06-18 17:01 ` Ada platforms and pricing, was: Re: a new language, designed for safety ! Jeffrey Carter 2014-06-19 7:53 ` Natasha Kerensikova 2014-06-19 21:10 ` Randy Brukardt 2014-06-19 22:27 ` Luke A. Guest 2014-06-16 21:31 ` Luke A. Guest 2014-06-16 23:02 ` Jeffrey Carter 2014-06-17 11:14 ` gvdschoot 2014-06-17 17:42 ` Jeffrey Carter 2014-06-17 12:56 ` Simon Clubley 2014-06-17 17:43 ` Jeffrey Carter 2014-06-17 19:46 ` Jacob Sparre Andersen 2014-06-26 1:20 ` Yannick Duchêne (Hibou57) 2014-06-17 19:41 ` Randy Brukardt 2014-06-17 20:08 ` Jeffrey Carter 2014-06-18 5:46 ` Georg Bauhaus 2014-06-18 8:02 ` Dmitry A. Kazakov 2014-06-18 9:34 ` G.B. 2014-06-18 12:30 ` Dmitry A. Kazakov 2014-06-18 14:43 ` G.B. 2014-06-18 16:39 ` Dmitry A. Kazakov 2014-06-20 8:27 ` Georg Bauhaus 2014-06-25 22:43 ` Yannick Duchêne (Hibou57) 2014-06-12 23:56 ` Shark8 2014-06-10 20:22 ` Simon Clubley 2014-06-10 21:14 ` Simon Clubley 2014-06-10 22:09 ` Luke A. Guest 2014-06-10 22:09 ` Luke A. Guest 2014-06-11 0:05 ` Jeffrey Carter 2014-06-11 7:32 ` Simon Clubley 2014-06-11 16:50 ` G.B. 2014-06-11 19:20 ` Jeffrey Carter 2014-06-12 7:01 ` Simon Clubley 2014-06-12 17:46 ` Jeffrey Carter 2014-06-12 21:40 ` Simon Clubley 2014-06-13 6:37 ` J-P. Rosen 2014-06-13 12:03 ` Simon Clubley 2014-06-13 15:34 ` Lucretia 2014-06-13 17:00 ` Simon Clubley 2014-06-13 22:21 ` Brian Drummond 2014-06-14 20:41 ` Simon Clubley 2014-06-15 6:26 ` Tero Koskinen 2014-06-16 0:11 ` Simon Clubley 2014-06-15 18:10 ` Luke A. Guest 2014-06-16 0:00 ` Simon Clubley 2014-06-25 6:42 ` Yannick Duchêne (Hibou57) 2014-06-25 7:29 ` Georg Bauhaus 2014-06-25 12:17 ` Simon Clubley 2014-06-12 23:53 ` Shark8 2014-06-13 4:28 ` Simon Clubley 2014-06-13 8:17 ` gvdschoot 2014-06-13 13:16 ` Simon Wright 2014-06-13 14:13 ` gvdschoot 2014-06-13 15:52 ` Shark8 2014-06-13 17:04 ` Simon Clubley 2014-06-13 20:10 ` Simon Wright 2014-06-15 6:33 ` Tero Koskinen 2014-06-15 7:47 ` gvdschoot 2014-06-15 8:13 ` gvdschoot 2014-06-15 8:18 ` Nasser M. Abbasi 2014-06-16 0:16 ` Simon Clubley 2014-06-16 0:35 ` Simon Clubley 2014-06-16 6:08 ` Georg Bauhaus 2014-06-16 6:19 ` Georg Bauhaus 2014-06-16 12:08 ` Peter Chapin 2014-06-25 22:28 ` Yannick Duchêne (Hibou57) 2014-06-16 12:30 ` Simon Clubley 2014-06-16 6:22 ` gvdschoot 2014-06-25 6:28 ` Yannick Duchêne (Hibou57) 2014-06-11 8:27 ` Maciej Sobczak 2014-06-11 19:39 ` Peter Chapin 2014-06-11 19:52 ` Luke A. Guest 2014-06-12 1:39 ` Peter Chapin 2014-06-12 2:46 ` Dan'l Miller 2014-06-12 11:24 ` Peter Chapin 2014-06-12 11:36 ` Lucretia 2014-06-12 14:48 ` björn lundin 2014-06-12 22:12 ` Simon Clubley 2014-06-13 8:36 ` Dmitry A. Kazakov 2014-06-13 15:55 ` Shark8 2014-06-13 16:13 ` Dmitry A. Kazakov 2014-06-13 20:57 ` Robert A Duff 2014-06-14 7:27 ` Georg Bauhaus 2014-06-14 21:02 ` Simon Clubley 2014-06-16 16:39 ` Randy Brukardt 2014-06-16 17:13 ` Dmitry A. Kazakov 2014-06-16 17:24 ` Simon Clubley 2014-06-16 19:13 ` Simon Wright 2014-06-16 20:25 ` Simon Clubley 2014-06-17 16:10 ` Simon Wright 2014-06-16 21:53 ` Robert A Duff 2014-06-16 23:02 ` Jeffrey Carter 2014-06-16 23:42 ` Robert A Duff 2014-06-17 19:18 ` Randy Brukardt 2014-06-14 21:05 ` Maciej Sobczak 2014-06-15 6:52 ` Dmitry A. Kazakov 2014-06-15 10:04 ` Georg Bauhaus 2014-06-15 12:25 ` Dmitry A. Kazakov 2014-06-17 8:18 ` Maciej Sobczak 2014-06-17 9:13 ` Dmitry A. Kazakov 2014-06-18 7:55 ` Maciej Sobczak 2014-06-18 8:31 ` Dmitry A. Kazakov 2014-06-12 8:16 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox