Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6128 > unrolled thread

Re: My answer about Ada and FreePascal and C++

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: My answer about Ada and FreePascal and C++ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-31 18:59 +0000
    Re: My answer about Ada and FreePascal and C++ JJ <jj4public@vfemail.net> - 2016-01-01 07:23 +0700
      Re: My answer about Ada and FreePascal and C++ Kaz Kylheku <kaz@kylheku.com> - 2016-01-01 01:07 +0000
        Re: My answer about Ada and FreePascal and C++ JJ <jj4public@vfemail.net> - 2016-01-01 18:16 +0700
          Re: My answer about Ada and FreePascal and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-01 14:34 +0000
            Re: My answer about Ada and FreePascal and C++ JJ <jj4public@vfemail.net> - 2016-01-02 09:58 +0700
              Re: My answer about Ada and FreePascal and C++ Kaz Kylheku <kaz@kylheku.com> - 2016-01-02 03:23 +0000
                Re: My answer about Ada and FreePascal and C++ JJ <jj4public@vfemail.net> - 2016-01-02 21:35 +0700
          Re: My answer about Ada and FreePascal and C++ Kaz Kylheku <kaz@kylheku.com> - 2016-01-01 16:08 +0000

#6128 — Re: My answer about Ada and FreePascal and C++

On 31/12/15 18:50, Ramine wrote:
>
> I wrote:
>
>  > The following is true in C++:
>  >
>  > 1. C/C++ provide implicit type conversions between signed and unsigned
>  > values. Unlike Ada, there is no a runtime check to make sure the value
>  > is convertible to the new type. For example, you can readily “convert” a
>  > negative signed value to an unsigned value.
>
>
> And Richard Heathfield answered:
>
> --
>
> That's perfectly true. For example:
>
> unsigned long maxval = -1;
>
> That's a good thing, not a bad thing.
>
> ---
>
>
> I think  Richard Heathfield that your argument about C++ is stupid,

Well, okay, we can play ad hominem if you like. You think my argument is 
stupid, and I think your articles - your incessant, boring, 
ill-conceived, badly-written articles - are stupid. So what?

> because in FreePascal you have it both ways,  you can have it
> the way of C++ if you don`t compile with the -Cr compiler option

What has that to do with it? In C and C++, unsigned integer arithmetic 
is performed modulo 2^(CHAR_BIT * sizeof(unsigned_type)). That's not a 
weakness. That's a feature, and a very useful feature. If you don't like 
it, don't use C or C++. But to say that they are not suitable for 
such-and-such a purpose just because they contain a feature you don't 
like is utterly preposterous.

> and you can have it the Ada way if you compile it with the FreePascal
> compiler -Cr option, the FreePascal -Cr compiler option is suitable
> for realtime safety critical systems where you have to constrain
> the system with an unsigned int and you want at runtime to catch
> the exception locally in the function or you want to catch the
> exception globally, that`s what you can do in FreePascal and Ada, but
> you can not do it in C and C++ , so C++ and C are not suitable
> for realtime safety critical systems.

Using the same logic, Pascal incorrectly uses the semicolon as a 
separator rather than as a terminator, and therefore Pascal is not 
suitable for realtime safety critical systems. *That* is a stupid 
argument, and it's identical in form to your own.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [next] | [standalone]

#6152

On Thu, 31 Dec 2015 18:59:26 +0000, Richard Heathfield wrote:
> 
> ... Pascal incorrectly uses the semicolon as a 
> separator rather than as a terminator, ...

What kind of separator is that?
I've used Pascal since Turbo Pascal 4 and up to Free Pascal Compiler and
Delphi, but I've never seen a semicolon used a separator.

[toc] | [prev] | [next] | [standalone]

#6154

On 2016-01-01, JJ <jj4public@vfemail.net> wrote:
> On Thu, 31 Dec 2015 18:59:26 +0000, Richard Heathfield wrote:
>> 
>> ... Pascal incorrectly uses the semicolon as a 
>> separator rather than as a terminator, ...
>
> What kind of separator is that?
> I've used Pascal since Turbo Pascal 4 and up to Free Pascal Compiler and
> Delphi, but I've never seen a semicolon used a separator.

See this Pascal BNF grammar, for instance, which looks like
some traditiona, old Pascal:

http://www2.informatik.uni-halle.de/lehre/pascal/sprache/pas_bnf.html

In every production where a semicolon terminal symbol appears, it is
preceded and followed by something (a something which doesn't derive
an empty string). Hence it is a separator.

Never mind that, I'm looking now at a copy of what appears to be the ISO
Pascal 1990 standard, ISO/IEC 7185:1990 (E).

This document defines a grammar which has some terminating uses
of the semicolon, notably in the area of declarations. To wit,

  6.2.1 type-definition-part = [ 'type' type-definition ';' { type-definition ';' } .

and various other examples.  However:

  6.8.3.1 statement-sequence = statement { ';' statement } .

Likewise, various others.

This inconsistency is arguably worse than making the semicolon always a
separator or always a terminator.

[toc] | [prev] | [next] | [standalone]

#6156

On Fri, 1 Jan 2016 01:07:16 +0000 (UTC), Kaz Kylheku wrote:
> 
> See this Pascal BNF grammar, for instance, which looks like
> some traditiona, old Pascal:
> 
> http://www2.informatik.uni-halle.de/lehre/pascal/sprache/pas_bnf.html
> 
> In every production where a semicolon terminal symbol appears, it is
> preceded and followed by something (a something which doesn't derive
> an empty string). Hence it is a separator.

As far as I can see, it's a flaw in the Backus–Naur Form itself. Backus–Naur
Form doesn't require a terminator character at the end of each rule.

> Never mind that, I'm looking now at a copy of what appears to be the ISO
> Pascal 1990 standard, ISO/IEC 7185:1990 (E).
> 
> This document defines a grammar which has some terminating uses
> of the semicolon, notably in the area of declarations. To wit,
> 
>   6.2.1 type-definition-part = [ 'type' type-definition ';' { type-definition ';' } .
> 
> and various other examples.  However:
> 
>   6.8.3.1 statement-sequence = statement { ';' statement } .
> 
> Likewise, various others.
> 
> This inconsistency is arguably worse than making the semicolon always a
> separator or always a terminator.

I don't think this is also a flaw in the Pascal language itself.

Specifications are not always perfect. There are many other specifications
that are misleading, unclear, or simply incorrect. Sometimes they corrected
them and sometimes don't. When they don't, either it's too trivial to
correct, or there are already greater number of statements that conflict
against the incorrect one.

[toc] | [prev] | [next] | [standalone]

#6158

JJ <jj4public@vfemail.net> writes:

> On Fri, 1 Jan 2016 01:07:16 +0000 (UTC), Kaz Kylheku wrote:
>> 
>> See this Pascal BNF grammar, for instance, which looks like
>> some traditiona, old Pascal:
>> 
>> http://www2.informatik.uni-halle.de/lehre/pascal/sprache/pas_bnf.html
>> 
>> In every production where a semicolon terminal symbol appears, it is
>> preceded and followed by something (a something which doesn't derive
>> an empty string). Hence it is a separator.
>
> As far as I can see, it's a flaw in the Backus–Naur Form itself. Backus–Naur
> Form doesn't require a terminator character at the end of each rule.

No, there's nothing wrong with BNF itself.  It can describe a language where
a semicolon is a statement separator:

  statement-list:
     statement
     statement-list ; statement

and it can describe one in which the semicolon is a statement
terminator:

  statement-list:
     statement ;
     statement-list statement ;

although in the later case it's more normal to put the semicolon into
the production for a statement:

  statement-list:
     statement
     statement-list statement
   
  statement:
     statement-content ;

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#6160

On Fri, 01 Jan 2016 14:34:35 +0000, Ben Bacarisse wrote:
> 
> No, there's nothing wrong with BNF itself.  It can describe a language where
> a semicolon is a statement separator:
> 
>   statement-list:
>      statement
>      statement-list ; statement
> 
> and it can describe one in which the semicolon is a statement
> terminator:
> 
>   statement-list:
>      statement ;
>      statement-list statement ;
> 
> although in the later case it's more normal to put the semicolon into
> the production for a statement:
> 
>   statement-list:
>      statement
>      statement-list statement
>    
>   statement:
>      statement-content ;
> 
> <snip>

So, it's that page's author then?

[toc] | [prev] | [next] | [standalone]

#6161

On 2016-01-02, JJ <jj4public@vfemail.net> wrote:
> On Fri, 01 Jan 2016 14:34:35 +0000, Ben Bacarisse wrote:
>> 
>> No, there's nothing wrong with BNF itself.  It can describe a language where
>> a semicolon is a statement separator:
>> 
>>   statement-list:
>>      statement
>>      statement-list ; statement
>> 
>> and it can describe one in which the semicolon is a statement
>> terminator:
>> 
>>   statement-list:
>>      statement ;
>>      statement-list statement ;
>> 
>> although in the later case it's more normal to put the semicolon into
>> the production for a statement:
>> 
>>   statement-list:
>>      statement
>>      statement-list statement
>>    
>>   statement:
>>      statement-content ;
>> 
>> <snip>
>
> So, it's that page's author then?

No, it's not the author either. It's the design of Pascal,
whose grammar the author was just writing down in BNF.

You may be tripped up by the fact that some Pacal dialects have a null
statement, whose use looks like a terminating semicolon:

   begin
     a := a + 1;
   end

In the above block, we have two statements: a = a + 1 and a null
statement, separated by a semicolon!

ISO 7185:1990 Pascal has such a thing in its grammar; see the
"empty-statement" rule in
<http://www.pascal-central.com/docs/iso7185.pdf>, section
6.8.2.1.

Perhaps some Pascal dialects have actual statement-terminating
semicolons in their grammars.

[toc] | [prev] | [next] | [standalone]

#6162

On Sat, 2 Jan 2016 03:23:15 +0000 (UTC), Kaz Kylheku wrote:
> 
> No, it's not the author either. It's the design of Pascal,
> whose grammar the author was just writing down in BNF.
> 
> You may be tripped up by the fact that some Pacal dialects have a null
> statement, whose use looks like a terminating semicolon:
> 
>    begin
>      a := a + 1;
>    end
> 
> In the above block, we have two statements: a = a + 1 and a null
> statement, separated by a semicolon!
> 
> ISO 7185:1990 Pascal has such a thing in its grammar; see the
> "empty-statement" rule in
> <http://www.pascal-central.com/docs/iso7185.pdf>, section
> 6.8.2.1.
> 
> Perhaps some Pascal dialects have actual statement-terminating
> semicolons in their grammars.

Oh, now I see.

In Delphi's documentation, a snippet of the (Object Pascal) grammar is
described like this:

<http://pastebin.com/GFQ2qTZj>

It looks like BNF but doesn't use the same character.
i.e. "->" instead of ":" or "::="

What about the possibility that ISO Pascal is not exactly the same as the
original Pascal when it was designed?

I mean, like Netspace's JavaScript. Some say that Netspace's JavaScript is
different than ECMAScript which is a standardization of the original
JavaScript. I just not sure the exact difference, though.

[toc] | [prev] | [next] | [standalone]

#6159

On 2016-01-01, JJ <jj4public@vfemail.net> wrote:
> On Fri, 1 Jan 2016 01:07:16 +0000 (UTC), Kaz Kylheku wrote:
>> 
>> See this Pascal BNF grammar, for instance, which looks like
>> some traditiona, old Pascal:
>> 
>> http://www2.informatik.uni-halle.de/lehre/pascal/sprache/pas_bnf.html
>> 
>> In every production where a semicolon terminal symbol appears, it is
>> preceded and followed by something (a something which doesn't derive
>> an empty string). Hence it is a separator.
>
> As far as I can see, it's a flaw in the Backus–Naur Form itself. Backus–Naur
> Form doesn't require a terminator character at the end of each rule.

What??? You should listen to more Zeppelin because you need schoolin',
baby, I'm not foolin'.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web