Syntax question

Syntax question

[Adrian Cho]

I am writing a chart comparing the syntax of a number of languages for an English sentence.
For example:

English:    Jack, put the box on the table

Smalltalk:  Jack putThe: box onThe: table

C:          putOn( Jack, box, table )

C++:        Jack.putOn( box, table )

Would someone in this newsgroup be kind enough to e-mail to me (adrian@acm.org)
the equivalent for the language of this newsgroup.  I think the above example
is self-explanatory.  Jack, box, and table are entities or objects and 'put on' is an action
or verb.   Please use the correct case.

Any help is much appreciated.

Thanks

Adrian

adrian@acm.org

Re: Syntax question

[Robert Dewar]

Put_On (Who => Jack, What => "the box", Where => On ("the table"));

Re: Syntax question

[Tucker Taft]

In article <Cx6pG3.IEp@ucc.su.oz.au>, Adrian Cho <adrian@acm.org> wrote:
>I am writing a chart comparing the syntax of a number of 
>languages for an English sentence.
>For example:
>
>English:    Jack, put the box on the table
>
>Smalltalk:  Jack putThe: box onThe: table
>
>C:          putOn( Jack, box, table )
>
>C++:        Jack.putOn( box, table )

Ada 83/9X:      Please(Jack, Put => Box, On => Table);

   (courtesy counts ;-)

>Would someone in this newsgroup be kind 
>enough to e-mail to me (adrian@acm.org)
>the equivalent for the language of this 
>newsgroup.  I think the above example
>is self-explanatory.  Jack, box, and 
>table are entities or objects and 'put on' is 
>an action or verb.   Please use the correct case.

I will e-mail this as well.

Of course, there are an infinite number of alternatives; the 
"courteous" one above takes advantage of the ability to use formal
parameter names to resolve overloading.  Probably the more
natural (or more "demanding" ;-) thing would be:

Ada 83/9X:      Put(Object => Box, On => Table, By => Jack);

Note that in Ada 9X, the "controlling" operand (presumably Jack
given the way you coded it in Smalltalk and C++) need not be
the first operand, and even if it is declared first, it can
be placed later in a call if named parameter notation is 
used (as above).  Also, there can be multiple controlling operands
(such as in "Shake_Hands(Jack, Jim)"); in such a case, all 
controlling operands are treated symmetrically.

>Any help is much appreciated.

I hope the above helps.

>Thanks
>
>Adrian
>
>adrian@acm.org

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: Syntax question

[Norman H. Cohen]

In article <36u42h$ru9@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> Put_On (Who => Jack, What => "the box", Where => On ("the table"));

No, no, no!  The_Box belongs to a type derived from the tagged type
Puttable_Object, and Put_On is a dispatching operation of this type, so
we have: 

   Put_On
      (Who   => Jack,
       What  => Puttable_Object'Class(The_Box),
       Where => The_Table);

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Syntax question

[David Weller]

In article <36ui0u$4dg@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Maybe the C line should be
>
>  p(j,b,t)
>
>since it seems out of style to use those long names :-)
>
*Whew*  Somebody _finally_ wrote some C code I can understand! :-)


-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Syntax question

[Geoffrey Hollingworth]

Hi

I am currently researching into real time languages and hope
you ada experts can explain something to me.  I apologise for
my lack of knowledge in ada.
When binding formal parameters with actual parameters the '=>'
operator is used, irrespective of whether the formal parameter
is declared as IN, INOUT or OUT.  Is there a reason for this ?
If I proposed an alternative syntax where "=>" indicated the FP
was an IN parameter, "<=" to indicate an OUT parameter and "<=>"
to indicate an INOUT.
Then the caller of the procedure/function would have explicitly
had to understand to direction of the parameters and at the same
time increased the readability of his/her code.
Is there a fundamental flaw in this line of thinking ?
Does ada manage this problem via a different mechanism ?

Any information, historical or otherwise, would be a great help
to me and greatly appreciated.

thanks

/geoff

Re: Syntax question

[Robert A Duff]

In article <3jrt1m$9rk@erinews.ericsson.se>,
Geoffrey Hollingworth <etlghh@garbo.ericsson.se> wrote:
>When binding formal parameters with actual parameters the '=>'
>operator is used, irrespective of whether the formal parameter
>is declared as IN, INOUT or OUT.  Is there a reason for this ?
>If I proposed an alternative syntax where "=>" indicated the FP
>was an IN parameter, "<=" to indicate an OUT parameter and "<=>"
>to indicate an INOUT.

Yeah, something like that might be nice.  In fact, I believe an early
version of Ada (or its precursor Green) did something like that.  I
don't know why they got rid of it.

However, note that you don't want to use "<=", because that already
means "less than or equal".

- Bob

Re: Syntax question

[Michael Feldman]

In article <3jrt1m$9rk@erinews.ericsson.se>,
Geoffrey Hollingworth <etlghh@garbo.ericsson.se> wrote:

>When binding formal parameters with actual parameters the '=>'
>operator is used, irrespective of whether the formal parameter
>is declared as IN, INOUT or OUT.  Is there a reason for this ?
>If I proposed an alternative syntax where "=>" indicated the FP
>was an IN parameter, "<=" to indicate an OUT parameter and "<=>"
>to indicate an INOUT.

This is an interesting idea, but of course it's not part of the language.
The => is used as a general sort of binding operator:

- formal to actual parameters
- formal to actual discriminants (variant record tags)
- in CASE and exception handler clauses

etc.

In the first two cases, it is quite legal to omit the named association,
that is, a procedure P(X: T1; Y OUT T2; Z :IN OUT T3) can be called
using positional asociation: P(A,B,C).

The named association is very convenient in teaching about parameters,
and makes for nice readable code (IMHO, of course), but in general is
really "syntactic sugar." 

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
One, two, three ways an underdog: Ada fan, Mac fan, Old Liberal Democrat
------------------------------------------------------------------------
Ada on the WWW: http://lglwww.epfl.ch/Ada/ or http://info.acm.org/sigada/
------------------------------------------------------------------------

Re: Syntax question

[Road Pilot]

Geoffrey Hollingworth (etlghh@garbo.ericsson.se) wrote:
: Hi
: 
: I am currently researching into real time languages and hope
: you ada experts can explain something to me.  I apologise for
: my lack of knowledge in ada.
: When binding formal parameters with actual parameters the '=>'
: operator is used, irrespective of whether the formal parameter
: is declared as IN, INOUT or OUT.  Is there a reason for this ?
: If I proposed an alternative syntax where "=>" indicated the FP
: was an IN parameter, "<=" to indicate an OUT parameter and "<=>"
: to indicate an INOUT.
: Then the caller of the procedure/function would have explicitly
: had to understand to direction of the parameters and at the same
: time increased the readability of his/her code.
: Is there a fundamental flaw in this line of thinking ?
: Does ada manage this problem via a different mechanism ?
: 
: Any information, historical or otherwise, would be a great help
: to me and greatly appreciated.
: 
: thanks
: 
: /geoff

Well, the arrow symbol "=>" is not meant to imply direction.  It is used in
the case statement (ex: WHEN choice => statement) and in aggregate assingments
as well (ex: initializing specific cells of an array without multiple index
references).  This is all in contrast to positional reference.  In your a
function/procedure call, the use of the arrow notation is completely
optional.  In some cases of multiple parameters, it makes it easier to keep
them straight.  I like to use them mainly because it avoids confusion.

Like so:
procedure insert( list : in out integer; item : in integer ) is

	insert( 2, 4 );   OR  insert (list=>2, item=>4);

 either way will work. 
 
I don't know if this helps any or just confuses more, but I guess the main
thing is that the arrow is more like a placeholder or referencing tool and
is not meant to imply direction.

Sloaner
stdsee01@pip.shsu.edu

Re: Syntax question

[Keith Thompson]

In <3jrt1m$9rk@erinews.ericsson.se> etlghh@garbo.ericsson.se (Geoffrey Hollingworth) writes:
> I am currently researching into real time languages and hope
> you ada experts can explain something to me.  I apologise for
> my lack of knowledge in ada.
> When binding formal parameters with actual parameters the '=>'
> operator is used, irrespective of whether the formal parameter
> is declared as IN, INOUT or OUT.  Is there a reason for this ?
> If I proposed an alternative syntax where "=>" indicated the FP
> was an IN parameter, "<=" to indicate an OUT parameter and "<=>"
> to indicate an INOUT.
> Then the caller of the procedure/function would have explicitly
> had to understand to direction of the parameters and at the same
> time increased the readability of his/her code.

Some versions of preliminary Ada (1979, possibly 1980) used ":=", "=:",
and ":=:" for named associations for in, out, and in out parameters,
respectively.  This was changed to "=>" for all three modes.  As others
have mentioned, this applies only to named notation; in positional
notation you just write the actual expressions or names separated
by commas.

As part of the Ada 9X revision process, I proposed a revision to allow
the parameter mode to be (optionally) specified for actual parameters by
using "in", "out", or "in out".  The compiler would check that the mode
is consistent with the declaration.  For example, given the declaration

    procedure Foo(X: in Integer; Y: out Integer);

, and given that A and B are Integer objects, any of the following calls
would be legal, along with numerous other combinations:

    Foo(A, B);                  -- existing syntax
    Foo(X => A, Y => B);        -- existing syntax
    Foo(in A, out B);           -- new syntax
    Foo(in X => A, out Y => B); -- new syntax

and the following would be illegal:

    Foo(in X => A, in out Y => B); -- inconsistent mode specified for Y => B

This change would have been entirely upward compatible, straightforward
to implement, and (IMHO) could have dramatically improved readability
in many cases, but it didn't make it into the language.

Maybe for Ada 200X?

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.

Re: Syntax question

[David Kusuda]

In article dim@felix.seas.gwu.edu, mfeldman@seas.gwu.edu (Michael Feldman) writes:

[snip]

>The named association is very convenient in teaching about parameters,
>and makes for nice readable code (IMHO, of course), but in general is
>really "syntactic sugar." 

I agree with Michael's points regarding named parameter association.  But the named
parameter association is also necessary to:

  a) Specify the parameter list in an arbitrary order--I think this is a weak point
     as far as readability/maintainability, but still a point.
  b) Omit parameters which have default values.  I think that this is very useful,
     too bad C++ doesn't have the same thing.



Dave

Re: Syntax question

[David Weller]

In article <3k7t8o$4pt@hacgate2.hac.com>,
David Kusuda <dkusu@atc-1s.hac.com> wrote:
>  b) Omit parameters which have default values.  I think that this 
>     is very useful, too bad C++ doesn't have the same thing.
>

It does, too!  All you hafta do is add another member function with
the new parameter list.  After that, all it is is just another
recompile :-)


-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
	

Re: Syntax question

[Fred J. McCall]

In article <3k7t8o$4pt@hacgate2.hac.com> dkusu@atc-1s.hac.com (David Kusuda) writes:

>In article dim@felix.seas.gwu.edu, mfeldman@seas.gwu.edu (Michael Feldman) writes:

>[snip]

>>The named association is very convenient in teaching about parameters,
>>and makes for nice readable code (IMHO, of course), but in general is
>>really "syntactic sugar." 

>I agree with Michael's points regarding named parameter association.  But the named
>parameter association is also necessary to:

>  a) Specify the parameter list in an arbitrary order--I think this is a weak point
>     as far as readability/maintainability, but still a point.

I don't know that I agree here.  Sometimes things 'read' better from the 
caller point of view if you can reorder the parameters.

>  b) Omit parameters which have default values.  I think that this is very useful,
>     too bad C++ doesn't have the same thing.

I quite agree.  The other thing I wish C++ would 'borrow' from Ada is the 
whole idea of rep specs.  There are applications where it is definitely handy 
to be able to specify exactly how many bits an object should occupy and just 
how its components should be laid out.

Re: Syntax question

[Spencer Allain]

In article <3k87i7$q7g@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM (David Weller) writes:

   In article <3k7t8o$4pt@hacgate2.hac.com>,
   David Kusuda <dkusu@atc-1s.hac.com> wrote:
   >  b) Omit parameters which have default values.  I think that this 
   >     is very useful, too bad C++ doesn't have the same thing.
   >

   It does, too!  All you hafta do is add another member function with
   the new parameter list.  After that, all it is is just another
   recompile :-)

Just as a clarification, not as a defense, C++ does allow omission of defaulted
parameters.

The function declared as

void func(int first,
          int second = 2,
          int third  = 3) ;

can be accessed in any of the three following ways.

    func(4, 5, 6) ;
    func(4, 5) ;
    func(4) ;

What you cannot do is something of this nature,

    func(4, third:6);

since binding of variables is purely positional, and there is no such thing
as the "third:" syntax shown above.

This is what I assume was referred to when mentioning that C++ was unable
to omit (intermediate) parameters with default values.

Spencer Allain <spencer@era.com>
Engineering Research Associates
Vienna, VA  22182

Re: Syntax question

[Adam Beneschan]

etlghh@garbo.ericsson.se (Geoffrey Hollingworth) writes:
>Hi
>
>I am currently researching into real time languages and hope
>you ada experts can explain something to me.  I apologise for
>my lack of knowledge in ada.
>When binding formal parameters with actual parameters the '=>'
>operator is used, irrespective of whether the formal parameter
>is declared as IN, INOUT or OUT.  Is there a reason for this ?
>If I proposed an alternative syntax where "=>" indicated the FP
>was an IN parameter, "<=" to indicate an OUT parameter and "<=>"
>to indicate an INOUT.
>Then the caller of the procedure/function would have explicitly
>had to understand to direction of the parameters and at the same
>time increased the readability of his/her code.
>Is there a fundamental flaw in this line of thinking ?
>Does ada manage this problem via a different mechanism ?

The main flaw with your proposal is that <= already has a meaning
(less than or equal).  Other than that, though, I think it would have
been a good idea.

I seem to remember that an early definition of Ada, while the language
definition was still in the works, used := for IN parameters, =: for
OUT (or was it vice versa?), and :=: for IN OUT.  Does anyone else
remember this, or know why the idea was scrapped?

                                -- Adam

Re: Syntax question

[Norman H. Cohen]

In article <D5D3t9.7nL@thomsoft.com>, kst@thomsoft.com (Keith Thompson) writes: 

|> Some versions of preliminary Ada (1979, possibly 1980) used ":=", "=:",
|> and ":=:" for named associations for in, out, and in out parameters,
|> respectively.  This was changed to "=>" for all three modes.  As others
|> have mentioned, this applies only to named notation; in positional
|> notation you just write the actual expressions or names separated
|> by commas.

It was in Preliminary Ada (1979) and gone by 1980.  I believe the
rationale for removing it was "syntactic uniformity".  Too bad:  When I
first saw the Preliminary Ada RM, this innovation really excited me.
Anyone who's spent time reading and trying to understand someone else's
code knows how important it is to understand which actual parameters are
set by a call, and which are expected to have been set beforehand.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Syntax question

[Niklas Holsti]

In <3k7t8o$4pt@hacgate2.hac.com> dkusu@atc-1s.hac.com (David Kusuda)
writes, among other things:

>I agree with Michael's points regarding named parameter association. 
>But the named parameter association is also necessary to:

>  a) Specify the parameter list in an arbitrary order--I think this is a weak point
>     as far as readability/maintainability, but still a point.

Named parameter association can also help maintenance. Recently, for
peculiar and irrelevant reasons we changed the declaration of a
subprogram from P (X: in Some_Type; Y: in Some_Type) to
P (Y: in Some_Type; X: in Some_Type). Since our coding rules require
named parameter association for all calls, we could do this without
searching for and correcting all calls to P. The _meaning_ of X
and Y was not changed, just their order in the parameter list.

>Dave

Niklas Holsti
Working but not speaking for Space Systems Finland Ltd
--
Niklas Holsti                         
    Space Systems Finland Ltd, phone +358 0 4354 3928
    Tekniikantie 12, P.O. Box 324, FIN-02151 Espoo, Finland

Re: Syntax question

[Robert Dewar]

"It does, too!  All you hafta do is add another member function with
the new parameter list.  After that, all it is is just another
recompile :-)"

David says, complaining that it is unfair to criticize C++ for not
having default parameters.

You haven't seen some of the complex parameter lists I have! Either that
or 2**K different member functions for large values of K doesn't worry
you!

Re: Syntax question

[Robert Dewar]

Of course Niklas, we have to ask, if you always use named notation, then
why on earth would you make a maintenance change altering the order of
parameters and forcing recompilation of all the clients :-)

Re: Syntax question

[Robert Dewar]

Well it shows how different people react to things, I really HATED the
:= and :=: trick, I thought they were typical of the kind of 
"fiddle-with-special-characters" games that ruin the syntax of many
languages, and I think it is a good thing they were dropped. In practice
I think that proper choice of parameter names and use of named notation
meets the needs just find.

Re: Syntax question

[Bob Collins]

In article <3jt5je$d0u@pip.shsu.edu> stdsee01@pip.shsu.edu (Road Pilot) writes:
>Geoffrey Hollingworth (etlghh@garbo.ericsson.se) wrote:
>: [snip]
>: When binding formal parameters with actual parameters the '=>'
>: operator is used, irrespective of whether the formal parameter
>: is declared as IN, INOUT or OUT.  Is there a reason for this ?
>: [snip]
>Well, the arrow symbol "=>" is not meant to imply direction.  It is used in
>the case statement (ex: WHEN choice => statement) and in aggregate assingments
> [snip]
>I don't know if this helps any or just confuses more, but I guess the main
>thing is that the arrow is more like a placeholder or referencing tool and
>is not meant to imply direction.

At the Ada debut in 1979 or 80 (memory cell problem), I asked Jean
Ishbiah how to pronounce the symbol "=>." He said it was supposed to
be like a pointing hand, and so he recommended pronouncing it as
"finger." If you needed to know ...

Bob Collins, collins@cs.wm.edu

Re: Syntax question

[Kevin F. Quinn]

In article <1995Mar23.130736.19109@cs.wm.edu>,
          collins@cs.wm.edu (Bob Collins) wrote:

> I asked Jean Ishbiah how to pronounce the symbol "=>." He said it
> was supposed to be like a pointing hand, and so he recommended
> pronouncing it as "finger." If you needed to know ...

Well call me a boring old chap, but I always say "is", for what it's
worth...

-- 
Kevin F. Quinn           * "That's not what you said when you sent him your
kevq@banana.demon.co.uk  * Navel."   "Novel, Baldrick, not navel."
kevq@cix.compulink.co.uk * "Well it sounds like a case of soggy grapefruits
Compu$erve: 100025,1525  * to me..."                        BlackAdder III
... I appreciate your not breathing while I smoke.

Re: Syntax question

[Norman H. Cohen]

In article <19950324.011135.49@banana.demon.co.uk>, kevq@banana.demon.co.uk
(Kevin F. Quinn) writes: 

|> In article <1995Mar23.130736.19109@cs.wm.edu>,
|>           collins@cs.wm.edu (Bob Collins) wrote: 
|>
|> > I asked Jean Ishbiah how to pronounce the symbol "=>." He said it
|> > was supposed to be like a pointing hand, and so he recommended
|> > pronouncing it as "finger." If you needed to know ...
|>
|> Well call me a boring old chap, but I always say "is", for what it's
|> worth...

I think we had better call in Victor Borge as a consultant.  (He has a
famous routine in which he reads a story while "pronouncing" all the
punctuation marks, after assigning a variety of tounge clicks, slurps,
giant sucking sounds, and so forth to the comma, period, semicolon, etc.)

--
Norman H. Cohen    ncohen@watson.ibm.com

"Don't laugh: It's YOUR language.  I'm just trying to use it."  -- V. Borge

Syntax Question

[Robby Simpson]

I have some ADA code I am porting to C (I am new to ADA).  What would
the following code mean?

some_var : some_type;

some_var := (some_other_type with attr_x => value1, attr_y => value2);

Robby

Re: Syntax Question

[Marin David Condic]

First off, let me advise you of this: YOU'RE GOING THE WRONG WAY!!! :-)

Why you want to go from Ada (note character case) to C, I do not know, but
it is *definitely* a step backward.

The code you refer to is a case where "some_var" is of a tagged record type
("some_type"). The tagged record type is itself derived from another type in
which it extends the original type with two new fields: attr_x and attr_y.
What you have in the assignment statement is an "aggregate" which is a sort
of literal. It specifies data values to be assigned to some_var that include
values for the extended record fields.

There is no equivalent to this in C.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robby Simpson" <rsimpson@ll.mit.edu> wrote in message
news:3B44AAE3.DB048BC8@ll.mit.edu...
> I have some ADA code I am porting to C (I am new to ADA).  What would
> the following code mean?
>
> some_var : some_type;
>
> some_var := (some_other_type with attr_x => value1, attr_y => value2);
>
> Robby

Re: Syntax Question

[Robby Simpson]

Actually, some_other_type is really a variable of a different type.  I
believe that some_var is a derived type and it is copying
some_other_type's attributes and then adding more.  Is this correct?

Thanks,
Robby

Robby Simpson wrote:
> 
> I have some ADA code I am porting to C (I am new to ADA).  What would
> the following code mean?
> 
> some_var : some_type;
> 
> some_var := (some_other_type with attr_x => value1, attr_y => value2);
> 
> Robby

Re: Syntax Question

[Ted Dennison]

In article <3B44AAE3.DB048BC8@ll.mit.edu>, Robby Simpson says...
>
>I have some ADA code I am porting to C (I am new to ADA).  What would
>the following code mean?
>
>some_var : some_type;
>
>some_var := (some_other_type with attr_x => value1, attr_y => value2);

That's a type extension (and "some_other_type" should probably be
"some_other_var"). I hope you mean you are porting it to C++, because C has
little or no support for OO programming, and *no* direct analog to this. You
might just as well try porting C to assembly as porting Object-Oriented Ada to
C.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Syntax Question

[Robby Simpson]

Thanks for the info/advice.  And I guess I should have been more clear,
I am porting it to C++.

Robby

Ted Dennison wrote:
> 
> In article <3B44AAE3.DB048BC8@ll.mit.edu>, Robby Simpson says...
> >
> >I have some ADA code I am porting to C (I am new to ADA).  What would
> >the following code mean?
> >
> >some_var : some_type;
> >
> >some_var := (some_other_type with attr_x => value1, attr_y => value2);
> 
> That's a type extension (and "some_other_type" should probably be
> "some_other_var"). I hope you mean you are porting it to C++, because C has
> little or no support for OO programming, and *no* direct analog to this. You
> might just as well try porting C to assembly as porting Object-Oriented Ada to
> C.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Syntax Question

[Robert Dewar]

Robby Simpson <rsimpson@ll.mit.edu> wrote in message news:<3B44AAE3.DB048BC8@ll.mit.edu>...
> I have some ADA code I am porting to C (I am new to ADA).  What would
> the following code mean?
> 
> some_var : some_type;
> 
> some_var := (some_other_type with attr_x => value1, attr_y => value2);


Translating complex Ada code to C is a difficult task under the
best of conditions, but trying to do it if you do not know Ada is
likely to be close to impossible. I recommend a thorough study of
Ada (work through one of the online tutorials, and in particular
read a good Ada text book describing the use of tagged types).

Re: Syntax Question

[Robby Simpson]

I have actually been studying ADA for a few months now and have realized
how powerful and easy-to-use it can be, especially in multi-threaded (or
should I say tasking, hehe) environments (especially if you would like
to write code that is actually portable).  To all of those C/C++
programmers out there who would like to learn ADA I must recommend Simon
Johnston's "ADA95 for C and C++ Programmers".  I found that it sped me
along on the way to thoroughly understanding ADA and the only thing that
I found it left out was the simple below code, which, thanks to this
newsgroup, I now understand.

Robby

Robert Dewar wrote:
> 
> Robby Simpson <rsimpson@ll.mit.edu> wrote in message news:<3B44AAE3.DB048BC8@ll.mit.edu>...
> > I have some ADA code I am porting to C (I am new to ADA).  What would
> > the following code mean?
> >
> > some_var : some_type;
> >
> > some_var := (some_other_type with attr_x => value1, attr_y => value2);
> 
> Translating complex Ada code to C is a difficult task under the
> best of conditions, but trying to do it if you do not know Ada is
> likely to be close to impossible. I recommend a thorough study of
> Ada (work through one of the online tutorials, and in particular
> read a good Ada text book describing the use of tagged types).