why Ada type casting is different from other languages? newType(value) vs. (newType)value

why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Nasser M. Abbasi]

I am just wondering what is the rational of Ada choosing to use
   
     type(value)

vs
   
     (type)value

to do typecasting. does not type(value) appear as a function call?
as in

      i := float(9);

vs.

      i := (float) 9;

Just wondering on this choice and its advantage over the more
common syntax.

thanks,
--Nasser

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Shark8]

On 12-Jul-14 19:55, Nasser M. Abbasi wrote:
> I am just wondering what is the rational of Ada choosing to use
>      type(value)
>
> vs
>      (type)value
>
> to do typecasting. does not type(value) appear as a function call?
> as in
>
>       i := float(9);
>
> vs.
>
>       i := (float) 9;
>
> Just wondering on this choice and its advantage over the more
> common syntax.
>
> thanks,
> --Nasser

Because conversion certainly may be thought of as a function; implicitly:
Function TARGET_TYPE_NAME( Input : SOURCE_TYPE ) Return TARGET_TYPE;

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Jeffrey Carter]

On 07/12/2014 06:55 PM, Nasser M. Abbasi wrote:
>
> Just wondering on this choice and its advantage over the more
> common syntax.

For the same reason Ada has type conversions, not type casts. "Type conversion" 
is clear; "type cast" must be explained if you haven't encountered it before. 
Ada's notation is clear; conversions involve some processing and so are like 
functions. C's unintuitive notation must be explained when 1st encountered.

-- 
Jeff Carter
"I would never want to belong to any club that
would have someone like me for a member."
Annie Hall
41

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Dan'l Miller]

On Sunday, July 13, 2014 1:26:16 AM UTC-5, Jeffrey Carter wrote:
> On 07/12/2014 06:55 PM, Nasser M. Abbasi wrote:
> > Just wondering on this choice and its advantage over the more
> > common syntax.

It is not that uncommon.  See C++'s exact equivalent below.

> For the same reason Ada has type conversions, not type casts. "Type conversion" 
> is clear; "type cast" must be explained if you haven't encountered it before. 
> Ada's notation is clear; conversions involve some processing and so are like 
> functions. C's unintuitive notation must be explained when 1st encountered.

C++ has conversion constructors that have exactly the same syntax as Ada's type conversion.  C++ borrowed the idea & syntax from Ada.  (Yes, C++ has dynamic_cast, static_cast, and reinterpret_cast as well as the obsolescent cast from C, but that is in situ type casting, not type conversion from one type of instance to another type of freshly-synthesized instance.)  In modern C++, conversion constructors come in 2 varieties:  implicit (i.e., the early-C++ variety) and explicit when annotated at time of declaration with the explicit keyword.

Here is what I believe to be the most historically-correct answer to your question, but only the early Green team, especially Ichbiah) would know for sure:
Ada was probably influenced by Algol68's mode coercion, where mode is Algol68-speak for type and coercion is Algol68-speak for conversion or casting or dereferencing or bit-widening numerics.  [Why did Algol68 utilize mode as the term for type?  Think modus operandi.]  Algol68 utilized the exact same syntax for explicit mode conversions as Ada borrowed for type conversions and that C++ borrowed (from either Algol68 or Ada or both as early C++'s mantra was "Ada done right") for conversion constructors.  Algol68 had multiple strengths of implicit (soft, weak, meek, firm, and strong) mode coercion.  (I could be incorrect that all of soft, weak, meek, firm, and strong are always implicit.)

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Niklas Holsti]

On 14-07-13 04:55 , Nasser M. Abbasi wrote:
> I am just wondering what is the rational of Ada choosing to use
>       type(value)
> 
> vs
>       (type)value
> 
> to do typecasting. does not type(value) appear as a function call?
> as in
> 
>      i := float(9);
> 
> vs.
> 
>      i := (float) 9;
> 
> Just wondering on this choice and its advantage over the more
> common syntax.

What do you mean, "common" :-) ? Most programming languages I have seen
have the Ada form, "type(value)", although the name of the conversion is
not always simply the type-name, but something more specific, at least
if the conversion loses information.

For example, Fortran 66:

- conversion from integer to float:  FLOAT(integer_expression)
- conversion from float to integer:  IFIX(float_expression)

Only C and its legitimate and illegitimate offspring and relatives use
the form "(type)value", as far as I know.

Ranting aside, the C form has the clear disadvantage that one must
remember precedence rules to understand what is being converted:

  is (float)i the same as (float)i + j,
  or is it the same as (float)(i + j) ?

In the Ada form, type(value), the parentheses nicely enclose the value
to be converted. Much better IMO.

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

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Dmitry A. Kazakov]

On Sun, 13 Jul 2014 12:01:26 +0300, Niklas Holsti wrote:

> Ranting aside, the C form has the clear disadvantage that one must
> remember precedence rules to understand what is being converted:
> 
>   is (float)i the same as (float)i + j,
>   or is it the same as (float)(i + j) ?
> 
> In the Ada form, type(value), the parentheses nicely enclose the value
> to be converted. Much better IMO.

BTW, in Ada one need not remember precedence rules because all expressions
where unary operation might be ambiguous are illegal:

   not X and Y -- Illegal, brackets required
   X and not Y -- That's OK

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

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[AdaMagica]

On Sunday, July 13, 2014 11:08:30 AM UTC+2, Dmitry A. Kazakov wrote:
>    not X and Y -- Illegal, brackets required

I doubt it. RM 4.5(2..7) says "not" has highest precedence, "and" lowest, so this is
    (not X) and Y
(I didn't ask GNAT). So the parentheses-less form should be legal.

>    X and not Y -- That's OK

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Georg Bauhaus]

On 13.07.14 11:08, Dmitry A. Kazakov wrote:
> On Sun, 13 Jul 2014 12:01:26 +0300, Niklas Holsti wrote:
>
>> Ranting aside, the C form has the clear disadvantage that one must
>> remember precedence rules to understand what is being converted:
>>
>>    is (float)i the same as (float)i + j,
>>    or is it the same as (float)(i + j) ?
>>
>> In the Ada form, type(value), the parentheses nicely enclose the value
>> to be converted. Much better IMO.
>
> BTW, in Ada one need not remember precedence rules because all expressions
> where unary operation might be ambiguous are illegal:
>
>     not X and Y -- Illegal, brackets required
>     X and not Y -- That's OK


The bit about ambiguity is not meant to be a statement of a general truth?
Before the fact, is the following text unambiguous for a human reader?

    X : constant := 16#7F_FF#;

begin

    if not X in Unsigned_16'Range then  -- legal, brackets suggested
       raise Program_Error;
    end if;

(Yes, there are better ways to write this, but since you must know
them, the latter requirement wipes out some of the alleged advantage of Ada
in this regard, I think.)

I have read plausible justifications for the choice of type conversion syntax
of both Ada and C. But conceptually, I think that C++ has found a better
solution. It is more Ada like, perhaps, whenever C++ suggests to explicitly
state the intent:

    static_cast<float>(i + j)

seems pretty clear (even when it might be unnecessary). Ada's and C's
overloading of round brackets for several different things might be
tempting at first, but the temptation ceases once ease of understanding
the differences is considered more important. Of course, that's the time
when the phrase "every competent programmer ..." will be heard from all
camps, and then the ones about < and > !

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:53c25e58$0$6665$9b4e6d93@newsspool3.arcor-online.net...
...
> I have read plausible justifications for the choice of type conversion 
> syntax
> of both Ada and C. But conceptually, I think that C++ has found a better
> solution. It is more Ada like, perhaps, whenever C++ suggests to 
> explicitly
> state the intent:
>
>    static_cast<float>(i + j)
>
> seems pretty clear (even when it might be unnecessary). Ada's and C's
> overloading of round brackets for several different things might be
> tempting at first, but the temptation ceases once ease of understanding
> the differences is considered more important.

But the question here is whether a detailed understanding of the differences 
is necessary the vast majority of the time. In Ada, at least, that's 
typically not necessary. One simply thinks of anything of the form 
"name(args)" as a named mapping from "args" to some result type. Assuming 
one is looking at existing code that already compiles (which is typically 
the case when one is trying to understand an expression [if you just wrote 
it, you hopefully still remember what you meant, and hopefully no one is 
checking in code that doesn't compiler], you usually don't need to know the 
exact types involved.

And if you do, in a language like Ada you need to look up every name 
involved and try to figure out which declaration is involved. Hopefully you 
have an IDE to do it, because it's never fun with just text tools. And 
that's true for type conversions (finding the location of the declaration 
can be unpleasant if there are a lot of use clauses and withs) as well as 
functions and arrays (since objects can be the results of parameterless 
functions and possibly hidden by nesting).

My point being, that knowing that something is a type conversion or an array 
indexing only helps a little. And they're really ways of looking at the same 
thing (a mapping) -- something that Dmitry likes to call an interface.

                              Randy.

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[G.B.]

On 15.07.14 01:36, Randy Brukardt wrote:
> My point being, that knowing that something is a type conversion or an array
> indexing only helps a little. And they're really ways of looking at the same
> thing (a mapping) -- something that Dmitry likes to call an interface.

The authors seem to think that, for newcomers at least, it is better
to have different syntax for different things, irrespective of
experienced linguists' abstract views. Should we learn abstraction
first in order to be able to understand that different things have a
common interface warranting the same syntax for using the different
things?

What's a enough syntax, though?

I think the typical cases of language use can be put to
the test. For example, there is iteration as one use case
and Ada provides syntax (though not just one).

   for ... loop
      iterated_statements;
   end loop;

Another example is placing data in some containing object.
For arrays, again, Ada does have syntax,

    a(x) := 9;

which is, however, partially the same, considering context,
as for functions and type conversions.

Now, for testing, if I go to some high school and ask those who
have had some introduction to programming, about the meaning of

    foo(x) := 9;

and then go to another high school for asking a similar question,

    foo[x] := 9;

what answers will I get in each case? Will () vs [] be an issue?
Maybe less so if 'a' is substituted for 'foo', assuming that 'a'
suggests arrays, but do we know this? "f(x) := y" is at odds with
what I have learned at school. The notation f(x) invariably meant
function. I guess that explaining to students that you can think
of *defining* array-as-function f(x) by use of assignment might
be a surprise.

So, style as a guiding principle of language design could be
contrasted with such test results.

And later, is it really good or bad if it takes years or not
to be competent enough to understand

   ptrdiff_t x = *(ptrdiff_t*)main;

vs

   X : Integer_Address := To_Integer (Main'Address);

if they are comparable?
__
(*) "Every terminating algorithm computes a function after all,
so why think in terms of procedures at all and not just declare..."

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Niklas Holsti]

On 14-07-15 21:42 , G.B. wrote:

> And later, is it really good or bad if it takes years or not
> to be competent enough to understand
> 
>   ptrdiff_t x = *(ptrdiff_t*)main;
> 
> vs
> 
>   X : Integer_Address := To_Integer (Main'Address);
> 
> if they are comparable?

Aah... they are *not* "comparable", if by that you mean "equivalent".
The first (C) declaration interprets the entry address of "main" as a
pointer to a ptrdiff_t, and then dereferences that pointer to read this
putative ptrdiff_t value and store it in x. In other words, x will
contain bits from the initial instructions of "main".

The second (Ada) declaration simply converts the entry address of "Main"
to an Integer_Address. It does not read anything from the instructions
in Main.

Perhaps I misunderstood your point?

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

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Georg Bauhaus]

On 15.07.14 21:14, Niklas Holsti wrote:
> On 14-07-15 21:42 , G.B. wrote:
>
>> And later, is it really good or bad if it takes years or not
>> to be competent enough to understand
>>
>>    ptrdiff_t x = *(ptrdiff_t*)main;
>>
>> vs
>>
>>    X : Integer_Address := To_Integer (Main'Address);
>>
>> if they are comparable?
>
> Aah... they are *not* "comparable", if by that you mean "equivalent".

That formula was to serve as an escape route and...

> Perhaps I misunderstood your point?

...you have proven my point, inasmuch as C's syntax (and other habits
which could be ascribed to it) have made me confused, while Ada does
not even require a type conversion. (I was copying from an earlier
example, replacing "0xa100" with "main" of a different type.) OTOH,
that's just this single programmer who, likely incompetently, messed up.

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Jeffrey Carter]

On 07/15/2014 11:42 AM, G.B. wrote:
>
> The authors seem to think that, for newcomers at least, it is better
> to have different syntax for different things, irrespective of
> experienced linguists' abstract views.

That some people got a book published doesn't mean they know what they're 
talking about. In a controlled experiment at West Point, it was determined that 
Ada is a better introductory language than Pascal, even though Ada uses 
parentheses for everything, while Pascal uses brackets for array indexing.

-- 
Jeff Carter
"Ah, go away or I'll kill ya."
Never Give a Sucker an Even Break
100

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Georg Bauhaus]

On 15.07.14 21:19, Jeffrey Carter wrote:
> On 07/15/2014 11:42 AM, G.B. wrote:
>>
>> The authors seem to think that, for newcomers at least, it is better
>> to have different syntax for different things, irrespective of
>> experienced linguists' abstract views.
>
> That some people got a book published doesn't mean they know what they're talking about. In a controlled experiment at West Point, it was determined that Ada is a better introductory language than Pascal, even though Ada uses parentheses for everything, while Pascal uses brackets for array indexing.

I have found
  "A Comparison of Ada and Pascal in an Introductory Computer Science Course"
by Murtagh & Hamilton. Things other than the shape of brackets have
greater influence on educational success, then. (Packages, types,
explicit type conversion, syntax without surprises, good error messages.)

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Randy Brukardt]

"G.B." <bauhaus@futureapps.invalid> wrote in message 
news:lq3slq$n75$1@dont-email.me...
> On 15.07.14 01:36, Randy Brukardt wrote:
>> My point being, that knowing that something is a type conversion or an 
>> array
>> indexing only helps a little. And they're really ways of looking at the 
>> same
>> thing (a mapping) -- something that Dmitry likes to call an interface.
>
> The authors seem to think that, for newcomers at least, it is better
> to have different syntax for different things, irrespective of
> experienced linguists' abstract views. Should we learn abstraction
> first in order to be able to understand that different things have a
> common interface warranting the same syntax for using the different
> things?

Ah, but my point is that these are all the same thing. If people aren't 
teaching novices that, then that's on the teachers, not on the programming 
language.

In the case of Ada, and especially in Ada 2012, it's common to switch 
between arrays and functions without changing any of the uses. After all, 
the "syntax sugar" of a generalized index effectively replaces a logical 
array indexing by a function call. That works in part because they have the 
same syntax, so a user can think of
    Container(C) := Obj;
as indexing into a cursor (even though what's really happening is that one 
is making a function call with an implicit dereferencee of the result).

At a high enough level, there is no visible difference between array 
indexing and a function call and a type conversion. They're all just 
mappings. (There's also the question of whether proper encapsulation 
effectively eliminates the use of indexing and to a lesser extent, type 
conversions anyway -- they're all functions in the end because the 
implementation shouldn't be exposed -- and array indexing is clearly an 
artifact of the implementation.)

                                        Randy.

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Dan'l Miller]

On Sunday, July 13, 2014 1:26:16 AM UTC-5, Jeffrey Carter wrote: 
> On 07/12/2014 06:55 PM, Nasser M. Abbasi wrote: 
> > Just wondering on this choice and its advantage over the more 
> > common syntax. 

It is not that uncommon.  See C++'s exact equivalent below. 

> For the same reason Ada has type conversions, not type casts. "Type conversion" 
> is clear; "type cast" must be explained if you haven't encountered it before. 
> Ada's notation is clear; conversions involve some processing and so are like 
> functions. C's unintuitive notation must be explained when 1st encountered. 

C++ has conversion operators [i.e., operator destinationType(const originType&) without any type occupying the customary return-type slot] that have exactly the same syntax as Ada's type conversion.  C++ borrowed the idea & syntax from Ada.  (Yes, C++ has dynamic_cast, static_cast, and reinterpret_cast as well as the obsolescent cast from C, but that is in situ type casting, not type conversion from one type of instance to another type of freshly-synthesized instance.)  In modern C++, conversion operators come in 2 varieties:  implicit (i.e., the early-C++ variety) and explicit when annotated at time of declaration with the explicit keyword. 

Here is what I believe to be the most historically-correct answer to your question, but only the early Green team, especially Ichbiah) would know for sure: 
Ada was probably influenced by Algol68's mode coercion, where mode is Algol68-speak for type and coercion is Algol68-speak for conversion or casting or dereferencing or bit-widening numerics among its 7 categories of mode coercion.  [Why did Algol68 utilize mode as the term for type?  Think modus operandi:  the mode of operation of that bit-string.]  Algol68 utilized the exact same syntax for explicit mode conversions as Ada borrowed for type conversions and that C++ borrowed (from either Algol68 or Ada or both as early C++'s mantra was "Ada done right") for conversion operators.  Algol68 had multiple strengths of implicit (soft, weak, meek, firm, and strong) mode coercion.  (I could be incorrect that all of soft, weak, meek, firm, and strong are always implicit.)

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Adam Beneschan]

On Saturday, July 12, 2014 6:55:24 PM UTC-7, Nasser M. Abbasi wrote:
> I am just wondering what is the rational of Ada choosing to use
> 
>      type(value)
> 
> vs
>
>      (type)value
>
> to do typecasting. does not type(value) appear as a function call?
> 
> as in 
> 
>       i := float(9);
> 
> vs.
> 
>       i := (float) 9;
> 
> Just wondering on this choice and its advantage over the more
> common syntax.

The only reason the latter is "more common" is because a lot of languages have based their syntax on C's, and that's the syntax Ritchie decided to use.  I don't know of any language that isn't based on C syntax that uses this syntax for a cast.  As for the languages that do use that syntax, I don't think the designers made a conscious choice to use the (type)expression syntax--i.e. they didn't look at the possibilities and decide that (type)expression was better.  Rather, they just decided at the beginning to use C syntax, copied most of the syntax, and then perhaps made a few tweaks here and there.

Ironically, C++ now allows the type(expression) syntax for type conversion.  Technically, it's not a type conversion, but rather a one-argument constructor for an object of type "type" with "expression" as the argument.  But the language definition has defined implicit one-argument constructors for primitive types, so that the effect is the same.  Sometimes.  Actually, I think the semantics are subtly different, and there are times when (type)expression is legal where type(expression) is not, and sometimes you need to use dynamic_cast<type>(expression) or static_cast<type>(expression).  In fact, I think the (type)expression syntax isn't supposed to be used any more, and static_cast<type>(expression) is preferred, at least according to some authorities.  As someone I know likes to say, "If you're not confused, you're not paying attention." 

I don't like the (type)expression syntax because I can never remember what the precedence is.  This is especially a problem for (type)object.method(args), because I have to look up whether the type conversion applies to just the object or to the result of the function call.

In general, questions such as this are meaningless, because for the most part they come down someone's style preference.

                                -- Adam

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[G.B.]

On 14.07.14 17:25, Adam Beneschan wrote:
> I don't like the (type)expression syntax because I can never remember what the precedence is.  This is especially a problem for (type)object.method(args), because I have to look up whether the type conversion applies to just the object or to the result of the function call.
>
> In general, questions such as this are meaningless, because for the most part they come down someone's style preference.

It appears that in some situations style alone is not a permissible
language design guide. WRT syntax, McIver and Conway explain, with
novice programmers in mind, that there needs to be a good signal
to noise ratio and that this may mean just enough syntax, but also
enough syntax.  In particular, they address "homonyms",
as in "type(expression)" vs "something-else(expression)".

"Alternatively, it may be better to increase the complex-
  ity of the syntax in order to reduce homonyms which blur
  the signal. For example, the meaning of the various compo-
  nents of the Turing expression^7:


    f(C(p).A(I))(N)

"might be better conveyed with the syntax:

    f(C::p->A_{I})[N]

"The second form, whilst regrettably no more mnemonic than
  the first, does at least provide adequate visual differen-
  tiation between pointer dereference, array indexing, func-
  tion call, and substring extraction.

^7:
"Create a substring consisting of the Nth letter of
  the string returned by the function f when passed
  the Ith element of the array member A of the object
  within collection C which is pointed to by p".

Linda McIver & Damian Conway,
Seven Deadly Sins of Introductory Programming Language Design

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Simon Wright]

"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:

> "Alternatively, it may be better to increase the complex-
>  ity of the syntax in order to reduce homonyms which blur
>  the signal. For example, the meaning of the various compo-
>  nents of the Turing expression^7:
>
>
>    f(C(p).A(I))(N)
>
> "might be better conveyed with the syntax:
>
>    f(C::p->A_{I})[N]
>
> "The second form, whilst regrettably no more mnemonic than
>  the first, does at least provide adequate visual differen-
>  tiation between pointer dereference, array indexing, func-
>  tion call, and substring extraction.
>
> ^7:
> "Create a substring consisting of the Nth letter of
>  the string returned by the function f when passed
>  the Ith element of the array member A of the object
>  within collection C which is pointed to by p".
>
> Linda McIver & Damian Conway,
> Seven Deadly Sins of Introductory Programming Language Design

Cripes.

The first (Ada-ish) version makes sense to me, the second -- ugh.

Actually, the Ada version might be

  f(p.A(I))(N)

depending on what "the object within collection C which is pointed to by
p" means.

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Simon Clubley]

On 2014-07-14, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>
> It appears that in some situations style alone is not a permissible
> language design guide. WRT syntax, McIver and Conway explain, with
> novice programmers in mind, that there needs to be a good signal
> to noise ratio and that this may mean just enough syntax, but also
> enough syntax.  In particular, they address "homonyms",
> as in "type(expression)" vs "something-else(expression)".
>
> "Alternatively, it may be better to increase the complex-
>   ity of the syntax in order to reduce homonyms which blur
>   the signal. For example, the meaning of the various compo-
>   nents of the Turing expression^7:
>
>
>     f(C(p).A(I))(N)
>
> "might be better conveyed with the syntax:
>
>     f(C::p->A_{I})[N]
>

To be honest, that suggestion by the authors sounds a bit bogus to me.

By the time a newcomer is far enough along to understand the concepts
behind that syntax, does that person really still need that special
syntax ?

The above is not what you would teach a student new to programming
in their first week of class.

Simon.

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

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Dan'l Miller]

On Monday, July 14, 2014 2:41:58 PM UTC-5, Simon Clubley wrote:
> On 2014-07-14, G.B. <> wrote:
> >     f(C(p).A(I))(N)
> > "might be better conveyed with the syntax:
> >     f(C::p->A_{I})[N]
> 
> To be honest, that suggestion by the authors sounds a bit bogus to me.
> 
> By the time a newcomer is far enough along to understand the concepts
> behind that syntax, does that person really still need that special
> syntax ?

Let's face it.  Far less than 1% of programmers work for an employer or on an open-source project that builds out an ASIS-based (for Ada) or Clang-based (for C or C++ or Objective-C) or GCC MELT-based (for C or C++) source-code analysis tool with a precise & accurate parser.  (In fact, I suspect that the true number is far less than 1/100th of 1%.)  Without such a precise & accurate parser, grep(3)ing through source code to find that cryptic type-case or type-conversion is likely to give numerous false negatives (as well as false positives).  Ignoring obfuscation possible in the C preprocessor, grep(3)ing through source code for type-casting syntax that is designed to be extraordinarily obvious (e.g., C++'s static_cast<type>(expression), dynamic_cast<type>(expression), and reinterpret_cast<type>(expression) is a highly-desirable welcome alternative to building out a ASIS-based or Clang-based or GCC MELT-based source-code analyzer/parser tool.  That goes for the expert in the language and it goes double (or a decimal order of magnitude more) for a beginner in a language.

As I mentioned earlier in a branch of this thread, Ada's subtle typecasting syntax is a historical artifact of mimicking ALGOL68's type-cast syntax back when Green was designed in the 1970s back when ALGOL68 still had some sway as the state-of-the-art in language-design.

> The above is not what you would teach a student new to programming
> in their first week of class.

  But that is sort of the point, now isn't it.  In a strongly-typed language, every way of manipulating types is a core part of the essential language.  When a programmer (beginning or otherwise) needs to play parser on typing information (which most programmers consider playing language lawyer, which is disdain not a complement), then most Millennial-generation programmers just give up and go with a less-strongly-type scripted language and declare a sort of victory.

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lq1bq1$o5d$1@dont-email.me...
> On 2014-07-14, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>>
>> It appears that in some situations style alone is not a permissible
>> language design guide. WRT syntax, McIver and Conway explain, with
>> novice programmers in mind, that there needs to be a good signal
>> to noise ratio and that this may mean just enough syntax, but also
>> enough syntax.  In particular, they address "homonyms",
>> as in "type(expression)" vs "something-else(expression)".
>>
>> "Alternatively, it may be better to increase the complex-
>>   ity of the syntax in order to reduce homonyms which blur
>>   the signal. For example, the meaning of the various compo-
>>   nents of the Turing expression^7:
>>
>>
>>     f(C(p).A(I))(N)
>>
>> "might be better conveyed with the syntax:
>>
>>     f(C::p->A_{I})[N]
>>
>
> To be honest, that suggestion by the authors sounds a bit bogus to me.
>
> By the time a newcomer is far enough along to understand the concepts
> behind that syntax, does that person really still need that special
> syntax ?

I agree. On top of that, there's more than 3 kinds of bracketed expressions 
(type conversion, type qualification, subprogram call, aggregates, array 
indexing, array slicing, and now conditional expressions and qualified 
expressions), but in ASCII there's only 3 useable sets of brackets (), [], 
{}. (You can't use <> as brackets in expressions because of ambiguity with 
operators < and >.) Any choice is going to end up with arbitrary groupings 
where some kinds of brackets are the same and some are different. Ada 
decided not to bother and just use one set - then you never have to worry 
about what set to use.

                              Randy.

Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Marius Amado-Alves]

Float(x) is the *right* syntax.
Proof: C++ has it now:-)