Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
why Ada type casting is different from other languages? newType(value) vs. (newType)value
1,478 views
Skip to first unread message
Nasser M. Abbasi
Jul 12, 2014, 9:55:24 PM7/12/14
to
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
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
Shark8
Jul 12, 2014, 11:01:43 PM7/12/14
to
Function TARGET_TYPE_NAME( Input : SOURCE_TYPE ) Return TARGET_TYPE;
Jeffrey Carter
Jul 13, 2014, 2:26:16 AM7/13/14
to
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"
>
> Just wondering on this choice and its advantage over the more
> common syntax.
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
Niklas Holsti
Jul 13, 2014, 5:01:26 AM7/13/14
to
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
. @ .
Dmitry A. Kazakov
Jul 13, 2014, 5:08:30 AM7/13/14
to
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
> 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.
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
AdaMagica
Jul 13, 2014, 6:20:16 AM7/13/14
to
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 -- Illegal, brackets required
(not X) and Y
(I didn't ask GNAT). So the parentheses-less form should be legal.
Georg Bauhaus
Jul 13, 2014, 6:24:24 AM7/13/14
to
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 > !
Message has been deleted
Dan'l Miller
Jul 13, 2014, 10:42:16 AM7/13/14
to
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:
> 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.
> > 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.
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.)
Adam Beneschan
Jul 14, 2014, 11:25:42 AM7/14/14
to
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
G.B.
Jul 14, 2014, 12:24:22 PM7/14/14
to
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
> 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.
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
Simon Wright
Jul 14, 2014, 1:41:00 PM7/14/14
to
"G.B." <rm-dash-...@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.
> "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
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.
Simon Clubley
Jul 14, 2014, 3:41:58 PM7/14/14
to
On 2014-07-14, G.B. <rm-dash-...@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.
>
> 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]
>
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
Dan'l Miller
Jul 14, 2014, 4:51:08 PM7/14/14
to
On Monday, July 14, 2014 2:41:58 PM UTC-5, Simon Clubley wrote:
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.
> 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.
> > 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 ?
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.
Randy Brukardt
Jul 14, 2014, 7:23:09 PM7/14/14
to
"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
message news:lq1bq1$o5d$1...@dont-email.me...
(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.
message news:lq1bq1$o5d$1...@dont-email.me...
> On 2014-07-14, G.B. <rm-dash-...@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
>>
>> 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 ?
(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.
Randy Brukardt
Jul 14, 2014, 7:36:16 PM7/14/14
to
"Georg Bauhaus" <rm.dash...@futureapps.de> wrote in message
news:53c25e58$0$6665$9b4e...@newsspool3.arcor-online.net...
...
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.
news:53c25e58$0$6665$9b4e...@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
> 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.
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.
G.B.
Jul 15, 2014, 2:42:03 PM7/15/14
to
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
> 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.
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..."
Niklas Holsti
Jul 15, 2014, 3:14:31 PM7/15/14
to
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".
> 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?
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?
Jeffrey Carter
Jul 15, 2014, 3:19:53 PM7/15/14
to
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
>
> 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.
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
Marius Amado-Alves
Jul 15, 2014, 3:22:50 PM7/15/14
to
Float(x) is the *right* syntax.
Proof: C++ has it now:-)
Proof: C++ has it now:-)
Randy Brukardt
Jul 15, 2014, 6:00:41 PM7/15/14
to
"G.B." <bau...@futureapps.invalid> wrote in message
news:lq3slq$n75$1...@dont-email.me...
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.
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
>> 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?
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.
Georg Bauhaus
Jul 15, 2014, 6:47:48 PM7/15/14
to
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...
> 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".
> Perhaps I misunderstood your point?
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.
Georg Bauhaus
Jul 15, 2014, 7:07:13 PM7/15/14
to
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
> 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.
"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.)
0 new messages