Build language with weak typing, then add scaffolding later to strengthen it?

Build language with weak typing, then add scaffolding later to strengthen it?

[Nasser M. Abbasi]

There seems to be strange thing going on with computer language design,
that I think folks here more than anywhere else would understand due
to Ada strong software engineering foundation.

I noticed languages start with weak or no typing at all. Then
later in the language life, lint like processing and type
hints are added to "strengthen" the language by making
it more strongly typed and catch more errors. Programmers
get excited each time a new scaffolding tool is added
since it now makes their language "better".

But why not then design the language with strong typing in
first place? Would not this be easier?

It is like constructing a building on weak foundation,
then add scaffolding on it later on to make it stronger.

Here is an example: Python now is adding what is called
"type hints" and everyone is excited about it since
it is supposed to make python more robust:

https://www.python.org/dev/peps/pep-0484/

"While these annotations are available at runtime
through the usual __annotations__ attribute, no type checking
happens at runtime . Instead, the proposal assumes the
existence of a separate off-line type checker which users
can run over their source code voluntarily. Essentially,
such a type checker acts as a very powerful linter. "

And we all know that C has lint also, to help catch
errors in code since C is weakly typed as well.

Fortran adds many compiler switches to help catch compile
time errors which otherwise would escape. I now use

gfortran -fcheck=all -Wall -Wconversion -Wextra -Wconversion-extra -pedantic

To make sure I checked everything, and I am still not sure it
did. (many times I download Fortran source code from the net
for fun and compile it using the above, and I see many
warnings generated, many due to mixed typing mess. It is scary).

In Ada, none of this is needed, as the language itself is designed
from the foundation to catch all these errors due to its
strong typing.

So, why do language designers design computer languages with weak
typing, and then spend so much effort later on to fixing the
weak typing? Is it because it is easier to design a language with
weak typing than strong one?

--Nasser

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[AdaMagica]

Just think about how thick the Ada RM is with all its rules to make the language safe and the RM correct. And think about the number of AI's each language generation has to correct the errors in the manual.

Compare this to other languages' RMs.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Dmitry A. Kazakov]

On Thu, 21 May 2015 12:29:36 -0700 (PDT), AdaMagica wrote:

> Just think about how thick the Ada RM is with all its rules to make the
> language safe and the RM correct. And think about the number of AI's each
> language generation has to correct the errors in the manual.

I disagree. The number of amendments and the size of the RM has little to
do with strong typing. I think the language could be much smaller with
types stronger.

Weak typing requires a lot more language rules. Type inference does even
more. Strong typing with nominal matching is much simpler to handle and
define. E.g. dynamically polymorphic (tagged) types, which are a bit
weaker, take more pages in the RM than all other plain types combined.

> Compare this to other languages' RMs.

I would address that to sloppiness. In many cases it is too difficult to
define what is going on with all these implicit-nowhere-defined types, so
people just don't bother to document it.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 21.05.15 21:11, Nasser M. Abbasi wrote:

> In Ada, none of this is needed,

This claim may be a little bold. Even thinking from "inside" Ada.

For example, the recently introduced aspects of types show how
"strong" Ada types really are, that is, how expressive the Ada
type system really has been.

Actually, the effort that has produced Ada may have spurred
an idea of how not to design a language. Obviously, for all
willing to see it that way, it was a big failure, C having
taken its place in embedded systems. While the greed, and the
opportunism associated with its design situation are on record,
still, obviously, the socioeconomic failure carries over to the
qualities of the design process. Right?

Who would want to do that again?


> So, why do language designers design computer languages with weak
> typing, and then spend so much effort later on to fixing the
> weak typing? Is it because it is easier to design a language with
> weak typing than strong one?

Are you sure there ware professional language designers around when
these languages were defined?

Maybe now, within Microsoft's X# set. Maybe around Scala. Maybe
atETH Zürich.

But with other "designs", it seems that a language is just inspired
by what its creators happen to have learned. (Which, sometimes,
is type inference in ML.) Designing something better, more inclusively,
requires voluntary co-operation of competitors in industry…
It requires deviating from just having grads do something™ in their
spare time and let The Market do the rest.
Is anything being done, language-wise, by industry? Or are their needs
taken care of (nominally) by the existing language vendors instead?

Certainly, an ad hoc language like JavaScript, created by young grads,
was pushed by popularity, the drivers being from the sales department;
that's on record. Once the language is out the door, having gained some
traction, it would take someone bold to replace it with something
much better. So, not sales staff. Once the language is out, no one
takes any risks, the business is established.

So, instead, PHP, C, Fortran etc. get all bells and whistles that you can
get for money (sic), by hiring compiler makers who need employment anyway.
Hence, for example, the Hack language and HHVM, were motivated and
financed by Facebook; this should keep PHP in place.

Thus our collective boldness (none) makes crappy languages stay.
The improved compilers help saving one's face.
Good.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Nasser M. Abbasi]

On 5/22/2015 2:42 AM, Georg Bauhaus wrote:
> On 21.05.15 21:11, Nasser M. Abbasi wrote:
>
>> In Ada, none of this is needed,
>
> This claim may be a little bold. Even thinking from "inside" Ada.
>

It is all relative ofcourse. What I meant is that when
I get clean compile from Ada (after some struggle), I feel
much more safe that I did not overlook some basic typing
conflict or some other silly mistake which should be
detected by the compiler  which can result in hard
to detect errors later on at run-time.

In this sense, Ada does not need all the scaffolding (lint,
compiler flags, type hints, etc.. to make it more robust, it
is build into  the language. That is what I mean.

Ofcourse, one can still make logic/algorithmic errors in any language.

> For example, the recently introduced aspects of types show how
> "strong" Ada types really are, that is, how expressive the Ada
> type system really has been.
>
> Actually, the effort that has produced Ada may have spurred
> an idea of how not to design a language. Obviously, for all
> willing to see it that way, it was a big failure, C having
> taken its place in embedded systems. While the greed, and the
> opportunism associated with its design situation are on record,
> still, obviously, the socioeconomic failure carries over to the
> qualities of the design process. Right?
>
> Who would want to do that again?
>
>
>> So, why do language designers design computer languages with weak
>> typing, and then spend so much effort later on to fixing the
>> weak typing? Is it because it is easier to design a language with
>> weak typing than strong one?
>
> Are you sure there ware professional language designers around when
> these languages were defined?
>
> Maybe now, within Microsoft's X# set. Maybe around Scala. Maybe
> atETH Zürich.
>
> But with other "designs", it seems that a language is just inspired
> by what its creators happen to have learned. (Which, sometimes,
> is type inference in ML.) Designing something better, more inclusively,
> requires voluntary co-operation of competitors in industry…
> It requires deviating from just having grads do something™ in their
> spare time and let The Market do the rest.
> Is anything being done, language-wise, by industry? Or are their needs
> taken care of (nominally) by the existing language vendors instead?
>
> Certainly, an ad hoc language like JavaScript, created by young grads,
> was pushed by popularity, the drivers being from the sales department;
> that's on record. Once the language is out the door, having gained some
> traction, it would take someone bold to replace it with something
> much better. So, not sales staff. Once the language is out, no one
> takes any risks, the business is established.
>
> So, instead, PHP, C, Fortran etc. get all bells and whistles that you can
> get for money (sic), by hiring compiler makers who need employment anyway.
> Hence, for example, the Hack language and HHVM, were motivated and
> financed by Facebook; this should keep PHP in place.
>
> Thus our collective boldness (none) makes crappy languages stay.
> The improved compilers help saving one's face.
> Good.
>

--Nasser

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[kalvin.news]

Even C could be made more robust, if simple type checking is performed at compile time. For example,

typedef int apples;

typedef int oranges;

apples a = 5;
oranges o = a;

should generate type check error as the types are definitely different types. Also, assigning enums to ints and ints to enums should be considered illegal.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[J-P. Rosen]

Le 22/05/2015 13:29, kalvin.news@gmail.com a écrit :
> Even C could be made more robust, if simple type checking is
> performed at compile time. For example,
> 
> typedef int apples;
> 
> typedef int oranges;
> 
> apples a = 5; oranges o = a;
> 
> should generate type check error as the types are definitely
> different types. Also, assigning enums to ints and ints to enums
> should be considered illegal.
> 
I don't agree. C is a low level language, and good at that. Its types
are those of the  machine: bytes and addresses, the rest is a (small
quantity of) syntactic sugar.

If you need strong typing, use a strongly typed language. But don't
blame C for not being strongly typed, it was simply not part of the
requirements.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[kalvin.news]

perjantai 22. toukokuuta 2015 15.57.07 UTC+3 J-P. Rosen kirjoitti:
> Le 22/05/2015 13:29, kalvin.-nospamhere-news@gmail.com a écrit :
> > Even C could be made more robust, if simple type checking is
> > performed at compile time. For example,
> > 
> > typedef int apples;
> > 
> > typedef int oranges;
> > 
> > apples a = 5; oranges o = a;
> > 
> > should generate type check error as the types are definitely
> > different types. Also, assigning enums to ints and ints to enums
> > should be considered illegal.
> > 
> I don't agree. C is a low level language, and good at that. Its types
> are those of the  machine: bytes and addresses, the rest is a (small
> quantity of) syntactic sugar.
> 
> If you need strong typing, use a strongly typed language. But don't
> blame C for not being strongly typed, it was simply not part of the
> requirements.
> 
> -- 
> 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

What I heard, C is used in programming some operating systems. And C/C++ has been even used for programming some serious large-scale applications - not very low level to me. I have also heard some rumours that quite often bugs in C/C++ software are related to its non-existent type validation ;) Adding some type checking wouldn't make it less suitable for low-level programming. After 20 years in embedded C/C++ programming, I cannot say that it is good even for low level programming because of the weak type checking. C/C++ are the cancer of software engineering.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[kalvin.news]

perjantai 22. toukokuuta 2015 17.01.14 UTC+3 kalvi...@gmail.com kirjoitti:
> perjantai 22. toukokuuta 2015 15.57.07 UTC+3 J-P. Rosen kirjoitti:
> > Le 22/05/2015 13:29, kalvin.-nospamhere-news@gmail.com a écrit :
> > > Even C could be made more robust, if simple type checking is
> > > performed at compile time. For example,
> > > 
> > > typedef int apples;
> > > 
> > > typedef int oranges;
> > > 
> > > apples a = 5; oranges o = a;
> > > 
> > > should generate type check error as the types are definitely
> > > different types. Also, assigning enums to ints and ints to enums
> > > should be considered illegal.
> > > 
> > I don't agree. C is a low level language, and good at that. Its types
> > are those of the  machine: bytes and addresses, the rest is a (small
> > quantity of) syntactic sugar.
> > 
> > If you need strong typing, use a strongly typed language. But don't
> > blame C for not being strongly typed, it was simply not part of the
> > requirements.
> > 
> > -- 
> > 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
> 
> What I heard, C is used in programming some operating systems. And C/C++ has been even used for programming some serious large-scale applications - not very low level to me. I have also heard some rumours that quite often bugs in C/C++ software are related to its non-existent type validation ;) Adding some type checking wouldn't make it less suitable for low-level programming. After 20 years in embedded C/C++ programming, I cannot say that it is good even for low level programming because of the weak type checking. C/C++ are the cancer of software engineering.

What I would like to see in C/C++, and what would make me a bit less grumpy, is a compiler "#pragma strict" - or something like that - which would enable improved type checking in the compilation entity. Better yet, an improved Lint with strict type checking rules because some of the C compilers are legacy and cannot be upgraded. In that way, it would be backwards compatible, it wouldn't break any existing C/C++ source code base, but it would allow (at least me) to check my own code for type validity before I commit the code into the version control system. At would be also a step forward in order to make an improvement in code quality and robustness.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Peter Chapin]

On Fri, 22 May 2015, kalvin.news@gmail.com wrote:

> What I would like to see in C/C++, and what would make me a bit less 
> grumpy, is a compiler "#pragma strict" - or something like that - which 
> would enable improved type checking in the compilation entity. Better 
> yet, an improved Lint with strict type checking rules because some of 
> the C compilers are legacy and cannot be upgraded.

Such tools exist. I believe even the free splint tool has "strict 
typedefs" where it can be configured to regard each typedef as a new type. 
I'm also about 98% sure the commercial PC-Lint tool has a similar feature.

The problem with using such a feature is that you pretty much have to 
write all the code yourself (not necessarily a bad thing in a high 
integrity context) since the use of types in third party header files is 
not so strict.

That said, it is generally possible to tell these tools to tone down their 
checking when they processs a third party header precisely to avoid the 
errors doing so would produce.

Peter

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[J-P. Rosen]

Le 22/05/2015 16:01, kalvin.news@gmail.com a écrit :
> I don't agree. C is a low level language, and good at that. Its types
>> are those of the  machine: bytes and addresses, the rest is a (small
>> quantity of) syntactic sugar.
>> 
>> If you need strong typing, use a strongly typed language. But don't
>> blame C for not being strongly typed, it was simply not part of the
>> requirements.
>> 
(Making my point clearer after various reactions).

Languages have history; they stemmed from a need for solving a certain
class of problems. Then people tend to use them for different purposes.
My point is that each language should be used for what it's good at.

C was created for writing an operating system, and it's initial
requirement were to be a "portable assembly language". At that level,
there is no place for typing: a machine word is what you make of it,
there is no difference between a float, an int, or whatever. I certainly
wouldn't object to writing a device driver in C.

Now, it's true that people use it to write higher level applications.
That doesn't make the language higher level. After all, when I started
programming, almost any serious application was written in assembly.

I have seen people writing databases in APL, real-time programs in Java,
high-reliability applications in C, etc. My plea is "use the right tool
for the job". I wouldn't advocate Ada for "throw-away" programs with a
life-time of one day. But when it comes to safety-critical and/or
long-lived and/or high reliability and/or etc...

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[kalvin.news]

perjantai 22. toukokuuta 2015 18.37.59 UTC+3 J-P. Rosen kirjoitti:
> Le 22/05/2015 16:01, kalvin-nospamhere-.news@gmail.com a écrit :
> > I don't agree. C is a low level language, and good at that. Its types
> >> are those of the  machine: bytes and addresses, the rest is a (small
> >> quantity of) syntactic sugar.
> >> 
> >> If you need strong typing, use a strongly typed language. But don't
> >> blame C for not being strongly typed, it was simply not part of the
> >> requirements.
> >> 
> (Making my point clearer after various reactions).
> 
> Languages have history; they stemmed from a need for solving a certain
> class of problems. Then people tend to use them for different purposes.
> My point is that each language should be used for what it's good at.
> 
> C was created for writing an operating system, and it's initial
> requirement were to be a "portable assembly language". At that level,
> there is no place for typing: a machine word is what you make of it,
> there is no difference between a float, an int, or whatever. I certainly
> wouldn't object to writing a device driver in C.
> 
> Now, it's true that people use it to write higher level applications.
> That doesn't make the language higher level. After all, when I started
> programming, almost any serious application was written in assembly.
> 
> I have seen people writing databases in APL, real-time programs in Java,
> high-reliability applications in C, etc. My plea is "use the right tool
> for the job". I wouldn't advocate Ada for "throw-away" programs with a
> life-time of one day. But when it comes to safety-critical and/or
> long-lived and/or high reliability and/or etc...
> 
> -- 
> 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

My point here is that although an int is an int, an int in one context may be totally different from another int, although both entities are of type int.

For example, a low-level harddisk device driver might contain declarations like this:

int cylinder = 1;
int head = 2;
int sector = 3;

So, it is quite easy to do something stupid like this:

head = sector;

The compiler is happy as we assign an int to another int, but clearily we are assigning apples to oranges, which is not something that we typically want to do. However, we have not coveyed any information about our intentions here, and all ints are treated equally although clearily the ints contain different kind of integer values.

Of course, one should declare distinct types for the different entities holding information about the cylinder, head and sector. This would also document the code better and convey more of the programmer's intent: 

typedef int Cylinder;
typedef int Head;
typedef int Sector;

Cylinder cylinder = 1;
Head head = 2;
Sector sector = 3;

In C/C++ it is still allowed to do this stupid assignment without any compiler warning or error whatsoever:

head = sector;

In my opinion, this should not be allowed or at least the compiler should generate a big loud warning, as we were stating specifically that the variable head is of type Head and the variable cylinder is of type Cylinder. The programmer has stated a specific intentent to declare distinct types for the Cylinder, Head and Sector and they should not be intermixed unless they are specifically typecasted to another type.

Ps. Creating specific type declarations like:

typedef int Sector;

would make porting a bit easier should the maximum allowed sector count be increased to more than 65535 and an int is only 16 bits:

typedef long int Sector;

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Clubley]

On 2015-05-22, kalvin.news@gmail.com <kalvin.news@gmail.com> wrote:
>
> My point here is that although an int is an int, an int in one context may be totally different from another int, although both entities are of type int.
>
> For example, a low-level harddisk device driver might contain declarations like this:
>
> int cylinder = 1;
> int head = 2;
> int sector = 3;
>

What I would hope is that the designer uses unsigned integers for those
variables and, in order to make the code portable across platforms, they
used uint32_t and friends to encode within the program what the actual
required size of those variables need to be.

Simon.

PS: This is _not_ a dig at you BTW but an observation on some C code
that I have looked at. I don't like seeing see code use plain integers
when an unsigned integer better models the problem at hand.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[kalvin.news]

perjantai 22. toukokuuta 2015 20.40.52 UTC+3 Simon Clubley kirjoitti:
> On 2015-05-22, kalvin-nospamhere-.news@gmail.com <kalvin-nospamhere.news@gmail.com> wrote:
> >
> > My point here is that although an int is an int, an int in one context may be totally different from another int, although both entities are of type int.
> >
> > For example, a low-level harddisk device driver might contain declarations like this:
> >
> > int cylinder = 1;
> > int head = 2;
> > int sector = 3;
> >
> 
> What I would hope is that the designer uses unsigned integers for those
> variables and, in order to make the code portable across platforms, they
> used uint32_t and friends to encode within the program what the actual
> required size of those variables need to be.
> 
> Simon.
> 
> PS: This is _not_ a dig at you BTW but an observation on some C code
> that I have looked at. I don't like seeing see code use plain integers
> when an unsigned integer better models the problem at hand.
> 
> -- 
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Yes, I understand. I just wanted to make a point here, that an int should not be considered type compatible with another int if they are declared using different typedefs. Neverthless, my argument is still valid if I had used unsigned int, uint16_t or uint32_t:

typedef uint16_t Cylinder;
typedef uint16_t Head;
typedef uint32_t Sector;

The variables of type Cyliner, Head and Sector should be treated by the compiler as incompatible and different types unless they are explicitly typecasted.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[J-P. Rosen]

Le 22/05/2015 19:51, kalvin.news@gmail.com a écrit :
> Yes, I understand. I just wanted to make a point here, that an int
should not be considered type compatible with another int if they are
declared using different typedefs. Neverthless, my argument is still
valid if I had used unsigned int, uint16_t or uint32_t:
> 
> typedef uint16_t Cylinder;
> typedef uint16_t Head;
> typedef uint32_t Sector;
> 
> The variables of type Cyliner, Head and Sector should be treated by
> the compiler as incompatible and different types unless they are
> explicitly typecasted.
Of course, being a long time supporter of strong typing, I agree with
that view. But if you think in terms of abstract types and problem
domain rather than bits and addresses, don't use C. I see no point in
trying to make a low-level language higher level: use a language
designed to support higher level views.

To take an analogy: nobody would be so fool as to use a language
designed for making animations on web pages in a real-time context ;-)

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[kalvin.news]

perjantai 22. toukokuuta 2015 22.41.15 UTC+3 J-P. Rosen kirjoitti:
> Le 22/05/2015 19:51, kalvin-nospamhere-.news@gmail.com a écrit :
> > Yes, I understand. I just wanted to make a point here, that an int
> should not be considered type compatible with another int if they are
> declared using different typedefs. Neverthless, my argument is still
> valid if I had used unsigned int, uint16_t or uint32_t:
> > 
> > typedef uint16_t Cylinder;
> > typedef uint16_t Head;
> > typedef uint32_t Sector;
> > 
> > The variables of type Cyliner, Head and Sector should be treated by
> > the compiler as incompatible and different types unless they are
> > explicitly typecasted.
> Of course, being a long time supporter of strong typing, I agree with
> that view. But if you think in terms of abstract types and problem
> domain rather than bits and addresses, don't use C. I see no point in
> trying to make a low-level language higher level: use a language
> designed to support higher level views.
> 
> To take an analogy: nobody would be so fool as to use a language
> designed for making animations on web pages in a real-time context ;-)
> 
> -- 
> 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

Reality bites. It is very easy to get a decent and free/inexpensive compiler for almost any microcontroller on the market. And it is quite easy the find developers how are familiar with C/C++. And it is very hard to convince managers to invest to new tools that they do not know or understand, or their knowledge is based on outdated information (like "Yeah, I know Ada. One of my friends worked with Ada in 80's and it was *very* slow, the compiler produced terrible code and they needed Vax-cluster to run the compiler. Ada is so big."). So, we are dealing with a cultural, economical and practical challenges as well as historical burden and bad reputation.

I do not claim that even Ada would be the ultimate solution. Someone made a good point above that, for example Oberon manual is only like 17 pages and Ada RM is over 1000 pages. There might be something wrong here, and may explain partly why Ada has not gain popularity.

In my opinion, one of Ada's problem is that it is not allowed to call a compiler an Ada compiler if it implements only a subset of the language and the compiler has not beed certified. Please correct me if I am wrong here. I would consider a subset of Ada quite attractive if it provided same functionality as a C99, providing Ada's strong type checking and better grammar etc. - and if the compiler would be available even for the smaller microcontrollers for free (in the similar manner as C is available).

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Jeffrey R. Carter]

On 05/22/2015 01:04 PM, kalvin.news@gmail.com wrote:
> 
> In my opinion, one of Ada's problem is that it is not allowed to call a
> compiler an Ada compiler if it implements only a subset of the language and
> the compiler has not beed certified. Please correct me if I am wrong here. I
> would consider a subset of Ada quite attractive if it provided same
> functionality as a C99, providing Ada's strong type checking and better
> grammar etc. - and if the compiler would be available even for the smaller
> microcontrollers for free (in the similar manner as C is available).

Weren't you the one railing against people using out-of-date information a
couple of paragraphs earlier in your post? When Ada was a trademark of the DoD,
you could only use the term for a compiler that implemented the full language
and had been certified. At the time of Ada 95 the DoD gave up the trademark, so
there is no authority preventing you from misusing the name. GNAT, for example,
by default is not an Ada compiler.

-- 
Jeff Carter
"I'll get broads up here like you wouldn't believe.
Swingers. Freaks. Nymphomaniacs. Dental hygienists."
Play It Again, Sam
125

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[kalvin.news]

perjantai 22. toukokuuta 2015 23.32.45 UTC+3 Jeffrey R. Carter kirjoitti:
> On 05/22/2015 01:04 PM, kalvin.-nospamhere- news@gmail.com wrote:
> > 
> > In my opinion, one of Ada's problem is that it is not allowed to call a
> > compiler an Ada compiler if it implements only a subset of the language and
> > the compiler has not beed certified. Please correct me if I am wrong here. I
> > would consider a subset of Ada quite attractive if it provided same
> > functionality as a C99, providing Ada's strong type checking and better
> > grammar etc. - and if the compiler would be available even for the smaller
> > microcontrollers for free (in the similar manner as C is available).
> 
> Weren't you the one railing against people using out-of-date information a
> couple of paragraphs earlier in your post? When Ada was a trademark of the DoD,
> you could only use the term for a compiler that implemented the full language
> and had been certified. At the time of Ada 95 the DoD gave up the trademark, so
> there is no authority preventing you from misusing the name. GNAT, for example,
> by default is not an Ada compiler.
> 
> -- 
> Jeff Carter
> "I'll get broads up here like you wouldn't believe.
> Swingers. Freaks. Nymphomaniacs. Dental hygienists."
> Play It Again, Sam
> 125

Guilty as charged. But at least I do know that Ada has successfully ported as cross-compile for Avr microcontrollers and there is this thing called Ravenscar-profile.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Peter Chapin]

On Fri, 22 May 2015, Jeffrey R. Carter wrote:

> GNAT, for example, by default is not an Ada compiler.

Is this still true? The latest GNAT has overflow checking on by default... 
or are there other issues?

Peter

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Jeffrey R. Carter]

On 05/23/2015 04:14 AM, Peter Chapin wrote:
> On Fri, 22 May 2015, Jeffrey R. Carter wrote:
> 
>> GNAT, for example, by default is not an Ada compiler.
> 
> Is this still true? The latest GNAT has overflow checking on by default... or
> are there other issues?

GNAT has generally required -gnata to activate assertion checks, -gnatn to
activate cross-pkg inlining, -gnato to activate overflow checks, -fstack-check
to give Storage_Error rather than a segfault, and -gnatE to use the ARM dynamic
elaboration checks. Even if overflow checking is now on by default, I suspect
GNAT is still not an Ada compiler by default.

-- 
Jeff Carter
"C++ is like giving an AK-47 to a monk, shooting him
full of crack and letting him loose in a mall and
expecting him to balance your checking account
'when he has the time.'"
Drew Olbrich
52

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Wright]

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

> On 05/23/2015 04:14 AM, Peter Chapin wrote:
>> On Fri, 22 May 2015, Jeffrey R. Carter wrote:
>> 
>>> GNAT, for example, by default is not an Ada compiler.
>> 
>> Is this still true? The latest GNAT has overflow checking on by
>> default... or are there other issues?
>
> GNAT has generally required -gnata to activate assertion checks,
> -gnatn to activate cross-pkg inlining, -gnato to activate overflow
> checks, -fstack-check to give Storage_Error rather than a segfault,
> and -gnatE to use the ARM dynamic elaboration checks. Even if overflow
> checking is now on by default, I suspect GNAT is still not an Ada
> compiler by default.

-gnato, -fstack-check: point taken.

-gnata: pretty sure that pragma Assertion_Policy is implemented? but
 just using -gnata is a lot easier.

-gnatn: does the language require this?

-gnatE: static elaboration checks are so clearly the Right Thing I'm
 surprised the ARM hasn't legalised them!

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Pascal Obry]

Le samedi 23 mai 2015 à 18:48 +0100, Simon Wright a écrit : 
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> > GNAT has generally required -gnata to activate assertion checks,
> > -gnatn to activate cross-pkg inlining, -gnato to activate overflow
> > checks, -fstack-check to give Storage_Error rather than a segfault,
> > and -gnatE to use the ARM dynamic elaboration checks. Even if overflow
> > checking is now on by default, I suspect GNAT is still not an Ada
> > compiler by default.
> 
> -gnato, -fstack-check: point taken.

-gnato is on by default in recent version of GNAT.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> -gnato is on by default in recent version of GNAT.

Including FSF GCC 5.1.0. Thanks for the pointer.

BTW, gnatmake -h still says
 -gnato    Enable overflow checking mode to CHECKED (off by default)

There doesn't seem to be a way to turn overflow checking off, other than
-gnatp.

Should float overflow be added to the list of things to "make GNAT into
a real Ada compiler"?
 -gnateF   Check overflow on predefined Float types

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 25.05.15 12:22, Simon Wright wrote:
> There doesn't seem to be a way to turn overflow checking off, other than
> -gnatp.

IIUC, -gnato has become -gnato[M[N]], where digits M and N
refer to values of pragma Overflow_Mode, as per GNAT UG D.3
on "Specifying the Desired Mode" of overflow checking.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 22, 2015 at 10:04:17 PM UTC+2, kalvi...@gmail.com wrote:
> perjantai 22. toukokuuta 2015 22.41.15 UTC+3 J-P. Rosen kirjoitti:
> > Le 22/05/2015 19:51, kalvin-nospamhere-.news@gmail.com a écrit :
> > > Yes, I understand. I just wanted to make a point here, that an int
> > should not be considered type compatible with another int if they are
> > declared using different typedefs. Neverthless, my argument is still
> > valid if I had used unsigned int, uint16_t or uint32_t:
> > > 
> > > typedef uint16_t Cylinder;
> > > typedef uint16_t Head;
> > > typedef uint32_t Sector;
> > > 
> > > The variables of type Cyliner, Head and Sector should be treated by
> > > the compiler as incompatible and different types unless they are
> > > explicitly typecasted.
> > Of course, being a long time supporter of strong typing, I agree with
> > that view. But if you think in terms of abstract types and problem
> > domain rather than bits and addresses, don't use C. I see no point in
> > trying to make a low-level language higher level: use a language
> > designed to support higher level views.
> > 
> > To take an analogy: nobody would be so fool as to use a language
> > designed for making animations on web pages in a real-time context ;-)
> > 
> > -- 
> > 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
> 
> Reality bites. It is very easy to get a decent and free/inexpensive compiler for almost any microcontroller on the market. And it is quite easy the find developers how are familiar with C/C++. And it is very hard to convince managers to invest to new tools that they do not know or understand, or their knowledge is based on outdated information (like "Yeah, I know Ada. One of my friends worked with Ada in 80's and it was *very* slow, the compiler produced terrible code and they needed Vax-cluster to run the compiler. Ada is so big."). So, we are dealing with a cultural, economical and practical challenges as well as historical burden and bad reputation.

The historical burden and the bad reputation have not kept me away.
And just read the blurp on the adacore website about all the military-, aircraft-, and financial applications. It certainly convinces my customers.
so it must be cultural, or tribal if you wish, this whole issue.

> 
> I do not claim that even Ada would be the ultimate solution. Someone made a good point above that, for example Oberon manual is only like 17 pages and Ada RM is over 1000 pages. There might be something wrong here, and may explain partly why Ada has not gain popularity.

I was told in good faith the other day by some small business owner that hacks code at times for his products, after I explained what I was doing at the moment and what tools I use, that I should invest in Java. I would be up and running in 14 days he said. 

So now, what do we deduce:
1. java has glamour (this has been discussed here before)
2. the basics of java are easily grasped by a weekend hacker
3. he obviously has friends that keep him nice and cosy within the circle of the believers.

And I think the last point is the deciding factor. At least research in the process of religious conversion says so. You join a crowd because you like some of the people, and after a while you start to think that there is something in what they teach there.

> 
> In my opinion, one of Ada's problem is that it is not allowed to call a compiler an Ada compiler if it implements only a subset of the language and the compiler has not beed certified. Please correct me if I am wrong here. I would consider a subset of Ada quite attractive if it provided same functionality as a C99, providing Ada's strong type checking and better grammar etc. - and if the compiler would be available even for the smaller microcontrollers for free (in the similar manner as C is available).

Well uh . . 
I have not yet had a gpl ada compiler out of Adacore that was certified or complete. 
I was just part of Adacores quality control system. More users catch more bugs.
And rest assured most compiler vendors know this trick.
And otherwise: a person is free to use a subset of the animal if that is what you like to do.

Just look around. some runtimes for microcontrollers are available. And they are not difficult to make yourself. If gcc has a back end, I am sure the gnat front end will work.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

<jan.de.kruyf@gmail.com> wrote in message 
news:7ac8be18-bf22-4e7b-afcc-4da5c92049f3@googlegroups.com...
...
> And I think the last point is the deciding factor. At least research in 
> the process
> of religious conversion says so. You join a crowd because you like some of 
> the
> people, and after a while you start to think that there is something in 
> what they
> teach there.

Of course, I doubt this group is immune to that. We're worshiping in the 
church of Ada here. ;-)

                       Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 29, 2015 at 12:33:38 AM UTC+2, Randy Brukardt wrote:

> ...
> > And I think the last point is the deciding factor. At least research in 
> > the process
> > of religious conversion says so. You join a crowd because you like some of 
> > the
> > people, and after a while you start to think that there is something in 
> > what they
> > teach there.
> 
> Of course, I doubt this group is immune to that. We're worshiping in the 
> church of Ada here. ;-)
> 
>                        Randy.

Yes and I am the irreligious christian. 
"The Ada church is not a church, it is stone-age tribalism" ha ha.

Here is another Dijkstra for you also:

"As you all remember, the first and foremost objective was the development of the Elixir that would give the one that drank it Eternal Youth. But since there is not much point in eternal poverty, the world of science quickly embarked on its second project, viz. the Philosopher's Stone that would enable you to make as much Gold as you needed.

Needless to say, the planning of these two grandiose research projects went far beyond the predictive powers of the seers of that day and, for sound reasons of management, the accurate prediction of the future became the third hot scientific issue." (EDW898)

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 22.05.15 22:04, kalvin.news@gmail.com wrote:
> perjantai 22. toukokuuta 2015 22.41.15 UTC+3 J-P. Rosen kirjoitti:
>>
>> To take an analogy: nobody would be so fool as to use a language
>> designed for making animations on web pages in a real-time context ;-)
>>
>> --
>> 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
>
> Reality bites.

Sort of.

> And it is quite easy the find developers how are familiar with C/C++.

HR staff think they find people who think they are familiar with C
or even C++. That's good enough, though, if employment is evidence.

People who write C scarcely know what they really are writing. But.
It is perceived risk, though, both on the part of programmers and
on the part of management that counts, also perceived quality of
software in general. So, the risk of using C is reduced if every
programmer and every manager takes the same risks.

(If cheaper Ada could help, than I think that remembering DOT.COM
business will prevent a situation that makes Ada have C-like pricing
for microcontrollers.)

C is tricky, and its ISO standard is impressively long for a reason,
even though it omits many things to be documented per implementation.
(Some 150 pages for the core language, excl. the library, for a total
of around 500 pages.)

C++---a language that for reasons of historic incident is believed
to be some sort of C, and mentioned curiously in contexts
such as in "C/C++"---is a different beast entirely.
How many microcontrollers can one program in C++ without using
some C++ -> C translator?

> And it is very hard to convince managers to invest to new tools that they do not know or understand, or their knowledge is based on outdated information (like "Yeah, I know Ada. One of my friends worked with Ada in 80's and it was *very* slow, the compiler produced terrible code and they needed Vax-cluster to run the compiler. Ada is so big."). So, we are dealing with a cultural, economical and practical challenges as well as historical burden and bad reputation.
>
> I do not claim that even Ada would be the ultimate solution. Someone made a good point above that, for example Oberon manual is only like 17 pages

Actually …

> and Ada RM is over 1000 pages.

What corresponds to the Oberon-1 "manual" (Wirth's 1987 report,
I take it?) in Ada's ISO reference would be the core language.
About 1/3 of the LRM, some 350 pages.

Now why is the Ada LRM still 10x that of Component Pascal (current
Oberon)? In part because of ISO requirements, needed for solid works
of industry, when not "soldering". Precision is needed. In part,
because Ada has task types generic units and elaboration and so
one, as has already been mentioned; things that were needed, and
will be needed even more in the future, provided that microcontrollers,
too, will get more ALUs working in parallel. (ActiveOberon formed
Object + Semaphore constructs; another dozen pages, and again
offloading much on programmers, see below.)

E.g., quoting from the "Component Pascal Language report" (about
30 pages), on CASE statements:

"If the value of the expression does not occur as a label of any case,
  the statement sequence following the symbol ELSE is selected,
  if there is one, otherwise the program is aborted."

Abort? That would not have been acceptable to an Ada compiler from
day one.
But, surely, all programmers will do the right thing, won't they?
And good testing should find the hole in the Oberon program
before it is deployed, right?

To me, this report is a example of how a language definition shifts
responsibility (and definitions) to programmers doing all the work of,
say, keeping case statements right…
This might work well for the self-employed or for small groups
of programmers, and for programs that are sufficiently small; but how
should this help refactoring, say? Changes? What I want to point out is
this: it is not that surprising, then, if the Oberon "manual" can be
very short.


> There might be something wrong here, and may explain partly why Ada has not gain popularity.

Yes. History and pricing.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Saturday, May 23, 2015 at 2:40:25 PM UTC+2, Georg Bauhaus wrote:


> 
> People who write C scarcely know what they really are writing. 

That sir is a rather shallow statement to make. I would rather say they are experts in that they can produce so much good code with such an oldfashioned language.

> (If cheaper Ada could help, than I think that remembering DOT.COM
> business will prevent a situation that makes Ada have C-like pricing
> for microcontrollers.)
>
Wel, just of my head: there is Ada for avr and for ARM Cortex. Both free of charge, waiting for you to make a good runtime for the processor you want to use.


> 
> What corresponds to the Oberon-1 "manual" (Wirth's 1987 report,
> I take it?) in Ada's ISO reference would be the core language.
> About 1/3 of the LRM, some 350 pages.

George your Oberon commentary is way off the mark. And your argumentation is weak, but I dont need to elaborate on that, since this is not a language shoot out. I merely used it as an example to prove a point.

And statistics prove that point. I have written 1000th's of lines in Oberon and 1000th's of lines in Ada. Both highly technical software.
And I got exactly the same kind of errors on compiling and running: errors caused by my sloppy habits. And both the Oberon compiler that fits on a floppy (a floppy, not a stiffy) and Gcc which stands at over 1Gig of source in the latest implementation, caught them equally well and also the runtime errors that I caused were exactly the same. And otherwise: the precision was exquisite. Oberon has a long and proud history of making things smaller and more precise. While experience teaches that Ada tries to make things more precise, but causes bloat in the process.


So please explain to me why on earth I or DoD or ISO or anybody else needs all the bloat to confuse us. 
1. Does a program become easier to prove formally when the language has more baroque features?
2. Does it become easier to write when the language has more baroque features?
3. Does the program production process become faster when the language used has more baroque features?
4. Does the program become easier to maintain when the language has more baroque features?
5. Do we attract more programmers to a language that is clearly over-specified and difficult to learn? And the group on this list is getting frightfully small and is getting on in years!
6. Do we convince more managers to use a language of which the essence is difficult to grasp at first sight?

You may answer, I rest my case.

Cheers,

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 25.05.15 09:14, jan.de.kruyf@gmail.com wrote:
> And statistics prove that point. I have written

The mixture of "statistics" and "I have" is a little irritating,
but OTOH may be expected whenever the word "we" is understood as
a generalization of "I".

Since this is about proving a point about a full LRM as opposed
to a short language report and productivity:

The scope of Oberon is indicated spcefically at projectoberon.com:
"Its simplicity and clarity enables a single person to know and
  implement the entire system"

Wirth is said to have immediately recommended Ada for anything
of larger scope. Ichbiah has addressed the "single person know-everything"
in his 1984 interview.

To answer your list of suggestive remarks, put as questions, briefly:
Yes, one needs precision whenever one gets out of ones garage
(alternatively, one's corner). Proves are much less vague if
the assumptions are (and can be!) actually stated, or referred to.

Speaking of assumptions, Hoare's latest (2004) edition of CSP has
some 230 pages. Is it "baroque", too? Do programmers not need to know
anything  from it, just the Active Oberon report instead?

Kindly indicate the mark which my "commentary" on the Component Pascal
report was off. That is, would the report still be short if its authors
had liked to handle case distinctions in the way that Ada does, or
Haskell-OCaml-F#, or static C analyzers, etc.  Doesn't a more expressive
fundamental type system result in higher productivity and better
code, easier to keep correct during maintenance, even though
it takes a little longer to learn, although not much,
according to McCormick's repeated findings?

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Shark8]

On Monday, May 25, 2015 at 1:14:56 AM UTC-6, jan.de... wrote:
> 
> 
> 1. Does a program become easier to prove formally when the language has more baroque features?

Quite possibly.
One simple instance of this is case-coverage -- Ada is one of the [relatively] few languages that requires all possibilities to be specified, this is due to the prevalence of C and its influence on language design (in particular its choice to make enumerations an alias for int-values) -- wich is a feature Ada has had since its inception.

> 2. Does it become easier to write when the language has more baroque features?

Quite possibly.
The TASK construct provides a fairly natural way to implement a protocol, in addition to providing a logically parallel thread. There's also Ada's GENERIC, which is more complex than many other languages, which can have values in addition to types (or packages) as parameters.

> 3. Does the program production process become faster when the language used has more baroque features? 

Quite possibly.
Consider Ada's package system: it is essentially a module-system, but in conjunction with generics provides a much saner parametrization/template mechanism than text-substitution mechanisms.

> 4. Does the program become easier to maintain when the language has more baroque features? 

Given the above: quite possibly.
(You have to take advantage of the facilities to gain the benefit, obviously.)

> 5. Do we attract more programmers to a language that is clearly over-specified and difficult to learn?

I'm not sure it's difficult to learn.
It's different than the C-family syntax that many younger programmers are familiar with, but that says nothing about the ease of learning. Further, given the results of McCormick's model-train course I would venture to say that it isn't too difficult -- now, granted there is a dearth of easy-to-find tutorials and fun/open projects (esp for Ada 2012)... but that is a tangential issue.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Monday, May 25, 2015 at 8:44:37 PM UTC+2, Shark8 wrote:
> On Monday, May 25, 2015 at 1:14:56 AM UTC-6, jan.de... wrote:
> > 
> > 
> > 1. Does a program become easier to prove formally when the language has more baroque features?
> 
> Quite possibly.
> One simple instance of this is case-coverage -- Ada is one of the [relatively] few languages that requires all possibilities to be specified, this is due to the prevalence of C and its influence on language design (in particular its choice to make enumerations an alias for int-values) -- wich is a feature Ada has had since its inception.

It is also in the 17 pages, notwithstanding Georg's doubts. If it is not it is an oversight in the editing.

> 
> > 2. Does it become easier to write when the language has more baroque features?
> 
> Quite possibly.
> The TASK construct provides a fairly natural way to implement a protocol, in addition to providing a logically parallel thread. There's also Ada's GENERIC, which is more complex than many other languages, which can have values in addition to types (or packages) as parameters.

My example is lame in this respect since obviously Tasks are needed, which were not in original Oberon, although they were easily constructed, but you were in charge and had to watch your running times. That was still single processor world.

You might find the Generic / Template idea indispensable perhaps. I have used it on occasion and to me it is easy to use, but at the same time I am happy without it if it makes the language overly complex.

> 
> > 3. Does the program production process become faster when the language used has more baroque features? 
> 
> Quite possibly.
> Consider Ada's package system: it is essentially a module-system, but in conjunction with generics provides a much saner parametrization/template mechanism than text-substitution mechanisms.

The package system comes from the days of Modula and is firmly embedded in the 17 pages.

> 
> > 4. Does the program become easier to maintain when the language has more baroque features? 
> 
> Given the above: quite possibly.
> (You have to take advantage of the facilities to gain the benefit, obviously.)

Shark, the features you bring up are not at all the issue. It is much deeper than that and I would love a good discussion about it, because to be honest I am totally puzzled by the 1500 pages.there is something deeply wrong with the thinking behind it. And I am the least of all to say that. Much greater brains have before me.
I love the language, I like working in it, except when the compiler is throwing its toys. And dont misunderstand me, it is always for good reasons (according to the RM, and my logic brain tells me it is right) but the dichotomy stays: How is it possible to _not_ have all these issues and work fast with the _same_ precision and security and provability as what we are used to in Ada. It boggles the mind.

> 
> > 5. Do we attract more programmers to a language that is clearly over-specified and difficult to learn?
> 
> I'm not sure it's difficult to learn.
> It's different than the C-family syntax that many younger programmers are familiar with, but that says nothing about the ease of learning. Further, given the results of McCormick's model-train course I would venture to say that it isn't too difficult -- now, granted there is a dearth of easy-to-find tutorials and fun/open projects (esp for Ada 2012)... but that is a tangential issue.

True and I am aware of the McCormick paper, And broadly speaking I would agree with it. And yes the C crowd gets pissed off because the lack of features in Oberon. But then you have not worked in overdrive :)

I think that the problem lies partly a difference in concepts between the 2 languages, although they look surprisingly similar. When you know the one you think you can program the other, but that then proves to be a falleximble. 
Oberon is very much a reduced instruction set language. Anything complex is either a library package or a code pattern. So formal proof, for those who need that, is relatively easy. And for me production-wise it was a big bonus. When you are coding, your immediate working knowledge consists of exactly those 17 pages. And you know them off by heart in no time, from doing them again and again.
And when you do your program design you dont get sidetracked by language complexities.

So obviously it was ever only a teaching language and it needs a lot of deep thinking and hard work to get it up to todays needs. The few tries were rather feeble (Georg's component pascal was one of them) since there were no deep pockets behind it. So I can sit and wish for that to happen but that is not very productive. I would rather make a positive contribution to some language like Ada.

And in the mean time I will just put a small single pass compiler together for the ARM work I do.I did it before for AVR. It is very enjoyable.

And by the way let me say it again: this is _not_ a language shoot out. I have not got time for such crap. But I would certainly like some light over the issues I raised (And beyond "we need it" and "we always done it this way", that for me merely points to a vested interest).

Cheers,

j.


 

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Shark8]

On Monday, May 25, 2015 at 1:54:28 PM UTC-6, jan.de... wrote:
> On Monday, May 25, 2015 at 8:44:37 PM UTC+2, Shark8 wrote:
> > On Monday, May 25, 2015 at 1:14:56 AM UTC-6, jan.de... wrote:
> > > 
> 
> And by the way let me say it again: this is _not_ a language shoot out. I have not got time for such crap. But I would certainly like some light over the issues I raised (And beyond "we need it" and "we always done it this way", that for me merely points to a vested interest).

Oh, no, I didn't mean to come off like it _was_ a language shoot-out. Just pointing out that the 'baroqueness' (complexity) certainly can have a positive answer to your questions.

I am in agreement as to wanting understanding on the size of the RM though. (I suspect that it derives from equal parts structured format and "we always done it this way".)

> Shark, the features you bring up are not at all the issue. It is much deeper than that and I would love a good discussion about it, because to be honest I am totally puzzled by the 1500 pages.there is something deeply wrong with the thinking behind it. And I am the least of all to say that. Much greater brains have before me.

No, they aren't -- but they are answers to the question of complexity, which is tangential to the RM's size (it must define the features, and should specify interactions between features like, say, a function returning a task with an extended return, or an expression function returning an access to a task).

> I love the language, I like working in it, except when the compiler is throwing its toys. And dont misunderstand me, it is always for good reasons (according to the RM, and my logic brain tells me it is right) but the dichotomy stays: How is it possible to _not_ have all these issues and work fast with the _same_ precision and security and provability as what we are used to in Ada. It boggles the mind.

Yes; I think the RM could possibly be shorter... but I think we would lose much of its topical-structure* if we did that. -- It might have been acceptable to restructure in Ada 95, but the problem of doing it now is it would be backwards incomparable /w section numbers.

* -- The structure makes the TOC and Index very usable. The Ada LRM's index is one of the better ones, IMO.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 25.05.15 21:54, jan.de.kruyf@gmail.com wrote:
>> One simple instance of this is case-coverage -- Ada is one of the [relatively] few languages that requires all possibilities to be specified, this is due to the prevalence of C and its influence on language design (in particular its choice to make enumerations an alias for int-values) -- wich is a feature Ada has had since its inception.
> It is also in the 17 pages, notwithstanding Georg's doubts. If it is not it is an oversight in the editing.
>

The CASE construct of the Oberons should be what the reports say it is.
Any the report does establish a foggy idea. Reiser and Wirth repeat the
same in their accompanying text book from 1992(en)/1994(de).

In 9.5, "The Programming Language Oberon" states for CASE:

"If the value of the expression does not occur as a label of any case,
  the statement sequence following the symbol ELSE is selected,
  if there is one. Otherwise it is considered as an error."

Difficulty arises from the report's language here: the pronoun "it"
just does not clearly point to anything serving as a noun. The word
"error" has no definition. What is the programmer to expect?
(C-style approach, of course: be pragmatic, try it with your
implementation, do what a proper engineer does, etc. etc..)

But the style of the report blends well with the idea of one person
writing and entire system, including OS, compilers, GUI, and tools
alone, since case coverage seems a bit more demanding than Wirth's
pragmatic shortcut would allow.

Oberon-07 does not even address the issue, since ELSE is gone.
Easy. So, I guess, CASE acts like an IF-ELSIF-... without an ELSE.
The report does not say. But it adds some other uses of CASE for type
extensions, quite clearly quoting from some unknown contexts, and not
introducing things like Si. Not surprising, then, that the report can
be shorter than usual.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 25.05.15 21:54, jan.de.kruyf@gmail.com wrote:
> Oberon is very much a reduced instruction set language. Anything complex is either a library package or a code pattern. So formal proof, for those who need that, is relatively easy.

Why is formal proof any easier, then? If anything complex is either
a library package or a code pattern, then formal proof would have to
include these. Patterns are useful, of course, but they do not establish
proof by just being patterns?

> And for me production-wise it was a big bonus. When you are coding, your immediate working knowledge consists of exactly those 17 pages.

How is it that you know the libraries and the code patterns?
Can't be from the 17 pages of the report as it mentions none of them.

WRT the Ada LRM, this "works" for me:
*if* a text book or other introduction(*) or the rationale won't do:
employ the structure of the RM:

- The core language is text before Annex A. (Some 350 pages)
   (This would be the equivalent of the Oberon report.)
- In there, every section N has a few short paragraphs
   that introduce the section's topics formally, using definitions.
- Many subsections N.M start like the Oberon report, giving
   grammar; others focus on one subtopic. Note the recurring headings
   like _Syntax_ for a good guess at where you need to look.


> And you know them off by heart in no time, from doing them again and again.

Yet what is it that you know from 17 pages? It might feel good,
but that isn't good enough for a reference.

> And when you do your program design you dont get sidetracked by language complexities.

Can we get sidetracked by, say, improper choice of the code pattern?

__
(*) http://www.adaic.org/wp-content/uploads/2010/05/Ada-Distilled-24-January-2011-Ada-2005-Version.pdf

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Nasser M. Abbasi]

Since there was some discussion on sizes of RM for languages, I
tried to find a reference that lists such information, but not
able to find one. It is hard to find these online, but this is what
I found:

C++   : 1366
Ada   : 944
C     : 552
Pascal: 98

If you find more, feel free to update the list or correct it.


---------------------------------
C++ working draft  from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf

shows it is 1366 pages.
----------------------------------------

Ada RM ISO/IEC 8652:2012(E)  is 944 pages (dated December 2012)
http://www.ada-auth.org/standards/12rm/RM-Final.pdf
-----------------------------------------

C ISO  ISO/IEC 9899:TC3, dated 2007
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
is 552 pages
-------------------------------------

Fortran ISO WD 1539-1 ISO/IEC JTC 1/SC 22/WG5/N2014
ftp://ftp.nag.co.uk/sc22wg5/N2001-N2050/N2014.pdf
dated May 2014
675 pages

---------------------------------------------
Pascal ISO 7185 :1990
http://www.pascal-central.com/docs/iso7185.pdf
98 pages

-------------------------------------------------

--Nasser

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Nasser M. Abbasi]

I forgot Fortran. Here is the list again

C++      : 1366 pages
Ada      : 944  pages
Fortran  : 675  pages
C        : 552  pages
Pascal   : 98    pages


On 5/25/2015 3:01 PM, Nasser M. Abbasi wrote:
> Since there was some discussion on sizes of RM for languages, I
> tried to find a reference that lists such information, but not
> able to find one. It is hard to find these online, but this is what
> I found:
>
> C++   : 1366
> Ada   : 944
> C     : 552
> Pascal: 98
>
> If you find more, feel free to update the list or correct it.
>
>
> ---------------------------------
> C++ working draft  from
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf
>
> shows it is 1366 pages.
> ----------------------------------------
>
> Ada RM ISO/IEC 8652:2012(E)  is 944 pages (dated December 2012)
> http://www.ada-auth.org/standards/12rm/RM-Final.pdf
> -----------------------------------------
>
> C ISO  ISO/IEC 9899:TC3, dated 2007
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> is 552 pages
> -------------------------------------
>
> Fortran ISO WD 1539-1 ISO/IEC JTC 1/SC 22/WG5/N2014
> ftp://ftp.nag.co.uk/sc22wg5/N2001-N2050/N2014.pdf
> dated May 2014
> 675 pages
>
> ---------------------------------------------
> Pascal ISO 7185 :1990
> http://www.pascal-central.com/docs/iso7185.pdf
> 98 pages
>
> -------------------------------------------------
>
> --Nasser
>
>
>
>
>
>

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Monday, May 25, 2015 at 10:04:05 PM UTC+2, Nasser M. Abbasi wrote:
> I forgot Fortran. Here is the list again
> 
> C++      : 1366 pages
> Ada      : 944  pages
> Fortran  : 675  pages
> C        : 552  pages
> Pascal   : 98    pages
> 
> 
> On 5/25/2015 3:01 PM, Nasser M. Abbasi wrote:
> > Since there was some discussion on sizes of RM for languages, I
> > tried to find a reference that lists such information, but not
> > able to find one. It is hard to find these online, but this is what
> > I found:
> >
> > C++   : 1366
> > Ada   : 944
> > C     : 552
> > Pascal: 98
> >
> > If you find more, feel free to update the list or correct it.
> >
> >
> > ---------------------------------
> > C++ working draft  from
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf
> >
> > shows it is 1366 pages.
> > ----------------------------------------
> >
> > Ada RM ISO/IEC 8652:2012(E)  is 944 pages (dated December 2012)
> > http://www.ada-auth.org/standards/12rm/RM-Final.pdf
> > -----------------------------------------
> >
> > C ISO  ISO/IEC 9899:TC3, dated 2007
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> > is 552 pages
> > -------------------------------------
> >
> > Fortran ISO WD 1539-1 ISO/IEC JTC 1/SC 22/WG5/N2014
> > ftp://ftp.nag.co.uk/sc22wg5/N2001-N2050/N2014.pdf
> > dated May 2014
> > 675 pages
> >
> > ---------------------------------------------
> > Pascal ISO 7185 :1990
> > http://www.pascal-central.com/docs/iso7185.pdf
> > 98 pages
> >
> > -------------------------------------------------
> >
> > --Nasser
> >
> >
> >
> >
> >
> >
https://bitbucket.org/trijezdci/m2r10/downloadsM2R10.2014-01-31.tracked.pdf
modula2 revision 10   This is a new development no ISO yet
The previous revisions' ISO documents are only for sale.
163 pages

ftp://ftp.ethoberon.ethz.ch/Oberon/OberonV4/Docu/OberonReport.ps
Oberon (1990 version)
17 pages

http://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf
Oberon-07
17 pages

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Jacob Sparre Andersen]

jan.de.kruyf@gmail.com writes:
> On Monday, May 25, 2015 at 10:04:05 PM UTC+2, Nasser M. Abbasi wrote:

>> C++      :              1366 pages
>> Ada      :               944 pages
>> Fortran  :               675 pages
>> C        :               552 pages

> modula2 revision 10 [...] 163 pages

>> Pascal   :                98 pages

> Oberon (1990 version)      17 pages

> Oberon-07                  17 pages

How much shorter would those texts be if:

1) All optional sections were removed.

2) All informative sections were removed.

3) All libraries, which can be implemented using only non-optional
   language features, were removed.

And how well would a team of student manage John McCormick's train
modeling course with each language?  (I think McCormick is still
teaching?  Can we get him to run that experiment?)

Greetings,

Jacob
-- 
ACRONYM: A Contrived Reduction Of Nomenclature Yielding Mnemonics

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Tuesday, May 26, 2015 at 9:52:39 AM UTC+2, Jacob Sparre Andersen wrote:

> And how well would a team of student manage John McCormick's train
> modeling course with each language?  (I think McCormick is still
> teaching?  Can we get him to run that experiment?)
> 

Yess!
Jacob, I like that idea. If we want to learn anything this will be one of the things to do.
Language wars are a very inefficient way of using time, so I have tried to refrain from it. But it seems answers are needed on the matter of Oberon.

So now you guys have put so much (thank you) that I will have to read a bit of compiler code. That is where old man Wirth will have hidden his answers. Since there is and never was meant to be an ISO document. So bear with me please, I need some time.

There are strong similarities between Modula and Ada, they were both designed in the same years: 1977 onward. And both grew from Pascal.
Ada in request to a Dod requirement, and Modula as a teaching language.

Now Ada has grown with the crowd.
Ada95's syntax volume stands at roughly 3000 lexemes on par with C#.
C++ is slightly less at 2500 or so. 

The old man (working in Georg's garage :) found scientific reason to follow the 'reduced instruction set' trend, that was and still is, popular in hardware CPU design. And came up with Oberon, with stands at 700 lexemes.

 (data according to S.Z.Sverdlov "Programming languages and translation methods", Piter Press, 2007)

My suggestion is not: "Ada must be like Oberon." That is childish bull.
And also my question to you is not "what is wrong with Oberon" I know most of that.

My question is "can we learn something, is it worth it to see if Ada could be more compact perhaps. (In my experience it definitely is, but that is speaking from where I stand)
Could the immense brain power of some of the highest paid software engineers be applied to the issue of 'progressive refinement' of what exists in Ada? Could we find scientific reason for a critical look at where Ada in particular (and IT in general) is going?
I mean a few high visibility software projects are again suffering  of "misinformation over the final cost". The JSF comes to mind.

And talking about JSF: is it possible to outbid the C crowd? So we do not see any more of this running to C programmers ("yes, we still have all the Ada methodologies in place, it will not be a problem") (this should be filed under famous last words!)


cheers,

j.
--
"We have to learn how to use our words. It's a fantastic thing--we humans are so easily trapped in our own words. 
The word time, for instance--we run into puzzles about the concept of time and then we say, oh, what a terrible thing. We don't realize we're the source of the puzzles
because we invented the word....
                           John Archibald Wheeler.




> Greetings,
> 
> Jacob
> -- 
> ACRONYM: A Contrived Reduction Of Nomenclature Yielding Mnemonics

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

Here is a follow up to my previous post:
I happen to find the system TRAP list of native Oberon for pc. (so not the latest version 07)

If my memory serves me right the compiler was written for a master thesis at eth.

It is not a military strength compiler obviously, but for industrial use it has proven itself.

A trap would automatically give a stack trace. the location could be found back by compiling with debug info.

Georg, please note TRAP2 :)

Perhaps we are here just discussing 25 years after the fact. 
And perhaps the language report is what it is to encourage the discussion which led to this:

--------------------------------------------

Trap numbers fall into the following ranges:
Traps -39 to -32 are generated by the floating-point unit of the processor. By default floating-point checks are disabled and the special overflow and error values INF and NaN are generated (see module Reals).
Traps -31 to 0 are generated by the processor.
Traps 1 to 10 are generated by compiler-inserted checks.
Traps 11 to 19 are generated by system modules.
Traps 20 and above are generated by HALT or ASSERT statements.

More detailed information about specific traps:
TRAP -35 Floating-point stack fault: The floating-point unit made an incorrect memory reference.
TRAP -34 Floating-point operation invalid: The floating-point stack overflowed or underflowed, or an invalid arithmetic operand was encountered (disabled by default).
TRAP -33 Floating-point overflow: Caused by an arithmetic overflow (disabled by default).
TRAP -32 Floating-point division by 0: Caused by an attempt to divide by 0 (disabled by default).
TRAP -16 Floating-point error: Generic floating-point error.
TRAP -14 NIL reference / Stack overflow / Page fault: An incorrect memory reference occured. This could be the result of a NIL pointer reference or a stack overflow.
TRAP -13 General protection fault: This is a generic exception generated by the processor. Refer to the processor documentation for more information.
TRAP -12 Stack overflow: An incorrect memory reference occured in a stack segment.
TRAP -6 Invalid instruction: An invalid machine instruction was encountered. This could be the result of a corrupted module in the heap.
TRAP -4 Overflow: An integer overflow. These checks are disabled by default and can be enabled with the \v switch of the compiler.
TRAP 0 Division by zero: A DIV (or MOD) by 0 occured, or the result of a divide was too big for the destination type.

TRAP 1 WITH guard failed: The type guard in a WITH statement failed (can be disabled with the \t compiler switch).
TRAP 2 CASE invalid: A CASE expression evaluated to a value that has no label, and the CASE has no ELSE clause.
TRAP 3 RETURN missing: A function procedure ended without a RETURN statement.
TRAP 4 Overflow: See TRAP -4.
TRAP 5 Implicit type guard failed: An implicit type guard generated as part of an assignment failed (can be disabled with the \t compiler switch).
TRAP 6 Type guard failed: An explicit type guard failed (can be disabled with the \t compiler switch).
TRAP 7 Index out of range: An array index was out of range (can be disabled with the \x compiler switch).
TRAP 8 ASSERT failed: A programmed ASSERT statement failed (can be disabled with the \a compiler switch).
TRAP 9 Array dimension error: A dynamically computed array dimension was incorrect (e.g. negative dimension in a NEW).

TRAP 13 Keyboard interrupt: A keyboard interrupt was generated with Ctrl-Break.
TRAP 14 Out of memory: The requested memory allocation (NEW) could not be fulfilled.
TRAP 15 Bad sector number: An incorrect sector number was detected. This could be the result of an error with on-disk file system structures, or memory corruption.
TRAP 16 Disk full: The disk is almost full. Reboot to have the disk garbage collector run during startup.
TRAP 17 Disk error: The disk driver encountered a hardware error. The local variable "err" or "res" contains further information.
TRAP 18 File too large: A file was generated that is too large for the file system.
TRAP 19 Buffer overflow: Generated by Files.ReadBytes and WriteBytes if the supplied buffer is too small.
-------------------------------------------

cheers,

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

<jan.de.kruyf@gmail.com> wrote in message 
news:20c56bea-2803-4aa9-a626-2d25e480df20@googlegroups.com...
...
>Now Ada has grown with the crowd.
>Ada95's syntax volume stands at roughly 3000 lexemes on par with C#.
>C++ is slightly less at 2500 or so.
>
>The old man (working in Georg's garage :) found scientific reason to follow 
>the 'reduced
>instruction set' trend, that was and still is, popular in hardware CPU 
>design. And came
>up with Oberon, with stands at 700 lexemes.

Other people mentioned it, but the number of pages is a horrible measure. 
Ada's standard was designed to be readable by actual programmers, thus it 
uses lots of extra descriptive text, shows lots of examples, and has lots of 
space-wasting internal headers. And, the Oberon standards contain no runtime 
library, that's a huge part of the Ada Standard. We've also got lots of 
reference indexes which are intended to make it easier to find things. So 
looking at the current Ada 2012+TC1 document:

Total: 951 pages (PDF).
Non-normative indexes, summarys, and tables: (Annex K-Q [106 pages], Table 
of Contents [10 pages], Index [53 pages]) [169 pages]
ISO mandated boilerplate, acknowledgements, other useless cruft: 16 pages.
Description of how the standard is organized (Chapter 1): 8 pages.
Clauses totally devoted to examples: 9.11 (3 pages); 12.8 (2 pages); 11.4.3 
(1 page); 13.11.6 (3 pages). [9 pages]
Libraries included in the core description (half of 3.9 - 2 pages; most of 
9.6, 9.6.1 - 8 pages; most of 13.11, 13.11.4, 13.11.5 - 5 pages).
The core library (Annex A): 227 pages.
Interfacing to foreign languages (mostly libraries): 28 pages.
Specialized needs annexes (these are optional - Annex C-H): 138 pages.
Obsolete stuff (Annex J): 14 pages.

That leaves the actual language definition at 337 pages. To be fair, one 
could eliminate stuff not even contemplated by Oberon - tasks (Chapter 9, 40 
pages), generics (Chapter 12, 18 pages not including the example removed 
earlier), and low-level programming (Chapter 13, 51 pages excluding the 
example removed earlier).

So now we're at 228 pages. With some reformatting, and removing all of the 
introductory text, notes, and examples, we'd save at least 20% of that 
(probably more). So that means that an equivalently formatted Ada standard 
would probably be roughly 180 pages (or maybe 270 if we left everything in).

Surely I could get the core of the Standard into 17 pages if I reformatted 
it enough (you'd probably need a magnifying glass to read it, though). 
Meaning that the number of pages doesn't mean much.

Is that bloat? Dunno. It's certainly a lot of extra precision in describing 
things, making code following the standard more likely to be portable. 
Hardly any programming languages describe the process of elaboration, or 
carefully define how finalization happens, including in weird corner cases 
that aren't likely to actually happen. And so on.

Assuming that your description of the syntax is accurate, the Oberon manual 
is clearly leaving out vast amounts of needed detail. (And no, you can't 
look at source of a compiler to "augment" a language standard!). The Ada 
syntax alone takes up 21 pages in the Ada standard. That means that the 
Oberon syntax should take up 21/3000*700 = 4.9 pages of text. That leaves 
precious little space to describe the visibility rules for packages (to take 
one nasty example).

And, of course, Wirth himself has a long history of writing sloppy language 
standards and leaving when other people try to clean them up (Algol-W, 
Pascal, Modula, Modula 2, ...). He's a brilliant language designer, but he 
always has underdescribed standards. (That surely includes building 
standards without any library description, which is nonsense for any 
purpose.)

Summary: standard page counts are meaningless. One can change them wildly by 
removing non-normative stuff, by reformatting, by leaving out the libraries 
that every programmer will need, and other stuff that has nothing whatsoever 
to do with content.

                                 Randy Brukardt, ARG Editor.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Stefan.Lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3553 bytes --]

On Thu, 28 May 2015, Randy Brukardt wrote:

> That leaves the actual language definition at 337 pages. To be fair, one
> could eliminate stuff not even contemplated by Oberon - tasks (Chapter 9, 40
> pages), generics (Chapter 12, 18 pages not including the example removed
> earlier), and low-level programming (Chapter 13, 51 pages excluding the
> example removed earlier).
>
> So now we're at 228 pages. With some reformatting, and removing all of the
> introductory text, notes, and examples, we'd save at least 20% of that
> (probably more). So that means that an equivalently formatted Ada standard
> would probably be roughly 180 pages (or maybe 270 if we left everything in).

Actually, you could get away with significantly less (I'd say, less than 
100 pages) if you rewrote the manual in an Oberon-like (or Wirthian) 
style, i.e., a manual that tells the programmer what he or she needs to 
know, but leaves plenty of details unspecified which the compiler writer 
would need to know.

Such as overloading and visibility rules. For programmers, some simple 
rules of thumb work most of the time. And if not, then the compiler will 
give a (somewhat unexpected) error message, giving the programmer the 
chance to fix the issue. I don't remember that by ignoring the rules I 
ever got an executable doing something unexpected. On the other hand, for 
independent and compatible implementations, the reference manual is a lot 
more specific.

Hmmm, I wonder if a new "simplistic Ada reference manual" would be 
appreciated by programmers ...

> And, of course, Wirth himself has a long history of writing sloppy language
> standards and leaving when other people try to clean them up (Algol-W,
> Pascal, Modula, Modula 2, ...). He's a brilliant language designer, but he
> always has underdescribed standards. (That surely includes building
> standards without any library description, which is nonsense for any
> purpose.)

Now *that* is unfair to Wirth! (Not the part with the brilliant language 
designer, but the other part.)

Firstly, compare the Algol-W and Pascal reports with other language 
reports and standards proposed at the same time. Which of these had a 
remotely reasonable standard library? Even the Ada 83 standard library 
is rather unimpressive, IMHO. Both Algol-W and Pascal are much 
older than Ada 83. (I am too lazy to look up when Modula has been 
proposed.)

Secondly, Oberon is younger than Ada 83, but is has been developed for a 
specific purpose. At least initially, Oberon was not meant to become a 
general purpose language. Also, even if there isn't much of a "Oberon 
standard library", there is the Oberon operating system and its library.

Thirdly, there are two general alternative approaches to language design:

1. Design a language precisely specifying almost everything (and defining 
unspecified details explicitly as unspecified), like Ada, or

2. Design a language with the specification omitting plenty of minor 
details. Let peaople argue about it. Over time, and with practical 
experience from using that language, fill the gaps.

Either approach has advantages and disadvantages. Of course, Ada was not 
an academic proposal, but a standard from the beginning, so approach 2 was 
never an option for Ada.


------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Jeffrey R. Carter]

On 05/29/2015 01:51 AM, Stefan.Lucks@uni-weimar.de wrote:
> 
> Hmmm, I wonder if a new "simplistic Ada reference manual" would be appreciated
> by programmers ...

That's a good idea. We could call it "Ada Distilled".

-- 
Jeff Carter
"Drown in a vat of whiskey. Death, where is thy sting?"
Never Give a Sucker an Even Break
106

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.11.1505291006310.28509@debian...
>On Thu, 28 May 2015, Randy Brukardt wrote:

>> So now we're at 228 pages. With some reformatting, and removing all of 
>> the
>> introductory text, notes, and examples, we'd save at least 20% of that
>> (probably more). So that means that an equivalently formatted Ada 
>> standard
>> would probably be roughly 180 pages (or maybe 270 if we left everything 
>> in).
>
>Actually, you could get away with significantly less (I'd say, less than
>100 pages) if you rewrote the manual in an Oberon-like (or Wirthian)
>style, i.e., a manual that tells the programmer what he or she needs to
>know, but leaves plenty of details unspecified which the compiler writer
>would need to know.

Which only works if there is never going to be more than one compiler (i.e. 
Oberon, Eiffel). Otherwise, it will eventually be a disaster, or the details 
will get filled in, or both.

...
>> And, of course, Wirth himself has a long history of writing sloppy 
>> language
>> standards and leaving when other people try to clean them up (Algol-W,
>> Pascal, Modula, Modula 2, ...). He's a brilliant language designer, but 
>> he
>> always has underdescribed standards. (That surely includes building
>> standards without any library description, which is nonsense for any
>> purpose.)
>
>Now *that* is unfair to Wirth! (Not the part with the brilliant language
>designer, but the other part.)

Not really. He complained about other people's language designs not being 
precise (in his Turing Award speech in particular vis-a-vis PL/I), but his 
don't seem to need the same amount of detail. I call BS on that.

                                   Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 29, 2015 at 11:51:40 PM UTC+2, Randy Brukardt wrote:

> 
> >> So now we're at 228 pages. With some reformatting, and removing all of 
> >> the
> >> introductory text, notes, and examples, we'd save at least 20% of that
> >> (probably more). So that means that an equivalently formatted Ada 
> >> standard
> >> would probably be roughly 180 pages (or maybe 270 if we left everything 
> >> in).
> >
> >Actually, you could get away with significantly less (I'd say, less than
> >100 pages) if you rewrote the manual in an Oberon-like (or Wirthian)
> >style, i.e., a manual that tells the programmer what he or she needs to
> >know, but leaves plenty of details unspecified which the compiler writer
> >would need to know.
> 
> Which only works if there is never going to be more than one compiler (i.e. 
> Oberon, Eiffel). Otherwise, it will eventually be a disaster, or the details 
> will get filled in, or both.
> 
> ...
> >> And, of course, Wirth himself has a long history of writing sloppy 
> >> language
> >> standards and leaving when other people try to clean them up (Algol-W,
> >> Pascal, Modula, Modula 2, ...). He's a brilliant language designer, but 
> >> he
> >> always has underdescribed standards. (That surely includes building
> >> standards without any library description, which is nonsense for any
> >> purpose.)
> >
> >Now *that* is unfair to Wirth! (Not the part with the brilliant language
> >designer, but the other part.)
> 
> Not really. He complained about other people's language designs not being 
> precise (in his Turing Award speech in particular vis-a-vis PL/I), but his 
> don't seem to need the same amount of detail. I call BS on that.
> 
>                                    Randy.

Randy,
I think his comments were deeply grounded, but in something I have not seen discussed in connection with Ada, or a few other languages for that matter.
So I understand what you are saying, but I think it is groundless.

For the old man a language is "right" when the EBNF diagram is "right" or perhaps "beautiful". (EBNF : Extended Backer Naus Formalism) Beautiful for a swiss person would then translate to: rather minimalistic, so you can see the structure well. This is a culture thing. And "right" would be mathematically right, because that is the whole object of drawing up an EBNF in the first place. He has a strong base in that, as he was a pupil of old Dijkstra, who programmed by contract in his day. The contract being the spec of the hardware not build yet. Those programs generally were faultless, since the mathematical basis was right.
All his life Wirth has striven to get that part right, which is why he started over a few times to see if he could beautify that part a bit more.

A good clear EBNF is for him (and for me) a very strong indicator of the precision and the ease of use of any language.
Almost _everything_ follows from the 2 pages of EBNF. The compiler structure. The error detection. You name it. 
And from the discussion here it was quite clear that where Oberon needs text over and beyond the EBNF things immediately were murky and open to critique.

In youthful courage (or silliness, depending where you stand) I once set out to "fix" something in Oberon. 
In those days memory was still expensive on a microcontroller so I set out to add a bit type, which would then be part of a byte (this being 8 bit world), which was very useful to me. I succeeded reasonably well and it worked ok. But the EBNF was bludgeoned beyond recognition and strangely so was the compiler. Especially the type tree.
So I will not fall for that temptation again, I plainly do not have the mathematical background for such an undertaking, in hindsight it was not worth it. Before I could just consult the EBNF if I was unclear about some language construct, now I had to find my notes back. nah!

So if you want to do any cleaning up I would say lets start with drawing up a EBNF of Ada. It will explain the critique from Dijkstra and Wirth, and it will explain the calls for a simpler Ada that we have heard since day 1 according to JPRosen.

And the biggest bonus will be that we will be able to work faster, once we have a good understanding of the mathematical underpinnings of the language.


j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Dmitry A. Kazakov]

On Sat, 30 May 2015 03:28:51 -0700 (PDT), jan.de.kruyf@gmail.com wrote:

> For the old man a language is "right" when the EBNF diagram is "right" or perhaps "beautiful".

BNF describes the language syntax or a formal language. Formal language <<<
programming language. Since 60's there is nothing interesting you could
describe in BNF or in any other syntactic formalism. We do know how "good"
syntax looks like.

> All his life Wirth has striven to get that part right,

You mean IF-THEN-ELSE, did he? (:-))

BTW, in all Wirth books I ever read he used directed graphs for syntax
definitions instead of BNF.

> So if you want to do any cleaning up I would say lets start with drawing
> up a EBNF of Ada.

ARM Annex P.

That is less than 0.1% of what constitutes a programming language.

> It will explain the critique from Dijkstra and Wirth,

It wasn't for Ada syntax AFAIK.

> And the biggest bonus will be that we will be able to work faster, once we
> have a good understanding of the mathematical underpinnings of the
> language.

Which ones? There is no problem parsing Ada. It is trivial, in fact. There
is little or nothing to understand there from a mathematical point of view. 

And this is not a problem people have with Ada. Even those, who dearly want
curly brackets and = for assignment, should understand that grammatically
there would be absolutely NO difference. Whether the end token is "end" or
"}" matters only aesthetically.

Few syntax problems Ada has come straight from Wirth himself. E.g.
different syntax for declarations of subprogram types and values (bodies)
from other types and values. Wirth seems never cared much about types.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Saturday, May 30, 2015 at 1:12:20 PM UTC+2, Dmitry A. Kazakov wrote:

> BNF describes the language syntax or a formal language. Formal language <<<
> programming language. Since 60's there is nothing interesting you could
> describe in BNF or in any other syntactic formalism. We do know how "good"
> syntax looks like.

yes we do know that. But you did not address what I said yet. 

I am trying to stress this here:
"The mathematical aspect dictates that the language be elegant, but simple to describe mathematically. Lisp-like languages are an example of languages for which this aspect is especially noticeable.
Other ways to describe this aspect are to say that the language should have an inherent simplicity and be easy to learn, expressive and orthogonal. Expressiveness is the power of a language to solve problems. Orthogonality requires combinations of legal constructs to be themselves legal constructs." 
(fom http://web.cs.wpi.edu/~kal/courses/cs4533/module2/grammars.html)
And please save me your comment about lisp, I do not know it, and it is immaterial in this discussion.


> You mean IF-THEN-ELSE, did he? (:-))

It is funny that I dont recall ever having a problem with it. I do recall being caught for a sucker because I did not forsee the consequences of my own doings.
Unless you talk of an issue before my time? . .
> 
> BTW, in all Wirth books I ever read he used directed graphs for syntax
> definitions instead of BNF.

Did not see any lately but I vaguely remember the Apple Pascal book had them.

> 
> > So if you want to do any cleaning up I would say lets start with drawing
> > up a EBNF of Ada.
> 
> ARM Annex P.

Thank you! I missed that.
The question to be resolved next is whether I can use it in day to day coding practice.

>
 
> That is less than 0.1% of what constitutes a programming language.

No it is not, unless you call the library the other 99.9 %.
In other words I suspect we are arguing about semantics here.

> 
> > It will explain the critique from Dijkstra and Wirth,
> 
> It wasn't for Ada syntax AFAIK.

No I did not hear or see that either. It was much rougher than that, in good swiss (and dutch) fashion. :)

> 
> > And the biggest bonus will be that we will be able to work faster, once we
> > have a good understanding of the mathematical underpinnings of the
> > language.
> 
> Which ones? There is no problem parsing Ada. It is trivial, in fact. 

Yes it _is_ trivial . . . for a computer or a highly trained person like you.
But we are talking here about the class of programmers you refer to in your next paragraph. 

> 
> And this is not a problem people have with Ada. Even those, who dearly want
> curly brackets and = for assignment, should understand that grammatically
> there would be absolutely NO difference. Whether the end token is "end" or
> "}" matters only aesthetically.

So now we could argue that it will be good to have both ways in the language. I mean it will be trivial to put into the ebnf and trivial to parse. And that specific group of programmers will like it, etc, etc.
Or we can argue that they need to be educated in the syntax of Ada, as you say.
Because clearly from other fields of human experience we know that it will only cause confusion.

So similarly I argue ---Not that this language or that language is Better--- but that there is room for improvement in Ada, And where this improvement can be made will follow from the reading and trying to understand appendix P as the core document of the language.

But the crowd likes to turn this into a language war around every corner, perhaps because from other fields of human experience it is also known that it is very difficult to do self refection.

> Few syntax problems Ada has come straight from Wirth himself. E.g.
> different syntax for declarations of subprogram types and values (bodies)
> from other types and values. Wirth seems never cared much about types.
> 

Believe it or not he did, but he has never been known to be paranoid. 

Dmitry, when I first got to know Ada I jumped on it specially for the nice multitude of types (since that is what I learned from the old man, to be typesafe) But after a few years of experience I find that I have often confused myself plainly with having too many types. 
So you could perhaps say that that was for lack of solid design. Could be. But then I find the same multitude of unchecked conversions back in gnat. So apparently it is not only me. 

By the way the other day I looked at your website and I stood in awe of the artworks you display there. Thank you.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Clubley]

On 2015-05-30, jan.de.kruyf@gmail.com <jan.de.kruyf@gmail.com> wrote:
> On Saturday, May 30, 2015 at 1:12:20 PM UTC+2, Dmitry A. Kazakov wrote:
>> You mean IF-THEN-ELSE, did he? (:-))
>
> It is funny that I dont recall ever having a problem with it. I do
> recall being caught for a sucker because I did not forsee the
> consequences of my own doings.
> Unless you talk of an issue before my time? . .

It was a very well known issue in the early versions of some languages.

Some reading for you:

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

Simon.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Saturday, May 30, 2015 at 5:01:22 PM UTC+2, Simon Clubley wrote:

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

Ah, that stinker. I remember still using some homegrown language about 15 years ago that had it. From a very well known motion control company in the US.

In any case I just had a lovely time reading history. 

http://heerdebeer.org/ALGOL/The_History_of_ALGOL.pdf

Beer has nothing about it, but the dangling else was in the original algol60 and Wirth did not notice when he did algol-W. It still is in his first ebnf.
Sortly therafter it was found and fixed by everybody. I dont seem to be able to trace whodone it. But Algol was very much a laguage being born in those days, And lots of people were involved

He brings the issue up in his Compiler construction book. As an exercise in spotting errors.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Dmitry A. Kazakov]

On Sat, 30 May 2015 06:21:01 -0700 (PDT), jan.de.kruyf@gmail.com wrote:

> On Saturday, May 30, 2015 at 1:12:20 PM UTC+2, Dmitry A. Kazakov wrote:
> 
>> BNF describes the language syntax or a formal language. Formal language <<<
>> programming language. Since 60's there is nothing interesting you could
>> describe in BNF or in any other syntactic formalism. We do know how "good"
>> syntax looks like.
> 
> yes we do know that. But you did not address what I said yet. 
> 
> I am trying to stress this here:
> "The mathematical aspect dictates that the language be elegant, but simple
> to describe mathematically.

I think this is untrue. Mathematical descriptions are based on the language
of mathematics. Actually there are a lot of such languages depending on the
sets of axioms taken and the methods of proofs considered acceptable, e.g.
constructive mathematics etc. But that is beside the point, which is that
whatever mathematical language you took, it is far more powerful than any
programming language because its "computational" framework is infinite,
sometimes uncountable infinite etc. Trivial mathematical descriptions may
be incomputable, thus whatever elegancy of triviality they posses, you
could not express that in any programming language. And conversely, trivial
things in a programming language might be quite impossible to describe
mathematically. E.g. anything that involves constraints. For example, brute
force methods working fine just because it is a finite number of states.

> Lisp-like languages are an example of
> languages for which this aspect is especially noticeable.

Or pattern matching languages, or relational algebra languages, elegant to
someone's, should I say pervert, mind and unusable for decent software
developing.

> Other ways to describe this aspect are to say that the language should
> have an inherent simplicity and be easy to learn, expressive and
> orthogonal. Expressiveness is the power of a language to solve problems.

That yardstick is too crude. Most languages are Turing-complete, you can
solve any solvable problem in practically any programming language.

It is the programming techniques and paradigms that make problems, not
solvable, that is a precondition, but manageable, solutions economically
feasible, safe etc.

> Orthogonality requires combinations of legal constructs to be themselves
> legal constructs."

I understand the intention, but taken literally this is an evident rubbish.
There are certain rules (an algebra) to apply to the language entities in
order to obtain new entities. It is not just combinations (there are
operations in the algebra) and not any combinations (there are constraints
to which operations apply to which entities, yep, those pesky types again).
 
>> That is less than 0.1% of what constitutes a programming language.
> 
> No it is not, unless you call the library the other 99.9 %.
> In other words I suspect we are arguing about semantics here.

Of course it is the semantics which makes these 99.9%. Of course the
popularity vote disregards semantics and see if there are curly brackets
here.

>>> And the biggest bonus will be that we will be able to work faster, once we
>>> have a good understanding of the mathematical underpinnings of the
>>> language.
>> 
>> Which ones? There is no problem parsing Ada. It is trivial, in fact. 
> 
> Yes it _is_ trivial . . . for a computer or a highly trained person like you.

Nobody ever claimed Ada less readable than C, Lisp, you name it. But yes,
the language must be comfortable for trained people. How much of your
productive time do you stay untrained? Either it takes one month to learn
and then you are using it professionally all your time, or it is wasting
time altogether. Ergo, learning curve is irrelevant. Though I bet that Ada
is far easier to learn than C, C++ or any other fancy language.

> Or we can argue that they need to be educated in the syntax of Ada, as you say.

We can safely say that Ada is far more readable than EBNF. Even highly
trained people could not say whether given sequence were legal according to
given EBNF.

> But the crowd likes to turn this into a language war around every corner,

Not really. What I am trying to stress is that problems lie elsewhere.
These problems are huge and nobody gives a damn. Curly brackets that's
important!

>> Few syntax problems Ada has come straight from Wirth himself. E.g.
>> different syntax for declarations of subprogram types and values (bodies)
>> from other types and values. Wirth seems never cared much about types.
> 
> Believe it or not he did, but he has never been known to be paranoid. 

He himself wrote as a title: Algorithms + Data Structures = Programs

> Dmitry, when I first got to know Ada I jumped on it specially for the nice
> multitude of types (since that is what I learned from the old man, to be
> typesafe) But after a few years of experience I find that I have often
> confused myself plainly with having too many types.

There is never too many types. It is simply so that you probably confined
to the idea of algorithms and data being programs.

> So you could perhaps say that that was for lack of solid design. Could be.
> But then I find the same multitude of unchecked conversions back in gnat.
> So apparently it is not only me. 

Even in c.l.a lot of people honestly believe in that idea. Then GNAT was
started in Ada 83 times. And even now Ada's type system is too weak to
express great many things. That is how you get Unchecked_Conversion, access
types and Constraint_Error.

> By the way the other day I looked at your website and I stood in awe of
> the artworks you display there.

Thanks.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Saturday, May 30, 2015 at 6:40:59 PM UTC+2, Dmitry A. Kazakov wrote:


> I think this is untrue. Mathematical descriptions are based on the language
> of mathematics. Actually there are a lot of such languages depending on the
> sets of axioms taken and the methods of proofs considered acceptable, e.g.
> constructive mathematics etc. But that is beside the point, which is that
> whatever mathematical language you took, it is far more powerful than any
> programming language because its "computational" framework is infinite,
> sometimes uncountable infinite etc. Trivial mathematical descriptions may
> be incomputable, thus whatever elegancy of triviality they posses, you
> could not express that in any programming language. And conversely, trivial
> things in a programming language might be quite impossible to describe
> mathematically. E.g. anything that involves constraints. For example, brute
> force methods working fine just because it is a finite number of states.

The Dijkstra - Wirth school differs from you here, whether justified or not I cannot say, I am not a trained mathematician. All I can say is that 
1. they came to their conclusions mainly because of their experience teaching undergraduates and through struggling with the matter themselves.
2. that I personally work a lot easier in a well defined elegant language.
3. Some great discoveries in computer science were made in those days by applying their homegrown mathematical rules. it is fascinating reading.

At the same time I gladly give you that something as strictly defined as that does not fit well with Windows or Linux or you name it. I am doing a kernel module adaption at the moment and also Ada and Linux kernel fit very badly.

> 
> Or pattern matching languages, or relational algebra languages, elegant to
> someone's, should I say pervert, mind and unusable for decent software
> developing.

Yes I did try to make emacs behave on the odd occasion, but then I did not want to destroy the quote since it brings some worthwhile issues to debate.

> 
> > Other ways to describe this aspect are to say that the language should
> > have an inherent simplicity and be easy to learn, expressive and
> > orthogonal. Expressiveness is the power of a language to solve problems.
> 
> That yardstick is too crude. Most languages are Turing-complete, you can
> solve any solvable problem in practically any programming language.

True but not all are easily applied to a particular problem. Ada is very nice for big technical projects, C is good if you want curly brackets, Oberon is excellent when you dont know yet which language fits best, because you make up what you need out of the lowlevel blocks, but as soon as there is an operating system involved you are stuffed again. 
So perhaps the expressiveness and the simplicity are in relation to the problem you want to solve.

> 
> > Orthogonality requires combinations of legal constructs to be themselves
> > legal constructs."
> 
> I understand the intention, but taken literally this is an evident rubbish.
> There are certain rules (an algebra) to apply to the language entities in
> order to obtain new entities. It is not just combinations (there are
> operations in the algebra) and not any combinations (there are constraints
> to which operations apply to which entities, yep, those pesky types again).
>  
I am with you but
Perhaps he means to say something, more in relation to the dangling else and similar issues. An if then else might be legal, but the combination of 2 of them might not be in some circumstances.
After all this piece of text was written for an undergraduate class.

> Of course it is the semantics which makes these 99.9%. Of course the
> popularity vote disregards semantics and see if there are curly brackets
> here.

I note that here we move away from computer science and into woollen socks science. (Named after the habitual foot wear of the members of faculty)
i.e. we will have to look at social science for an answer here. 
I am attracted to the D-W school exactly because it was shaped by the daily interaction with dumb people. Although Wirth might deny that.

We may sit and talk here till the cows come home, but the convincing arguments will only come about in discussion with the curly bracket programmers.


> We can safely say that Ada is far more readable than EBNF. Even highly
> trained people could not say whether given sequence were legal according to
> given EBNF.

I just meant to say that I am comfortable using the EBNF as a reference to Oberon. It tells me everything I need to know in almost all cases.

I just had a giggle and tried to look up "pure" in the bnf. It is not there. Then I went back to the index which referred me to some place about 10 lines below where I should have read.On reading the right section I decided better wait until tomorrow when I am fresh, my digestion will work better. So all in all I might perhaps say that the social sciences where not involved when the ARM was written, because believe it or not, there are certain editing rules that promote clarity.
This is not to drag the ARM editors down, its just to point out that logically it is no doubt correct, but there are almost no people whose first language is "logic".

> 
> > But the crowd likes to turn this into a language war around every corner,
> 
> Not really. What I am trying to stress is that problems lie elsewhere.
> These problems are huge and nobody gives a damn. Curly brackets that's
> important!

I was not blaming you really. But it does get annoying when a person has to take a week fighting all kind of attacks, just to get the crowd to do at least some reflexion on where we all are going with Ada. 
And based on social science I would say that the picture is not good. But then there is a lot of money behind it from a source that will never dry up (armaments)

> 
> He himself wrote as a title: Algorithms + Data Structures = Programs

Yes I got that book. What it covers is not bad, What is left out is the problem.
But types hardly belong there. They are in chapter 2, 8, 9, 11 and 12 of the undergraduate book (at least in the Oberon version of those books)
He turns that issue over and over and over until it is correct and elegant. 
That is not to say we cant expand on it, but the basis and more importantly the reason why, are there.

> There is never too many types. It is simply so that you probably confined
> to the idea of algorithms and data being programs.
> 

My first experience of the issue was when I was barely literate in basic and started to do assemlby. I learned then to draw some circles representing the functions (algorithms if you like) and lines connecting them, representing function calls.
In those function-call-lines I used to draw a big spiel, meticulously specifying the data that was exchanged. Those interfaces were much bigger than any of the rest. That was my first experience with (homegrown) typing of my data. And it worked like a bomb. All of a sudden I saw structure. This was long before the universities tought anything like it. 
So I am all for types, they bring clarity and abstraction in my programs, they might indicate units for physical quantities etc.

But once we get to the very same unsigned quantity or menory address defined in 5 different places by 5 different people who then at the last minute quickly made a kludge to be able to read each others data, then I say let types be damned. I need to get on with the job here. 

> 
> Even in c.l.a lot of people honestly believe in that idea. Then GNAT was
> started in Ada 83 times. And even now Ada's type system is too weak to
> express great many things. That is how you get Unchecked_Conversion, access
> types and Constraint_Error.
> 

Yes I am aware of your work with unit measures. So there I agree. But when the programmers just use types cause you need to use types cause the boss says so, then the problem is not having this type or that type, then the problem is a lack of knowledge, clarity and elegance in the methods those programmers have been taught. This problem can only be fixed by taking there toys away from them for a bit.
Then all the typing becomes meaningless, and suprise suprise gnat also suffers of that. I posted an example the other day involving passing a string to printk.
I am aware that part of gnat is quite old, but then we come to the issue of the vested interests, which also must be listened to of course, but that is not about language that is about money. So we will have to see how the 2 can meet.

cheers,

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Nasser M. Abbasi]

On 5/30/2015 3:52 PM, jan.de.kruyf@gmail.com wrote:

> I am doing a kernel module adaption at the moment and also Ada and Linux kernel fit very badly.
>

fyi, There was lots of discussion in making an Ada kernel/OS many years ago.

I do not know what happend to these activities. Here are some threads:

https://groups.google.com/forum/#!topic/comp.lang.ada/c9QzntBcAbI
https://groups.google.com/forum/#!topic/comp.lang.ada/9FsfbVPsuuQ
http://compgroups.net/comp.lang.ada/ada-os-based-on-minix3/1411184
http://compgroups.net/comp.lang.ada/open-source-ada-os/1412511

and more.

--Nasser

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Dmitry A. Kazakov]

On Sat, 30 May 2015 13:52:56 -0700 (PDT), jan.de.kruyf@gmail.com wrote:

> On Saturday, May 30, 2015 at 6:40:59 PM UTC+2, Dmitry A. Kazakov wrote:
> 
>>> Other ways to describe this aspect are to say that the language should
>>> have an inherent simplicity and be easy to learn, expressive and
>>> orthogonal. Expressiveness is the power of a language to solve problems.
>> 
>> That yardstick is too crude. Most languages are Turing-complete, you can
>> solve any solvable problem in practically any programming language.
> 
> True but not all are easily applied to a particular problem.

Yes, repeating the old saying - if C is a solution what was the problem?

> So perhaps the expressiveness and the simplicity are in relation to the
> problem you want to solve.

That is abstraction level in relation to the problem space. But, Ada, C,
etc thought to be universal purpose languages. If you wanted to define
expressiveness for such languages you should forget the escape to
relativism.

> I note that here we move away from computer science and into woollen socks
> science. (Named after the habitual foot wear of the members of faculty)
> i.e. we will have to look at social science for an answer here. 

As if social "science" could give answers.

> I am attracted to the D-W school exactly because it was shaped by the
> daily interaction with dumb people.

Students aren't dumb, not as programmers are! (:-))

>> We can safely say that Ada is far more readable than EBNF. Even highly
>> trained people could not say whether given sequence were legal according to
>> given EBNF.
> 
> I just meant to say that I am comfortable using the EBNF as a reference to
> Oberon. It tells me everything I need to know in almost all cases.

That is strange because syntax is such a minor part and because in case of
Ada it is very difficult (at least to me) to understand its BNF, because
they tried to push precedence (and some other) rules into it.

Luckily nobody, except maybe you, cares, since precedence rules are evident
from the titles of ARM table of contents.

>>> But the crowd likes to turn this into a language war around every corner,
>> 
>> Not really. What I am trying to stress is that problems lie elsewhere.
>> These problems are huge and nobody gives a damn. Curly brackets that's
>> important!
> 
> I was not blaming you really. But it does get annoying when a person has
> to take a week fighting all kind of attacks, just to get the crowd to do
> at least some reflexion on where we all are going with Ada.

Since 1995, nowhere.

> And based on social science I would say that the picture is not good.

Well, bringing relativism back, since there is no progress in programming
languages anyway Ada's position remains basically same. Nothing lost,
nothing gained. Some bad features added, but we are free not to use them.

> But
> then there is a lot of money behind it from a source that will never dry
> up (armaments)

There is no money behind. Even if military contractors were interested in
Ada, they are not, their money is miniscule compared to what is thrown into
rubbish languages by civilians and that together is nothing compared to
what is wasted on so-called tool-chains.

>> He himself wrote as a title: Algorithms + Data Structures = Programs
> 
> Yes I got that book. What it covers is not bad, What is left out is the problem.
> But types hardly belong there.

They do. The error is in trying to decompose any problem in terms of
standard numeric types. This starts with the notion of algorithm (operating
this rudimentary set of types) and data structures (amorph aggregation of
the same limited set of entities). This is inherently low-level with no
chance of abstraction to address complex or large problems. It looks
minimalist and fine only in a text book. But those "dumb students" must
become software engineers, some day...

> But once we get to the very same unsigned quantity or menory address
> defined in 5 different places by 5 different people who then at the last
> minute quickly made a kludge to be able to read each others data, then I
> say let types be damned. I need to get on with the job here. 

And? You will use some type for that anyway. What you describe, provided it
is indeed the *same* problem space entity, is lack of reuse. This can have
reasons as well, e.g. being a result of modular, separate design.

This is solvable without Unchecked_Conversion, e.g. by ad-hoc supertypes,
if Ada had them.

> But when
> the programmers just use types cause you need to use types cause the boss
> says so,

Really? I never saw such bosses. Usually a boss does not even know that
there are types.

> then the problem is not having this type or that type, then the
> problem is a lack of knowledge, clarity and elegance in the methods those
> programmers have been taught.

See above. You still believe that everything is int. This is a clarity and
elegance of machine code. Good luck with that!

> I posted an example the other day involving passing a string to printk.

As I said Ada lacks means for handle this. Just look at
[Wide_][Wide_]{Character|String} mess in ARM. This is a mess because there
is no way to sort it out. It must be the mess. Considering Wide_String and
String same type would not resolve that mess. You will still have to
convert one to another, because they are different entities in the *problem
space*. They are there, whether you wanted or not.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Sunday, May 31, 2015 at 10:52:03 AM UTC+2, Dmitry A. Kazakov wrote:

> 
> Yes, repeating the old saying - if C is a solution what was the problem?

Apparently writing a Linux Kernel?? (could not resist that one :)

> 
> As if social "science" could give answers.

I will tell my wife. 
To me they stumble and fall just like we do, but perhaps together we will gain a bit more knowledge.

> 
> Students aren't dumb, not as programmers are! (:-))

So then I am still a student that walks wide eyed into any crap. :)


> 
> That is strange because syntax is such a minor part and because in case of
> Ada it is very difficult (at least to me) to understand its BNF, because
> they tried to push precedence (and some other) rules into it.

That is one of the issues I tried to argue.

> Nothing lost,
> nothing gained. Some bad features added, but we are free not to use them.

I try just that and it has saved me from some more advanced stages of mental degradation. 


> what is wasted on so-called tool-chains.

Because complexity breeds toolchains. Or: mankind wants to be fooled so fool them.

> > But types hardly belong there.
> 
> They do. 

This is the main reason why I wanted to answer this post:
I tried to do some thinking while driving over the last few days. And I got the hint for what follows out of one of your old posts (I think) about having units of measurement as a type, etc.

I came to the conclusion that perhaps 2 things got confused over the years in the typing scheme:
1. structural equivalence. (i.e. a storage specification)
2. name equivalence. (as long as the type names are equivalent it will work)

These days we go for name equivalence and make new types or rename types to our hearts content. And so confuse things horribly for the person that tries to understand our code later, as I tried to indicate before.

The whole type system originated with structural equivalence. On which we can build some interesting tricks then. We can use the type structure to admit or not admit a variable to an algebraic algorithm, and if this record is equivalent to, or a subset of that record we can feed them to some procedure for processing. It is just an algebraic assurance that the calculation will be successful.

But the type system, as it has evolved over the years, has been overloaded with the name equivalence idea.

And this to me is important in this discussion: it has not succeeded in solving all our problems. Ada did not fully fulfil the Dod spec in this respect. Read the Steelman document. And you were complaining that you could not put any safeguards into your iso units software. And I just complain bitterly that at times that I do not see the wood for the trees when trying to interface Ada to the kernel.

So my solution would be to have, besides the "structural type" attribute to a variable, also a "what it is" or a "functional type" attribute to a variable.
(perhaps the "functional" word is a bit overloaded here, bit it will work for the purpose of the discussion)

The structural type is fine for the algebra and the storage.
The functional type would serve to help us with all the other issues we have.
Like naming the physical quality we deal with.
Like assuring that our formulas work out according to the International System of Units. And we dont multiply apples with apples, etc.
You name it, there is a wide field here.

And to put that into the symbol table parse tree of a compiler is trivial, it is just a copy more or less of the existing type tree. At least to my  understanding. But we will have to find the correct way of describing the operational interaction limitations of the different functional types we use.

In using the language we will now have a choice:
just use structural equivalence (what you blame me of :) or use the functional stuff as well. in order to build a secure program. 

In this way I would think that we will do away with a lot of 'unchecked conversions' which to my understanding were designed to fit a character onto an integer and the like. But at the moment 2 reasons for using them are confused: the perfectly legitimate ways (converting from one derived type to another) are mixed up with non-portable ways of use (fixing up the storage specification of a variable).

By the way I did look at your scanner and parser stuff, it is impressive. but I thought Sparre might perhaps be better served when he understands the very basics first, and perhaps it is enough for what he wants. Only he can judge.
 
> This is solvable without Unchecked_Conversion, e.g. by ad-hoc supertypes,
> if Ada had them.

Yes, I think what I described above would cater for that.

> 
> Really? I never saw such bosses. Usually a boss does not even know that
> there are types.

Ah, they made the salesman the boss, shame!

>  They are there, whether you wanted or not.

Yes, but not dreaming is deadly. So even if Ada might not see here way open to solve all this, perhaps her children might.

The Ada design basics are from 1977 - 1983. And today it is still very compatible, so what do we expect.  It is fantastic that it has stood up so long.

Read this if you want to get some perspective on the speed of development:

http://heerdebeer.org/ALGOL/The_History_of_ALGOL.pdf

cheers,

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Dmitry A. Kazakov]

On Thu, 4 Jun 2015 08:31:14 -0700 (PDT), jan.de.kruyf@gmail.com wrote:

> On Sunday, May 31, 2015 at 10:52:03 AM UTC+2, Dmitry A. Kazakov wrote:
> 
>> Yes, repeating the old saying - if C is a solution what was the problem?
> 
> Apparently writing a Linux Kernel?? (could not resist that one :)

Oh, that problem! They should have let it be... (:-)) 

>> As if social "science" could give answers.
> 
> I will tell my wife. 
> To me they stumble and fall just like we do, but perhaps together we will
> gain a bit more knowledge.

Yeah, so far answers social "science" ever gave, ultimately led to
brainwashing closely followed by concentration camps...

>> what is wasted on so-called tool-chains.
> 
> Because complexity breeds toolchains.

And the complexity is bred by mental laziness.

>>> But types hardly belong there.
>> 
>> They do. 
> 
> This is the main reason why I wanted to answer this post:
> I tried to do some thinking while driving over the last few days. And I
> got the hint for what follows out of one of your old posts (I think) about
> having units of measurement as a type, etc.
> 
> I came to the conclusion that perhaps 2 things got confused over the years
> in the typing scheme:
> 1. structural equivalence. (i.e. a storage specification)

?

Structural equivalence is an attempt to infer the behavior of an object
from its internal structure, or, more generally, from the way of its
construction. A mathematician would not even bother with that idea because
it clearly incomputable for anything beyond trivial. An engineer would tell
you that it is rubbish because it does not abstract the problem space. How
would you put the internal structure of the planet Mars to know if it were
a planet different from Earth?

> 2. name equivalence. (as long as the type names are equivalent it will work)

Nominal equivalence is when things are known to be equivalent a priory,
usually from the problem space, or per design.

> These days we go for name equivalence and make new types or rename types
> to our hearts content. And so confuse things horribly for the person that
> tries to understand our code later, as I tried to indicate before.

Sure, because he or she must share that a priory knowledge with you. If you
name something Pi, the reader must know trigonometry already. What puzzles
me, is why do you think that writing instead an infinite continued fraction
would be better to communicate Pi?

Pi is incomputable for humans as well. If all men were as silly as people
believing in structural types equivalence we would still be living in stone
age...
 
> The whole type system originated with structural equivalence.

Type systems appeared in mathematics after the disaster of naive set
theories.

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

> So my solution would be to have, besides the "structural type" attribute
> to a variable, also a "what it is" or a "functional type" attribute to a
> variable.

There is no "is". Neither in real world or in programming. Equivalence in
mathematics is just a binary relation of certain properties.

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

> Like assuring that our formulas work out according to the International
> System of Units. And we dont multiply apples with apples, etc.

Oh, but you do. Add diagonal of your monitor to the width of the button "A"
on the Logitech keyboard. The measurement unit is exactly same: [m].

> And to put that into the symbol table parse tree of a compiler is trivial,
> it is just a copy more or less of the existing type tree. At least to my 
> understanding. But we will have to find the correct way of describing the
> operational interaction limitations of the different functional types we
> use.

You cannot handle measurement units on the syntax level. It is useless for
most practical reasons. As an example consider writing a calculator dealing
with dimensioned values.
 
> In using the language we will now have a choice:
> just use structural equivalence (what you blame me of :) or use the
> functional stuff as well. in order to build a secure program. 

See the example above. Structural equivalence is fundamentally unsafe. It
is a well known fact any C programmer learns on his hide - the "structure"
of int is same even if one int is a file descriptor and another is the
Avogadro constant... Why don't you look into the standard output descriptor
when comparing 1 to 1? 

> In this way I would think that we will do away with a lot of 'unchecked
> conversions' which to my understanding were designed to fit a character
> onto an integer and the like.

We do it away by making conversions checked, but automated. What Ada really
lacks is subtyping beyond merely constrained instances.

>> This is solvable without Unchecked_Conversion, e.g. by ad-hoc supertypes,
>> if Ada had them.
> 
> Yes, I think what I described above would cater for that.

It would not, because the structures are evidently different. Here lies the
fundamental flaw of the idea. The difference and the similarity do not come
from the structure, they come from the problem space. The structures of
Character 'A' and Wide_Character 'A' are different. Yet the problem space
entity is exactly same. See?

A software architect would say that the structure is an implementation
detail, deserving no attention, never to be trusted at the client side.
Deducing anything about the program logic from structures is a *bug* on the
client's part.

> The Ada design basics are from 1977 - 1983. And today it is still very
> compatible, so what do we expect.  It is fantastic that it has stood up so
> long.

It is because nothing interesting happened since 1995. We are living
through the Dark Ages of computing...

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Shark8]

On Thursday, June 4, 2015 at 11:23:51 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> It is because nothing interesting happened since 1995. We are living
> through the Dark Ages of computing...

I blame the popularity of C/C++ and *nix.
Perhaps the best things to come out of the FP domain is (a) a more widespread disdain for C's fast/loose typing, (b) the realization that global state and side-effects can/should be avoided when possible, and (c) the realization that C language-family syntax is not indicative of "a real programming language".

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Nasser M. Abbasi]

On 6/4/2015 3:14 PM, Shark8 wrote:
> On Thursday, June 4, 2015 at 11:23:51 AM UTC-6, Dmitry A. Kazakov wrote:
>>
>> It is because nothing interesting happened since 1995. We are living
>> through the Dark Ages of computing...
>
> I blame the popularity of C/C++ and *nix.

In software, inertia is everything. Once something takes hold, it is
very hard to impossible to change it or replace it, due to the huge
inertia it has and the amount of investment made in it. For example,
almost all software games are in C/C++, it is almost impossible to make
the industry change this now.

> Perhaps the best things to come out of the FP domain is (a) a more widespread
>disdain for C's fast/loose typing,

Well, it seems most of the new and popular languages these days are
based on loose typing. Python? duck typing? Javascript? PHP? Perl? etc...

Who needs strong typing, when there is a good debugger?  :)

>(b) the realization that global state and side-effects can/should be
>avoided when possible, and (c) the realization that C language-family
>syntax is not indicative of "a real programming language".
>

--Nasser

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1066il1b5nk21.ioykgza5bnsw.dlg@40tude.net...
> On Sat, 30 May 2015 06:21:01 -0700 (PDT), jan.de.kruyf@gmail.com wrote:
...
>>> Few syntax problems Ada has come straight from Wirth himself. E.g.
>>> different syntax for declarations of subprogram types and values 
>>> (bodies)
>>> from other types and values. Wirth seems never cared much about types.
>>
>> Believe it or not he did, but he has never been known to be paranoid.
>
> He himself wrote as a title: Algorithms + Data Structures = Programs

Ah, yes, one of my old college textbooks. The professor of the class had 
never used it before, and we ended up spending lots of class-time trying to 
figure out how the algorithms should work. They were riddled with errors. 
Apparently, running the sample programs was a novel concept. (Dunno if those 
problems were fixed in a later edition, hopefully. I've heard from others 
that they thought the book was useful, so YMMV)

                           Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Monday, June 1, 2015 at 11:36:57 PM UTC+2, Randy Brukardt wrote:

> Ah, yes, one of my old college textbooks. The professor of the class had 
> never used it before, and we ended up spending lots of class-time trying to 
> figure out how the algorithms should work. They were riddled with errors. 
> Apparently, running the sample programs was a novel concept. (Dunno if those 
> problems were fixed in a later edition, hopefully. I've heard from others 
> that they thought the book was useful, so YMMV)
> 
>                            Randy.

Randy, you are confusing Stone Age with post-modernity again ;>
From you writing I gather that that must have been shortly after the ALGOL age as described in the HeerdeBeer thesis above.
I was trying my hand at basic at the time, so perhaps we all came a long way since then.

cheers and keep smiling

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Tuesday, May 26, 2015 at 9:52:39 AM UTC+2, Jacob Sparre Andersen wrote:

> And how well would a team of student manage John McCormick's train
> modeling course with each language?  (I think McCormick is still
> teaching?  Can we get him to run that experiment?)
> 

Half the experiment is done already. I forgot a bit. Since at the time I was not into motion control so much.

http://www.ifr.mavt.ethz.ch/research/xoberon/

http://www.ifr.mavt.ethz.ch/research/xoberon/performance.html.

A hexaglide is a 6 axes single head motion configuration that can be used as a milling machine for instance. Various universities have made many promises about it. But the market is slow.

And there is an evening of free beer for those who can beat these performance figures on an stm32f7xx. in Ada. 
There should be little difference in raw speed. At the most the 604 is 1.5 times as fast but not as measured inside an Apple, Then the are about equal.

I will see if I can twist an arm for the software. So far I only saw the package spec files of the system.

Otherwise I am unfortunately still a bit overloaded at the moment

cheers,

j.
 

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Peter Chapin]

On Mon, 25 May 2015, Nasser M. Abbasi wrote:

> I forgot Fortran. Here is the list again
>
> C++      : 1366 pages
> Ada      : 944  pages
> Fortran  : 675  pages
> C        : 552  pages
> Pascal   : 98   pages

The size of the reference manual may (probably) says something about the 
complexity of the language, but I'm not sure what. It may also say 
something about the care with which the description was written. Many 
specifications are incomplete to one degree or another. Fully specifying 
all the fine details of even a simple language is likely to result in a 
longish reference manual. Fully specifying all the fine details of a 
complex language is likely to result in an enormous reference manual. 
That's only natural.

Another point to keep in mind is that the size of the reference manuals 
above include, at least in most cases, information about the associated 
standard libraries. A simple language with a huge library will have a 
large manual. A language reference without any information about the 
library will, of course, be much smaller.

I haven't read the Oberon Report but I can't help but wonder if it's 
leaving out a lot.

Peter

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Sylvain Laperche]

On 2015-05-25, Peter Chapin <PChapin@vtc.vsc.edu> wrote:
> I haven't read the Oberon Report but I can't help but wonder if it's
> leaving out a lot.

For a simple exemple: what happen when an integer overflow?
- The program aborts?
- The value silently wrap-around (2-complement behavior)?
- Is it an undefined behavior (like in C)?

Another one: what happens when there is an access out of the bounds of an array?
A crash? A runtime check? undefined behavior (like C)?

I did not find the answer in these 17 pages.
It seems that it leaving out a lot indeed…

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 26.05.15 10:01, Sylvain Laperche wrote:
> Another one: what happens when there is an access out of the bounds of an array?
> A crash? A runtime check? undefined behavior (like C)?

An answer might be in a suggestion to look at what your implementation
happens to support. Vishap Oberon-2:

  r      - check value ranges
  x      - turn off array indices check

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[J-P. Rosen]

Le 26/05/2015 10:01, Sylvain Laperche a écrit :
> On 2015-05-25, Peter Chapin <PChapin@vtc.vsc.edu> wrote:
>> I haven't read the Oberon Report but I can't help but wonder if
>> it's leaving out a lot.
> 
> For a simple exemple: what happen when an integer overflow? - The
> program aborts? - The value silently wrap-around (2-complement
> behavior)? - Is it an undefined behavior (like in C)?
> 
> Another one: what happens when there is an access out of the bounds
> of an array? A crash? A runtime check? undefined behavior (like C)?
> 
> I did not find the answer in these 17 pages. It seems that it leaving
> out a lot indeed…
> 
I also downloaded the Oberon report and had a look at it (easy, only 17
pages). I'd say it is not to be compared with anything close to a
standard. It's just a "report" that gives a vague idea of the language
without addressing any serious issue. TBH, it claims that its fuzzy
definitions are intended:

"What remains unsaid is mostly left so intentionally, either because it
is derivable from stated rules of the language, or because it would
unnecessarily restrict the freedom of implementors."

Translate: we don't care for portability.

Another good one: Oberon's definition of a static expression:
"A constant expression can be evaluated by a mere textual scan without
actually executing the program."

And the list of missing features is stunning, just some of them:
No user defined integer types (only two integer types: BYTE and INTEGER,
and they are /not/ incompatible), no enumeration types, no fixed points,
arrays indexed from 0, no variant records, no exceptions, no tasking, no
generics, no representation clauses, structural equivalence for array
parameters, no user defined operators, no overloading, no overriding, etc...

Looks more like a slightly improved Pascal appropriate for teaching than
an industrial language.

In short: if you miss most important features, and have only weak
definitions for the rest, it is easy to have a small reference manual!
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Clubley]

On 2015-05-26, J-P. Rosen <rosen@adalog.fr> wrote:
>
> "What remains unsaid is mostly left so intentionally, either because it
> is derivable from stated rules of the language, or because it would
> unnecessarily restrict the freedom of implementors."
>
> Translate: we don't care for portability.
>

The latter bit made me uneasy as well.

> Another good one: Oberon's definition of a static expression:
> "A constant expression can be evaluated by a mere textual scan without
> actually executing the program."
>
> And the list of missing features is stunning, just some of them:
> No user defined integer types (only two integer types: BYTE and INTEGER,
> and they are /not/ incompatible), no enumeration types, no fixed points,
> arrays indexed from 0, no variant records, no exceptions, no tasking, no
> generics, no representation clauses, structural equivalence for array
> parameters, no user defined operators, no overloading, no overriding, etc...
>

Be careful you don't turn Oberon into another Ada with slightly different
syntax. While Oberon is too minimal, there is real potential for a
easy to learn lightweight language which is safer than C and which can be
used for all the things C is currently used for.

When I was thinking about the possibility of a half-way language between
C and Ada (I was thinking about something safer than C which wasn't as
heavyweight as Ada) the above was the list of things I came up with
which was missing from Oberon.

I would have certainly added things like user defined integer types
with ranges, enumeration types and a user definable array base index.
(Basically the core low level features of Ada).

I would not have added tasking or generics (this was a C language
replacement). Given potential implementation issues (code written in
this Oberon variant would have to interact with other languages),
I wasn't sure about exceptions. Maybe local exceptions only.

I was undecided about how strict to make the type conversion as well.
I would never have tolerated silent conversions which cause data loss
(integer to byte for example) but I was undecided about how strict to
make things when going in the other direction.

Given the goal in this theoretical exercise was to create a language to
attract C programmers I was wondering how much the type system could be
relaxed without compromising safety too much. (The language doesn't have
to be as safe as Ada, it just has to be a lot better than C.)

In addition, I would also have added syntax to implement atomic updating
of partial aggregates as per my proposal which was turned into an AI
(ai12-0127). This would allow you to get rid of C style bitmasks when
updating device registers.

I would also have dropped Oberon's case sensitivity or at least made
the keywords lower case.

I/O would be via an I/O library, not as part of the language.

> Looks more like a slightly improved Pascal appropriate for teaching than
> an industrial language.
>

But with the correct amendments, there's potential for growth just as
happened with Pascal.

Simon.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[J-P. Rosen]

Le 26/05/2015 14:36, Simon Clubley a écrit :
> When I was thinking about the possibility of a half-way language between
> C and Ada (I was thinking about something safer than C which wasn't as
> heavyweight as Ada) the above was the list of things I came up with
> which was missing from Oberon.
(my collection of features was just to stress that the "17 pages" didn't
mean a simpler language, only an incomplete an mostly undefined language
- which reminds me of another good one: BYTE is compatible (both ways)
with INTEGER, but there isn't a single word to tell what happens when
you convert to BYTE a value outside 0..255)

Now to your point. I've seen people wanting a "simpler Ada" ever since I
attended the first presentation of the language by JDI in 1979...
But things rapidly get tied together. You want user defined integer
types, and no magic for IOs? Then you'll need packages and generics.
Safe IOs also require exceptions. And you certainly want aggregates,
because they are sooo convenient.

The only things that could be detached are tasking and OOP. Of course
not having the latter would be highly politically incorrect, which
leaves us only with tasking. And this is not the hardest part to implement.

(Note on the examples I took: in a previous life, I worked on an Ada83
compiler. It took me much more time to implement code generation for
array aggregates than the whole design and implementation of the tasking
system).

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Dmitry A. Kazakov]

On Tue, 26 May 2015 15:39:06 +0200, J-P. Rosen wrote:

> You want user defined integer
> types, and no magic for IOs? Then you'll need packages

Yes, but unrelated to user-defined types. Packages are for modularity and
separate compilation. Wirth's languages are notably weak in that respect.

> and generics.

No. Classes can be obtained without generics. It is static vs. dynamic
polymorphism.

> Safe IOs also require exceptions. And you certainly want aggregates,
> because they are sooo convenient.

Aggregates could be primitive subprograms. The syntax sugar of aggregates
could be made open for user definitions.

> The only things that could be detached are tasking and OOP.

None of them could, and Ada's unsuccessful attempts perfectly illustrate
that.

> Of course
> not having the latter would be highly politically incorrect,

It has nothing to do with PC in any sense. If the language should support
generic programming, there is no alternative to run-time classes. Generics
are not a substitute because they do not prove named typed class-wide
objects. They are simply untyped.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Shark8]

On Tuesday, May 26, 2015 at 7:39:08 AM UTC-6, J-P. Rosen wrote:
> 
> (Note on the examples I took: in a previous life, I worked on an Ada83
> compiler. It took me much more time to implement code generation for
> array aggregates than the whole design and implementation of the tasking
> system).

That is amazing -- I never would have guessed that array aggregates would be more difficult than the entire tasking system.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[J-P. Rosen]

Le 26/05/2015 18:19, Shark8 a écrit :
> On Tuesday, May 26, 2015 at 7:39:08 AM UTC-6, J-P. Rosen wrote:
>>
>> (Note on the examples I took: in a previous life, I worked on an Ada83
>> compiler. It took me much more time to implement code generation for
>> array aggregates than the whole design and implementation of the tasking
>> system).
> 
> That is amazing -- I never would have guessed that array aggregates would be more difficult than the entire tasking system.
> 
Yes. The order of evaluation of ranges and components, and the rule
about empty arrays not raising Constraint_Error, makes any naive
evaluation order wrong. And the order of evaluation is not the same for
a bidimensional array and an array of arrays that have the same aggregate!

Note: I mentionned it was Ada83. IIRC, things have been a bit relaxed
since - quite a long time I didn't look into it.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Jeffrey R. Carter]

On 05/26/2015 01:49 AM, J-P. Rosen wrote:
>>
> I also downloaded the Oberon report and had a look at it (easy, only 17
> pages). I'd say it is not to be compared with anything close to a
> standard. It's just a "report" that gives a vague idea of the language
> without addressing any serious issue. TBH, it claims that its fuzzy
> definitions are intended:
> 
> "What remains unsaid is mostly left so intentionally, either because it
> is derivable from stated rules of the language, or because it would
> unnecessarily restrict the freedom of implementors."
> 
> Translate: we don't care for portability.

That was my reaction to that sentence as well. Of course, the ARM has some of
those, as well. There's no reason Integer couldn't be defined as

type Integer is range -(2 ** 15) + 1 .. (2 ** 15) - 1;

rather than being implementation defined with at least that range. That would
enhance portability and decrease overuse of the predefined type.

> And the list of missing features is stunning, just some of them:
> No user defined integer types (only two integer types: BYTE and INTEGER,
> and they are /not/ incompatible), no enumeration types, no fixed points,
> arrays indexed from 0, no variant records, no exceptions, no tasking, no
> generics, no representation clauses, structural equivalence for array
> parameters, no user defined operators, no overloading, no overriding, etc...
> 
> Looks more like a slightly improved Pascal appropriate for teaching than
> an industrial language.

Those are differences between Ada and Oberon. Whether they're "missing" from
Oberon is a matter of opinion; clearly jan.de.kruyf@gmail.com doesn't think so.

As to being "a slightly improved Pascal", having modules and terminators for
compound statements is an improvement, but Pascal had enumeration types and
array ranges with differing low bounds, and lacking those is going in the wrong
direction IMO, so the overall improvement seems pretty close to nil.

Anyway, if you took the ARM, got rid of all the things Oberon doesn't have,
eliminated the precision of the definitions and any "unnecessary" verbiage,
you'd probably end up close to Oberon's 17 pp.

-- 
Jeff Carter
"What's special about Agile is that it's a mix of the
best and the worst."
Bertrand Meyer
148

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:mk29dv$l47$2@dont-email.me...
...
> Anyway, if you took the ARM, got rid of all the things Oberon doesn't 
> have,
> eliminated the precision of the definitions and any "unnecessary" 
> verbiage,
> you'd probably end up close to Oberon's 17 pp.

I think you could leave in most of the Ada features and still describe them 
with that level of precision. The one sentence that J-P quoted could replace 
the entirety of 4.9-4.9.1(5 pages). One probably could come up with a 
similar description of visibility, replacing the majority of Chapter 8 (16 
pages). Shrink the fonts, eliminate the white-space, and voila! About 17 
pages.

Ergo, the whole discussion is silly. Which is probably why we're having it. 
:-)

                        Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

I wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
> news:mk29dv$l47$2@dont-email.me...
> ...
>> Anyway, if you took the ARM, got rid of all the things Oberon doesn't 
>> have,
>> eliminated the precision of the definitions and any "unnecessary" 
>> verbiage,
>> you'd probably end up close to Oberon's 17 pp.
>
> I think you could leave in most of the Ada features and still describe 
> them with that level of precision. The one sentence that J-P quoted could 
> replace the entirety of 4.9-4.9.1(5 pages). One probably could come up 
> with a similar description of visibility, replacing the majority of 
> Chapter 8 (16 pages). Shrink the fonts, eliminate the white-space, and 
> voila! About 17 pages.

Besides, no one said anything about the page size. If we use coffee-table 
art book page sizes, and 6 point type, we can probably get the entire core 
RM in 17 pages without changes. ;-)

> Ergo, the whole discussion is silly. Which is probably why we're having 
> it. :-)

I couldn't have said it better myself. :-) :-)

                                Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Jeffrey R. Carter]

On 05/29/2015 02:54 PM, Randy Brukardt wrote:
> 
> Besides, no one said anything about the page size. If we use coffee-table 
> art book page sizes, and 6 point type, we can probably get the entire core 
> RM in 17 pages without changes. ;-)

The PDF of the Oberon report linked to earlier in this thread used what looked
like A4 pages with what appeared to be a 12-pt font, so let's use what that PDF
used as the requirement for page and font size.

-- 
Jeff Carter
"Drown in a vat of whiskey. Death, where is thy sting?"
Never Give a Sucker an Even Break
106

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 26.05.15 01:05, Peter Chapin wrote:
> On Mon, 25 May 2015, Nasser M. Abbasi wrote:
>
>> I forgot Fortran. Here is the list again
>>
>> C++      : 1366 pages
>> Ada      : 944  pages
>> Fortran  : 675  pages
>> C        : 552  pages
>> Pascal   : 98   pages
>
> The size of the reference manual may (probably) says something about the complexity of the language, but I'm not sure what. It may also say something about the care with which the description was written. Many specifications are incomplete to one degree or another. Fully specifying all the fine details of even a simple language is likely to result in a longish reference manual. Fully specifying all the fine details of a complex language is likely to result in an enormous reference manual. That's only natural.

Additionally, Ada, like others on this list, would be developed
with backwards compatibility in mind. Wirth seems to have approached
the matter differently.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

<jan.de.kruyf@gmail.com> wrote in message 
news:ac78c8c6-de94-4f92-afcb-c1ae78523245@googlegroups.com...
...
> And statistics prove that point. I have written 1000th's of lines in 
> Oberon and
> 1000th's of lines in Ada. Both highly technical software.
>And I got exactly the same kind of errors on compiling and running: errors 
>caused
> by my sloppy habits. And both the Oberon compiler that fits on a floppy (a 
> floppy,
> not a stiffy) and Gcc which stands at over 1Gig of source in the latest
> implementation, caught them equally well and also the runtime errors that 
> I caused
> were exactly the same.

Uh-huh. Janus/Ada 83 fit on and ran on floppies. (Heck, there wasn't 
anything else available on early MS-DOS.) Even the relatively tiny 5 1/4" 
floppies. It still would if you could find a machine that has floppies. The 
bloat is in GCC, not necessarily in Ada.

The bloat in the Standard (such as it is) came from adding lots of stuff 
that people thought was necessary (but argubly isn't): tagged types and 
dispatching, interfaces, prefix calls, assertions, and (especially) 
containers.

>So please explain to me why on earth I or DoD or ISO or anybody else needs 
>all the bloat to confuse us.

We don't. As with all old languages, it's political. We can't remove old 
features (as that would break existing programs), so the only possibility is 
for the Standard to get bigger. It's also getting bigger because we've (me 
in particular) have been insisting on adding wording to fill holes, rather 
than just ignoring them. Based on my experience, I think a language standard 
with 17 pages is about 90% hole (unless, of course, the language doesn't 
actually do anything).

I'd think it's getting close to time to start over with Ada, not because of 
any major problem, but simply the accumulation of cruft. The problem is that 
if you think its hard to convince people to use Ada with all of its track 
record, try doing that with a new language with no record. So I don't think 
there would be much of a market for that.

                        Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Nasser M. Abbasi]

On 5/28/2015 5:46 PM, Randy Brukardt wrote:

> The problem is that
> if you think its hard to convince people to use Ada with all of its track
> record, try doing that with a new language with no record. So I don't think
> there would be much of a market for that.

If you mean it is hard to get people to get interested in
new language with no record, then how can one explain the
sudden popularity of many new languages such as swift, C# and
others like them when they first appeared?

They became popular from first day. Swift now is ranked 18 now
on http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
and it was released by Apple, what, less than one year ago?

http://en.wikipedia.org/wiki/Swift_%28programming_language%29

More are using Swift now than Ada. And Swift has no track record
to speak of. But of course, it is from Apple, so this explains
all of this popularity. May be if Apple releases an Ada version for
the iPhone, call it "iAda" with GUI build in to make apps, then Ada
would become popular overnight :)

--Nasser

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

"Nasser M. Abbasi" <nma@12000.org> wrote in message 
news:mk87oj$hle$1@speranza.aioe.org...
> On 5/28/2015 5:46 PM, Randy Brukardt wrote:
>
>> The problem is that
>> if you think its hard to convince people to use Ada with all of its track
>> record, try doing that with a new language with no record. So I don't 
>> think
>> there would be much of a market for that.
>
> If you mean it is hard to get people to get interested in
> new language with no record, then how can one explain the
> sudden popularity of many new languages such as swift, C# and
> others like them when they first appeared?

You answer your own question below: it's the sponsor, not the language that 
matters. That's even true for Ada; something like it would have never gotten 
off the ground without the DoD support.

> They became popular from first day. Swift now is ranked 18 now
> on http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> and it was released by Apple, what, less than one year ago?
>
> http://en.wikipedia.org/wiki/Swift_%28programming_language%29
>
> More are using Swift now than Ada. And Swift has no track record
> to speak of. But of course, it is from Apple, so this explains
> all of this popularity. May be if Apple releases an Ada version for
> the iPhone, call it "iAda" with GUI build in to make apps, then Ada
> would become popular overnight :)

Certainly.

                                   Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 29, 2015 at 12:46:28 AM UTC+2, Randy Brukardt wrote:


> than just ignoring them. Based on my experience, I think a language standard 
> with 17 pages is about 90% hole (unless, of course, the language doesn't 
> actually do anything).

Yes, the 17 pages say that things have been left unsaid, but the compiler stopped any adventures.
Perhaps it was assumed known in those days, at least in Zurich, that you do the job properly or not at all? 

> 
> I'd think it's getting close to time to start over with Ada, not because of 
> any major problem, but simply the accumulation of cruft. The problem is that 
> if you think its hard to convince people to use Ada with all of its track 
> record, try doing that with a new language with no record. So I don't think 
> there would be much of a market for that.
> 
>                         Randy.

Yes . . . and then No.

A telling sign is that Ada has not forked yet. That is either a sign of the great wisdom of the Ada high priests, or it does not evoke dreams . . .

I would say that we could do with a 100 or 200 page "Ada language report" for the kids that have not learned how to read in this modern age.

Otherwise I like to observe that a 'language X' program from the nineties normally does not compile anymore on Gcc. You have to fix the changes in technology first; and please spare me the reasons why, I know about it. But Also in Ada ways of doing things change slowly over time.
So I'd say that we could have a compiler switch if needed once the cruft has been identified (new laguage war. . . )


Two practical observations worth their own thread perhaps:
In the thread about the shortest path through a task Simon came up with some number for interrupt latency in Ravenscar that horrifies me. Surely the object of the exercise of having interrupts at all is defeated by now, At least in my application. (High speed motion control)
--


In the example kernel module in the pegasoft book Ken does the following:

------------------------
-- Kernel Calls

  procedure Printk( s : string );
  pragma import( C, printk, "printk" );
.
.
Printk("Hello,World!" & Character'val(10) & character'val(0));
.
.
-------------------------

This is off course a highly irreligious way of doing things.
So I set out to do it the proper way via Interfaces.C and what,what.

In the end after many lines of converting Ada string to C string, I could only point out to myself that at least I now had unchecked conversions and System.Addresses.

So then, how do I assign a value to these observations, what is the lesson to be applied next time over?

cheers,

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> In the thread about the shortest path through a task Simon came up
> with some number for interrupt latency in Ravenscar that horrifies
> me. Surely the object of the exercise of having interrupts at all is
> defeated by now, At least in my application. (High speed motion
> control)

To me, 6 us didn't seem too bad. You have to pay for using high-level
constructs (high-ish, in the case of Ravenscar, of course).

But then, I remember the manual-guide-torpedo-by-wire system where the
team were pleased they'd got the feedback loop time (move joystick to
response from torpedo on screen) down from 50 s to 15 s. When asked
whether he found it a problem, the CPO said that submariners are used to
taking things slowly :-)

I should add, the RTS that I timed is based on FreeRTOS. Guess I should
do the same timing with AdaCore's RTS.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 29, 2015 at 11:27:54 AM UTC+2, Simon Wright wrote:

> To me, 6 us didn't seem too bad. You have to pay for using high-level
> constructs (high-ish, in the case of Ravenscar, of course).

Perhaps it was one of my notorious impercise expressions. I should have said "instructions" or may be "cpu cycles"
> 
> But then, I remember the manual-guide-torpedo-by-wire system where the
> team were pleased they'd got the feedback loop time (move joystick to
> response from torpedo on screen) down from 50 s to 15 s. When asked
> whether he found it a problem, the CPO said that submariners are used to
> taking things slowly :-)

In my previous life I was an officer at sea. I once stood for about 3 or 4 minutes waiting patiently for a big crash that could not be avoided anymore.
We fully knew the magnitude of the error, but the PID output was limiting, so to speak.

> 
> I should add, the RTS that I timed is based on FreeRTOS. Guess I should
> do the same timing with AdaCore's RTS.

Perhaps, but you will also find things.
Here it is not a matter of having a bigger amplifier. I have to accept that technology that works well in a washing machine, is too slow for a high speed set-up. And I will have to adapt the basic premises of my technology.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[G.B.]

On 29.05.15 12:23, jan.de.kruyf@gmail.com wrote:
> I have to accept that technology that works well in a washing machine, is too slow for a high speed set-up.

Nitpick: todays better washing machines would need to
respond quickly to unbalance.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

> > I have to accept that technology that works well in a washing machine, is too slow for a high speed set-up.
> 
> Nitpick: todays better washing machines would need to
> respond quickly to unbalance.

specially when the shocks are worn.
I dont think though that our Miele goes much beyond 20 or maybe 10 msec cycletime. From watching it doing its thing.

I was merely referring to the micro controller and its common programming environment.
As soon as you want to go below say 2 or 3 milliseconds control loop cycle time  everything changes, whatever language you use. Unless you throw money at it and go for a high speed cpu.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> I should add, the RTS that I timed is based on FreeRTOS. Guess I
> should do the same timing with AdaCore's RTS.

OK: same setup (at least as far as this exercise is concerned), compiled
with -O2: 890 cycles, 5 us (on the 180 MHz STM32F429I-DISCO).

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 29, 2015 at 5:32:13 PM UTC+2, Simon Wright wrote:

> 
> > I should add, the RTS that I timed is based on FreeRTOS. Guess I
> > should do the same timing with AdaCore's RTS.
> 
> OK: same setup (at least as far as this exercise is concerned), compiled
> with -O2: 890 cycles, 5 us (on the 180 MHz STM32F429I-DISCO).

Thank you Simon.
So on a 407 it will be like 5.6 usecs.

So we must not assume, but rather measure.

Have a nice weekend.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> We don't. As with all old languages, it's political. We can't remove
> old features (as that would break existing programs),

But aren't the existing programs being compiled with compilers for the
appropriate (old) versions of the language?

How large is the actual benefit of maintaining practically full
backwards compatibility?

Isn't it more a matter of not being able to agree on what is important
to keep, and what isn't?

> I'd think it's getting close to time to start over with Ada, not
> because of any major problem, but simply the accumulation of
> cruft. The problem is that if you think its hard to convince people to
> use Ada with all of its track record, try doing that with a new
> language with no record. So I don't think there would be much of a
> market for that.

Isn't that in itself an argument for letting Ada 2020 be a major change,
where backwards compatibility isn't as important as using our current
knowledge to improve the language?  I wouldn't want an Ada 2012 program
to be accepted by an Ada 2020 compiler with a different meaning, but I
wouldn't mind it if the Ada 2020 compiler told me that I have to do
things differently in Ada 2020.

Greetings,

Jacob
-- 
"It is very easy to get ridiculously confused about the
 tenses of time travel, but most things can be resolved
 by a sufficiently large ego."

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 29, 2015 at 11:31:33 AM UTC+2, Jacob Sparre Andersen wrote:
> Randy Brukardt wrote:
> 
> > We don't. As with all old languages, it's political. We can't remove
> > old features (as that would break existing programs),
> 
> But aren't the existing programs being compiled with compilers for the
> appropriate (old) versions of the language?
> 
> How large is the actual benefit of maintaining practically full
> backwards compatibility?
> 
> Isn't it more a matter of not being able to agree on what is important
> to keep, and what isn't?
> 
> > I'd think it's getting close to time to start over with Ada, not
> > because of any major problem, but simply the accumulation of
> > cruft. The problem is that if you think its hard to convince people to
> > use Ada with all of its track record, try doing that with a new
> > language with no record. So I don't think there would be much of a
> > market for that.
> 
> Isn't that in itself an argument for letting Ada 2020 be a major change,
> where backwards compatibility isn't as important as using our current
> knowledge to improve the language?  I wouldn't want an Ada 2012 program
> to be accepted by an Ada 2020 compiler with a different meaning, but I
> wouldn't mind it if the Ada 2020 compiler told me that I have to do
> things differently in Ada 2020.
> 
> Greetings,
> 
> Jacob
> -- 
> "It is very easy to get ridiculously confused about the
>  tenses of time travel, but most things can be resolved
>  by a sufficiently large ego."


Let me try to put in my 2 cents here:
A while back I was asked to solve an issue on a 486 board, which you will still find in older industrial machines here.
So first things first: do a full memory test.
And there I was stuck for a full week trying to find / construct a stiffy that would boot and have a working memtest.
I remember that I pulled out a very old gcc to re-compile the memtest source.
Although gcc is supposedly fully backward compatible.
I there had been a concious decision to change, and documemt the change, it would have been easy. But by trying to stay backward compatible a booboo slipped through.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Björn Lundin]

On 2015-05-29 11:31, Jacob Sparre Andersen wrote:
> Randy Brukardt wrote:
> 
>> We don't. As with all old languages, it's political. We can't remove
>> old features (as that would break existing programs),
> 
> But aren't the existing programs being compiled with compilers for the
> appropriate (old) versions of the language?

Not necessarily.
Our system often has a life expectancy of 15 +- 5 years.
But the os/database/other tools does not.
Once say Oracle say - no support available - which they do relatively
fast - most customers wants a platform upgrade .
That is - make the same system run on a newer os/db/whatever.

And that includes a new Ada compiler.
Ans one really nice thing about Ada is that is usually
compiles and works right away.
If compiler-vendor-change took place, some fiddling is usually present,
but upgrading a system from one gnat to another is painless.

You get tons of more warnings - and that is it.

Another scenario is when a customer wants some 'newer' technology,
like webbish stuff.
To add AWS a relatively new compiler is needed.
And that should compile that rest of the system too - even if old.

> 
> How large is the actual benefit of maintaining practically full
> backwards compatibility?
> 

To us - very large.


> Isn't it more a matter of not being able to agree on what is important
> to keep, and what isn't?

If you ask around enough, you will likely get
answers that wants to keep 'odd' features.
I - for example - love the separate construct. we use it allot.
But I think not too many use it.


--
Björn

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Peter Chapin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 520 bytes --]

On Fri, 29 May 2015, Björn Lundin wrote:

> If you ask around enough, you will likely get answers that wants to keep 
> 'odd' features. I - for example - love the separate construct. we use it 
> a lot. But I think not too many use it.

I also like using subunits now and then. It seems like a good fit when I 
have a package with one unusually large subprogram that dominates the 
package's physical content, but is just not important enough, or logically 
distinct enough, to make into its own unit.

Peter

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Shark8]

On Friday, May 29, 2015 at 6:03:12 AM UTC-6, Peter Chapin wrote:
> On Fri, 29 May 2015, Björn Lundin wrote:
> 
> > If you ask around enough, you will likely get answers that wants to keep 
> > 'odd' features. I - for example - love the separate construct. we use it 
> > a lot. But I think not too many use it.
> 
> I also like using subunits now and then. It seems like a good fit when I 
> have a package with one unusually large subprogram that dominates the 
> package's physical content, but is just not important enough, or logically 
> distinct enough, to make into its own unit.
> 
> Peter

I find that happens in parsing; especially unserialization.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Shark8]

On Friday, May 29, 2015 at 3:31:33 AM UTC-6, Jacob Sparre Andersen wrote:
> 
> Isn't that in itself an argument for letting Ada 2020 be a major change,
> where backwards compatibility isn't as important as using our current
> knowledge to improve the language?  I wouldn't want an Ada 2012 program
> to be accepted by an Ada 2020 compiler with a different meaning, but I
> wouldn't mind it if the Ada 2020 compiler told me that I have to do
> things differently in Ada 2020.


If we accept a breaking change, then we could clean up the [[Wide_]Wide_]Character and [[Wide_]Wide_]Strings.  -- Randy had an interesting idea about that a while back (I forget the details though).

If we went with a sort of "abstract type" idea we could we could simplify the Character/String-packages in the standard library. It might also give us a chance to look at allowing User-defined attributes... though that might be a bad idea (I like being able to look any particular attribute up in the standard

Another thing that would be nice is a way to initialize containers in-source w/o functions -- but overloading the aggregates more than they already are to handle that might be far too much effort for the comparatively little gain. Also, a way to refer to indices when in an array-aggrigare would be nice; Ex: I:Array(1..4,1..4) of Integer := (others => (if I'Index(1) = I'Index(2) then 1 else 0));

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:288e200f-8379-45b3-8eb7-342564c920ef@googlegroups.com...
On Friday, May 29, 2015 at 3:31:33 AM UTC-6, Jacob Sparre Andersen wrote:
...
> Also, a way to refer to indices when in an array-aggrigare would be nice;
> Ex: I:Array(1..4,1..4) of Integer := (others => (if I'Index(1) = 
> I'Index(2) then 1 else 0));

See AI12-0061-1. It was considered too big a change to put into the 
Corrigendum, else you'd already have it. The original proposal was part of 
Ada 9x, but it was one of many "nice-to-haves" that got dropped in the 
"scope reduction". And we didn't think of it again until it came here in 
2013 (causing Adam to formally propose it on Ada-Comment).

                                                Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Shark8]

On Friday, May 29, 2015 at 3:36:15 PM UTC-6, Randy Brukardt wrote:
> "Shark8" wrote in message 
> news:288e200f-8379-45b3-8eb7-342564c920ef...
> On Friday, May 29, 2015 at 3:31:33 AM UTC-6, Jacob Sparre Andersen wrote:
> ...
> > Also, a way to refer to indices when in an array-aggrigare would be nice;
> > Ex: I:Array(1..4,1..4) of Integer := (others => (if I'Index(1) = 
> > I'Index(2) then 1 else 0));
> 
> See AI12-0061-1. It was considered too big a change to put into the 
> Corrigendum, else you'd already have it. The original proposal was part of 
> Ada 9x, but it was one of many "nice-to-haves" that got dropped in the 
> "scope reduction". And we didn't think of it again until it came here in 
> 2013 (causing Adam to formally propose it on Ada-Comment).
> 
>                                                 Randy.

Nice!
I did not know about that one.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87a8wnu3v0.fsf@adaheads.sparre-andersen.dk...
> Randy Brukardt wrote:
>
>> We don't. As with all old languages, it's political. We can't remove
>> old features (as that would break existing programs),
>
> But aren't the existing programs being compiled with compilers for the
> appropriate (old) versions of the language?

Until they need some part upgraded. For example, I'm (slowly) moving my web 
and mail servers from Janus/Ada on a W2K machine to GNAT on a new Linux 
machine. It's likely that I'll want/need to use some new capabilities when 
that's done. Changing lots of code because someone didn't like some existing 
feature is unappealing.

Similarly, I know that pretty much any Ada code that I have will still work 
if I need it in some program. Reuse is a valuable benefit of Ada, and that 
cuts across time as well as projects.

> How large is the actual benefit of maintaining practically full
> backwards compatibility?

It's hard to say. Some people (Robert Dewar in particular) think we abandon 
compatibility far too easily in the ARG as it is. And we don't do that 
lightly as it is. He claims that compatibility issues discouraged many from 
using Ada 2005; the aspects and preconditions in Ada 2012 were enough to 
break through that barrier, but it would be easy for Ada 202y to fall into a 
similar trap (not enough important to make up for incompatibilities).

> Isn't it more a matter of not being able to agree on what is important
> to keep, and what isn't?

No. There definitely is a group that think that almost any incompatibility 
is unacceptable. And someone is using every core feature (even stuff like 
generic formal in out parameters); how do you decide who's code is not 
important enough to support.

>> I'd think it's getting close to time to start over with Ada, not
>> because of any major problem, but simply the accumulation of
>> cruft. The problem is that if you think its hard to convince people to
>> use Ada with all of its track record, try doing that with a new
>> language with no record. So I don't think there would be much of a
>> market for that.
>
> Isn't that in itself an argument for letting Ada 2020 be a major change,
> where backwards compatibility isn't as important as using our current
> knowledge to improve the language?  I wouldn't want an Ada 2012 program
> to be accepted by an Ada 2020 compiler with a different meaning, but I
> wouldn't mind it if the Ada 2020 compiler told me that I have to do
> things differently in Ada 2020.

Sure, it's an argument. But what's typically happened when languages made 
big breaks is that the new version is much less used than the original. That 
goes all the way back to Algol 60 vs. Algol 68. I doubt Ada could survive a 
much less used version.

                                           Randy.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Peter Chapin]

On Fri, 29 May 2015, Randy Brukardt wrote:

>> Isn't that in itself an argument for letting Ada 2020 be a major 
>> change, where backwards compatibility isn't as important as using our 
>> current knowledge to improve the language?  I wouldn't want an Ada 2012 
>> program to be accepted by an Ada 2020 compiler with a different 
>> meaning, but I wouldn't mind it if the Ada 2020 compiler told me that I 
>> have to do things differently in Ada 2020.
>
> Sure, it's an argument. But what's typically happened when languages 
> made big breaks is that the new version is much less used than the 
> original. That goes all the way back to Algol 60 vs. Algol 68. I doubt 
> Ada could survive a much less used version.

I'd hold up Python as an example of how things don't work well when you 
make too many breaking changes. Python 3 is incompatible with Python 2, 
yet after 6.5 years there are still (many? most?) projects out there that 
require Python 2. I don't follow the Python community that closely but my 
impression is that the plan to entice everyone over to Python 3 failed. 
Now they are stuck with maintaining two incompatible versions of the 
language into the arbitrary future.

Peter

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Georg Bauhaus]

On 30.05.15 01:12, Peter Chapin wrote:
> Now they are stuck with maintaining two incompatible versions of the language into the arbitrary future.

Ruby and Perl got stuck too, here and there. One of the causes being
when their string type was relying on C's char.  At some point, the
eighth's bit became meaningful, encoding and better types needing
support in the language. (Just consider C's 127 + 1 if CHAR_BIT is 8,
and dynamically linked libraries being used.)  One effect on Python
is that programmers cannot easily use many libraries that were built
with 7 bit I/O in mind.

Python's creator Guido van Rossum has left Google, so maybe Google
will use their own Go language now, Python loosing a sponsor.


 From the technical point of view:

    12345.67e9

does not make a programmer think about encoding of numeric literals,
does it? Whereas "π" does, in all sorts of ways. While programmers do
need numbers all the time, the same is perhaps not true about text.

So, possibly computer scientists have created a huge language problem
by building on the assumption that "text stuff", rarely needed as it
is, is just like numeric literals.

    But "'A'" /= "65 ". Dammit!

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Luke A. Guest]

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

> To take an analogy: nobody would be so fool as to use a language
> designed for making animations on web pages in a real-time context ;-)


What? Like Java?

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Wright]

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

> What I would hope is that the designer uses unsigned integers for
> those variables and, in order to make the code portable across
> platforms, they used uint32_t and friends to encode within the program
> what the actual required size of those variables need to be.

When I was translating STM32F4 headers into Ada, I was able to convert
the -fdump-ada-spec generated uint32_t into Interfaces.Unsigned_32,
which seemed to work very well (though exceedingly thin, of course!)

Bit of sed script:

# Unsigned types in parameters/record components
s/stdint_h.uint(8|16|32|64)_t/Interfaces.Unsigned_\1/g

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 22, 2015 at 7:57:23 PM UTC+2, Simon Wright wrote:

> 
> When I was translating STM32F4 headers into Ada, I was able to convert
> the -fdump-ada-spec generated uint32_t into Interfaces.Unsigned_32,
> which seemed to work very well (though exceedingly thin, of course!)
> 
> Bit of sed script:
> 
> # Unsigned types in parameters/record components
> s/stdint_h.uint(8|16|32|64)_t/Interfaces.Unsigned_\1/g

Well Simon I would never feel bad about it. I bought myself a big bottle of variable-type stripper for doing the kernel module interface. I find life gets much easier that way.And the code more understandable. In the end it all means nothing, it is often just a whim of the coder.

But to get serious: Yes they did mean something when the people first had the problem seeing the difference between 32bit code and 64bit code, little endian and big endian etc. But in Ada the only time it bites you is when you do low level ethernet stuff, and even then there are some tricks to keep it all straight without going to the extremes of having 5 different type names for the same thing.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

Well,
Here is my 2 cents worth:

I learned to program in basic and assembler in the 70's. Then I dabbled a bit in C and forgot quickly I ever did such a thing.

All this until I found old Wirth's last creation: Oberon. I performed wonders in that language, with just a post-mortem stackframe debugger, if you can call it that.

Strongly typed, concise, object oriented were I needed that, and expressive enough to do everything that needs doing, for any size project.
And to cap it all the latest RM is all of 17 pages. 

Does that mean I have something against Ada? No not really, it is a very nice and cosy work environment, I enjoy it. But I will surely enjoy the day when the language lawyers learn to stop being logical and start to think, to quote Niels Bohr.

The simple fact that there is only 17 pages to learn off by hart makes a person that knows the trade extremely productive. And far fewer mistakes are made as a result _because we know what we are doing_ and we are willing to do it!. The same cannot be said for Ada. If I must count the hours searching out how to do a thing in Ada, then it will not be very far of trying to figure out how to interface with C for instance.
Please people if the basics are in place we do not need 1200 pages of ifs and buts. It is nonsense.

All it does is show that show that we have the money and the brain power to carry on on the road chosen, just like has happened in any other language, as was enumerated above in this thread.

Again I do not mean to say I have something against Ada, I enjoy it.

But I do say that old Dijkstra was right when he said that Ada was a mess. We merely managed to make the mess managable enough since then, so we can work and so that it is at least better than some of the other creations around.

Do I mean to say that George and Randy and Dmitry and others are not working hard and putting in lots of valuable time to make Ada better, off course not. I am merely making a plea for lean and mean. Because I know it _works_.

Thank you

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[David Botton]

> All this until I found old Wirth's last creation: Oberon.

What open source compilers (if there are) have a community right now for Oberon?

David Botton

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 22, 2015 at 5:21:06 PM UTC+2, David Botton wrote:
> > All this until I found old Wirth's last creation: Oberon.
> 
> What open source compilers (if there are) have a community right now for Oberon?
> 
> David Botton

about 3 or 4 go look for them.

I was not pushing Oberon, merely pushing lean and mean. It is worth the reflection.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Bob Duff]

jan.de.kruyf@gmail.com writes:

> But I do say that old Dijkstra was right when he said that Ada was a
> mess.

Yeah, and look what we got instead.  C++, for example.

- Bob

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 22, 2015 at 5:31:05 PM UTC+2, Bob Duff wrote:

> 
> > But I do say that old Dijkstra was right when he said that Ada was a
> > mess.
> 
> Yeah, and look what we got instead.  C++, for example.
> 
> - Bob

Yes, and that was not Dijkstra's doing. 
It was mankind that chose.

And I did say that I was not uncomfortable with Ada. Please read my post.

This thread seems to think that we will look better if we can heap scorn on other languages. Well it says a lot about the people that participate, and surprisingly little about those other languages.

Lets just pull together and make Ada better, That would be time well spend and much more enjoyable.

j.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[G.B.]

On 22.05.15 14:57, J-P. Rosen wrote:
> Le 22/05/2015 13:29, kalvin.news@gmail.com a écrit :
>> Even C could be made more robust, if simple type checking is
>> performed at compile time. For example,
>>
>> typedef int apples;
>>
>> typedef int oranges;
>>
>> apples a = 5; oranges o = a;
>>
>> should generate type check error as the types are definitely
>> different types. Also, assigning enums to ints and ints to enums
>> should be considered illegal.
>>
> I don't agree. C is a low level language, and good at that. Its types
> are those of the  machine: bytes and addresses, the rest is a (small
> quantity of) syntactic sugar.

Not sure this description of what C is in the eye of
an Adaist will win an argument; first, it is not exactly
right. (If myths say that int was influenced by PDP hardware
40 years ago, this doesn't seem to reflect C compilers in use
today, or yesterday.)

While the C type int is defined by the C standard,
one needs to consult the implementation's docs to
learn the specifics of int for a given implementation.

Same for Ada!

There would have been an opportunity to point out
the extended possibilities that Ada offers for expressing
expectations on types. But

   LS : String(1 .. 100_000);

is not defined by the Ada LRM as an unequivocally valid
piece of Ada source text, since Positive, and therefore
String, are only defined to much the same extent that C's
int is defined by C.

OTOH, what happens if I'd write  *(p + 100000-1) in a
C program?

Then, the C standard is explicit about what a byte is.
A C int cannot be expressed as bytes of C. Nor is the
behavior of int objects in borderline situations devoid
of context in the standard.

There also is no forced relationship of machine words and
int for a C implementation: 32 bits on a 64 bit architecture
is a valid choice. But that _is_ a source of trouble!

The issues are elsewhere, and it seems like a good opportunity
to show that, with Ada, there is actually more in the hands
of a programmer to address issues that cannot be addressed in
portable C source text; e.g., reactions to overflow.

C is in many ways as strongly typed as Ada, just not everywhere,
and that's worth pointing out, specifically addressing the typical
problems that C programs tend to run into.

C, in addition, has neither subtype constraints, nor derived types,
nor language-defined representation expressions etc.. But is _does_
have named type equivalence:

typedef struct apples { int amount; } Apples;
typedef struct oranges { int amount; } Oranges;

Oranges f() {
   Apples a = { .amount = 5 };

   return a;
}

The definition triggers a compile time error: it is nor permissible
to return a structurally equivalent struct apples when instead
a struct oranges was named as the return type in f's profile.

If the error is corrected, then the code produced, even when
just modest optimization is requested, will be the same as if
only a scalar type had been used.

That is not to say that I'd expect C programmers to avoid bare int.
Nor that the "solution" looks attractive. But it does confirm
that to say that C is a weakly typed _language_ will be ignored
by any C programmer in charge. Doing so falls short of being
an argument.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Bill White]

On 2015-05-22, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 22/05/2015 13:29, kalvin.news@gmail.com a ?crit :
>> Even C could be made more robust, if simple type checking is
>> performed at compile time. For example,
>> 
>> typedef int apples;
>> 
>> typedef int oranges;
>> 
>> apples a = 5; oranges o = a;
>> 
>> should generate type check error as the types are definitely
>> different types. Also, assigning enums to ints and ints to enums
>> should be considered illegal.
>> 
> I don't agree. C is a low level language, and good at that.

C isn't good at anything except to serve as a bad example!

> Its types are those of the  machine: bytes and addresses

Rather, C's types are those of C's virtual machine- C's view of the
hardware. And that makes C unsuitable for systems programming and not very
portable without defining your own types. Just because something is widely
used doesn't mean it's suitable. There are other factors like price,
availability, etc. Cheap (free) won long ago.

> If you need strong typing, use a strongly typed language. But don't
> blame C for not being strongly typed, it was simply not part of the
> requirements.

Agreed. But then the only requirements C ever really had were for ease of
implementation.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Bob Duff]

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

> I don't agree. C is a low level language, and good at that.

I say Ada is far superior to C for doing low-level programming.
Address clauses, representation clauses, packed arrays, ...

And Ada has the huge advantage that it doesn't force you into low-level
programming when you don't need that.

- Bob

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Clubley]

On 2015-05-22, Bob Duff <bobduff@theworld.com> wrote:
> "J-P. Rosen" <rosen@adalog.fr> writes:
>
>> I don't agree. C is a low level language, and good at that.
>
> I say Ada is far superior to C for doing low-level programming.
> Address clauses, representation clauses, packed arrays, ...
>

Unfortunately, C has one major advantage over Ada which is why it's
used for this kind of thing. Practically every platform out there has
a freely available C compiler which supports the platform as a target
so you can be sure you don't have to rewrite your C code in another
language when you want to port your code to a new environment.

Simon.

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

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 22, 2015 at 7:47:27 PM UTC+2, Simon Clubley wrote:

> >
> >> I don't agree. C is a low level language, and good at that.
> >
> > I say Ada is far superior to C for doing low-level programming.
> > Address clauses, representation clauses, packed arrays, ...
> >
> 
> Unfortunately, C has one major advantage over Ada which is why it's
> used for this kind of thing. Practically every platform out there has
> a freely available C compiler which supports the platform as a target
> so you can be sure you don't have to rewrite your C code in another
> language when you want to port your code to a new environment.
> 
> Simon.
> 
> -- 

There is more to it than that Simon.
I am looking at the moment at Linux Kernel code in order to write a module at least partly in Ada.

What I find is that (based on C) the Kernel writers have developed their own idiom that interfaces extremely badly to any language of the Algol family, of which Ada is one.
The inummerable #defines for inline routines are an example.
(And it is proven that those inlines slow the system down by the way, but that Linus did not know when he started the bad habit).

So basically its like writing your next novel in German. It might be a superior language ;) but it takes a real hobbyist to do it.

So besides any compilers, or the quality (or the lack thereof) of any computer language, there is a deeply cultural aspect involved. 

j.
  

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> (And it is proven that those inlines slow the system down by the way,
> but that Linus did not know when he started the bad habit).

I found that pragma Inline/Inline_Always slowed our PowerPC application
quite a bit. Cache effects, I suppose.

Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf]

On Friday, May 22, 2015 at 9:01:11 PM UTC+2, Simon Wright wrote:

> 
> > (And it is proven that those inlines slow the system down by the way,
> > but that Linus did not know when he started the bad habit).
> 
> I found that pragma Inline/Inline_Always slowed our PowerPC application
> quite a bit. Cache effects, I suppose.

Most likely, I did see some numbers but I forget where.

j.