* Pondering what rationale behind record type @ 2011-05-09 17:47 Anh Vo 2011-05-09 18:59 ` Adam Beneschan ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Anh Vo @ 2011-05-09 17:47 UTC (permalink / raw) Some time I am wondering why record type has different syntax pattern than the rest with respect to type ending text. That is it ends with 'end record;' no matter what the identifier is. The rest of others end with 'end identifier'. Below are examples regarding this subject. type Data is record X_Coord : Integer := 0; Y_Coord : Integer := 0; -- more components end record; task type Event_Monitor is entry Start; entry Process (...) end Event_Monitor; Anh Vo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 17:47 Pondering what rationale behind record type Anh Vo @ 2011-05-09 18:59 ` Adam Beneschan 2011-05-09 19:51 ` Niklas Holsti 2011-05-09 20:49 ` Randy Brukardt 2011-05-19 9:50 ` J-P. Rosen 2011-05-20 6:10 ` anon 2 siblings, 2 replies; 20+ messages in thread From: Adam Beneschan @ 2011-05-09 18:59 UTC (permalink / raw) On May 9, 10:47 am, Anh Vo <anhvofrc...@gmail.com> wrote: > Some time I am wondering why record type has different syntax pattern > than the rest with respect to type ending text. That is it ends with > 'end record;' no matter what the identifier is. The rest of others end > with 'end identifier'. Below are examples regarding this subject. > > type Data is record > X_Coord : Integer := 0; > Y_Coord : Integer := 0; > -- more components > end record; > > task type Event_Monitor is > entry Start; > entry Process (...) > end Event_Monitor; Heh ... good question. I have to say I get tripped up by this a lot; I type things like "type Some_Type is record ... end Some_Type;" fairly frequently, and sometimes I don't catch it before the compiler does. Maybe the BNF gives a clue. In Ada 83, the "task type" and "end" were part of the same syntax definition, so it was clear that the "end" ended the "task type" and thus sort of belonged to it; while the "record" and "end record" keywords were part of the "record_type_definition" syntax rule, which is separate from the rule that contains "type identifier [discriminant_part] is type_definition;", so maybe they didn't want an "end" in one syntax rule to refer to something in another rule. Just a wild guess, but perhaps that's the rationale for the original syntax. (Note that this doesn't apply in Ada 95+ since the "end" of a task type is now in a different syntax rule. I'm just speculating about the original rationale.) -- Adam ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 18:59 ` Adam Beneschan @ 2011-05-09 19:51 ` Niklas Holsti 2011-05-09 20:02 ` Dmitry A. Kazakov 2011-05-09 20:49 ` Randy Brukardt 1 sibling, 1 reply; 20+ messages in thread From: Niklas Holsti @ 2011-05-09 19:51 UTC (permalink / raw) Adam Beneschan wrote: > On May 9, 10:47 am, Anh Vo <anhvofrc...@gmail.com> wrote: >> Some time I am wondering why record type has different syntax pattern >> than the rest with respect to type ending text. That is it ends with >> 'end record;' no matter what the identifier is. The rest of others end >> with 'end identifier'. Below are examples regarding this subject. >> >> type Data is record >> X_Coord : Integer := 0; >> Y_Coord : Integer := 0; >> -- more components >> end record; >> >> task type Event_Monitor is >> entry Start; >> entry Process (...) >> end Event_Monitor; > > Heh ... good question. I have to say I get tripped up by this a lot; > I type things like "type Some_Type is record ... end Some_Type;" > fairly frequently, and sometimes I don't catch it before the compiler > does. I make that mistake often, too. I would vote for a change in the language to allow "end Some_Type" as an alternative to "end record". -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 19:51 ` Niklas Holsti @ 2011-05-09 20:02 ` Dmitry A. Kazakov 2011-05-09 20:12 ` Anh Vo 0 siblings, 1 reply; 20+ messages in thread From: Dmitry A. Kazakov @ 2011-05-09 20:02 UTC (permalink / raw) On Mon, 09 May 2011 22:51:42 +0300, Niklas Holsti wrote: > Adam Beneschan wrote: >> Heh ... good question. I have to say I get tripped up by this a lot; >> I type things like "type Some_Type is record ... end Some_Type;" >> fairly frequently, and sometimes I don't catch it before the compiler >> does. > > I make that mistake often, too. I would vote for a change in the > language to allow "end Some_Type" as an alternative to "end record". Count me in. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 20:02 ` Dmitry A. Kazakov @ 2011-05-09 20:12 ` Anh Vo 2011-05-09 22:03 ` Georg Bauhaus 0 siblings, 1 reply; 20+ messages in thread From: Anh Vo @ 2011-05-09 20:12 UTC (permalink / raw) On May 9, 1:02 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Mon, 09 May 2011 22:51:42 +0300, Niklas Holsti wrote: > > Adam Beneschan wrote: > >> Heh ... good question. I have to say I get tripped up by this a lot; > >> I type things like "type Some_Type is record ... end Some_Type;" > >> fairly frequently, and sometimes I don't catch it before the compiler > >> does. > > > I make that mistake often, too. I would vote for a change in the > > language to allow "end Some_Type" as an alternative to "end record". > > Count me in. I am in automatically. I am hoping that it is still time to put it in Ada 2012. Of course, we need to hear from Randy, Tucker and others first. Anh Vo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 20:12 ` Anh Vo @ 2011-05-09 22:03 ` Georg Bauhaus 2011-05-10 7:45 ` Dmitry A. Kazakov 0 siblings, 1 reply; 20+ messages in thread From: Georg Bauhaus @ 2011-05-09 22:03 UTC (permalink / raw) On 5/9/11 10:12 PM, Anh Vo wrote: > On May 9, 1:02 pm, "Dmitry A. Kazakov"<mail...@dmitry-kazakov.de> > wrote: >> On Mon, 09 May 2011 22:51:42 +0300, Niklas Holsti wrote: >>> Adam Beneschan wrote: >>>> Heh ... good question. I have to say I get tripped up by this a lot; >>>> I type things like "type Some_Type is record ... end Some_Type;" >>>> fairly frequently, and sometimes I don't catch it before the compiler >>>> does. >> >>> I make that mistake often, too. I would vote for a change in the >>> language to allow "end Some_Type" as an alternative to "end record". >> >> Count me in. > > I am in automatically. > > I am hoping that it is still time to put it in Ada 2012. Of course, we > need to hear from Randy, Tucker and others first. I'll advocate (and speculate) against, even though I frequently type "end R" when I should type "end record" (of have my editor expand it for me). There might be a fix, though. I'll list a few points that refer to bracketing constructs that I think are nicely specific. They make "end record" a logical choice, but not "end R". First, in the phrase "end X", the "X" part can usually be omitted. To have just "end [R]" in record declarations is less specific (specifically finishing off record declarations), and less informative than "end record". Second, in "end [X]", where X is a name, the corresponding left bracket for "end" either is "begin" or we have seen something that wraps around declarations of callable constructs, if I'm not missing something. So whenever we put "record" (or "case", or "if", etc) after an "end", this is delimiting a bracketed construct that is neither a block nor a {package, task, protected}. A piece of syntax that helps the reader keeping different things apart. By reversing things for reasons of contrasting the options, assume "package ... end package;" is suggested as a replacement of the current syntax. Wouldn't you instead want "package P ... end package P;" instead? Fortran and ParaSail have these conventions, I think. Consequently, how about this addition to the syntax of record declarations: type R is record ... end record R; ? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 22:03 ` Georg Bauhaus @ 2011-05-10 7:45 ` Dmitry A. Kazakov 2011-05-10 10:12 ` Georg Bauhaus 0 siblings, 1 reply; 20+ messages in thread From: Dmitry A. Kazakov @ 2011-05-10 7:45 UTC (permalink / raw) On Tue, 10 May 2011 00:03:37 +0200, Georg Bauhaus wrote: > First, in the phrase "end X", the "X" part can usually be omitted. That is another fix to do: a default profile which would forbid omitting the name. I saw no Ada program in my life which omitted names in the ends. > So whenever we put "record" (or "case", or "if", etc) after an "end", These are anonymous constructs. The only reason why record bracket should not contain its name is when there is no name, e.g. as Randy has pointed out, in an anonymous record type. They are illegal in Ada, but an imaginary example could be: function Get_Token (File : File_Type) return (Matched : Boolean; Length : Positive) record case Matched is when True => Token : String (1..Length); when False => null; end case; end record; The result is this anonymous record: type <anonymous> (Matched : Boolean; Length : Positive) is record case Matched is when True => Token : String (1..Length); when False => null; end case; end record; We could continue the exercise with other types: function Get_Handle (...) return new Ada.Finalization.Controlled with record ... end record; function Get_List (...) return array (Positive range <>) of Element; Do you like it? (:-)) > Consequently, how about this addition to the syntax of record > declarations: > > type R is > record > ... > end record R; > > ? Shudder. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-10 7:45 ` Dmitry A. Kazakov @ 2011-05-10 10:12 ` Georg Bauhaus 2011-05-10 12:08 ` Dmitry A. Kazakov 0 siblings, 1 reply; 20+ messages in thread From: Georg Bauhaus @ 2011-05-10 10:12 UTC (permalink / raw) On 10.05.11 09:45, Dmitry A. Kazakov wrote: > On Tue, 10 May 2011 00:03:37 +0200, Georg Bauhaus wrote: > >> First, in the phrase "end X", the "X" part can usually be omitted. > > That is another fix to do: a default profile which would forbid omitting > the name. I saw no Ada program in my life which omitted names in the ends. > >> So whenever we put "record" (or "case", or "if", etc) after an "end", > > These are anonymous constructs. Though a loop can have a name. Anything wrong with (i.e. makes you shudder) Label_A: loop ... end loop Label_A; ? > The only reason why record bracket should > not contain its name is when there is no name, e.g. as Randy has pointed > out, in an anonymous record type. They are illegal in Ada, but an imaginary > example could be: > > function Get_Token (File : File_Type) return > (Matched : Boolean; Length : Positive) record > ... In order to be competitive in the current discussion, pro "end [X]", the example would have to be type Get_Token is function (File : File_Type) return ((Matched : Boolean; Length : Positive) record case Matched is when True => Token : String (1..Length); when False => null; end case; end record) end Get_Token; ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-10 10:12 ` Georg Bauhaus @ 2011-05-10 12:08 ` Dmitry A. Kazakov 2011-05-10 12:18 ` Georg Bauhaus 0 siblings, 1 reply; 20+ messages in thread From: Dmitry A. Kazakov @ 2011-05-10 12:08 UTC (permalink / raw) On Tue, 10 May 2011 12:12:10 +0200, Georg Bauhaus wrote: > On 10.05.11 09:45, Dmitry A. Kazakov wrote: >> On Tue, 10 May 2011 00:03:37 +0200, Georg Bauhaus wrote: >> >>> First, in the phrase "end X", the "X" part can usually be omitted. >> >> That is another fix to do: a default profile which would forbid omitting >> the name. I saw no Ada program in my life which omitted names in the ends. >> >>> So whenever we put "record" (or "case", or "if", etc) after an "end", >> >> These are anonymous constructs. > > Though a loop can have a name. > > Anything wrong with (i.e. makes you shudder) > > Label_A: loop > ... > end loop Label_A; > > ? loop A do ... end A; >> The only reason why record bracket should >> not contain its name is when there is no name, e.g. as Randy has pointed >> out, in an anonymous record type. They are illegal in Ada, but an imaginary >> example could be: >> >> function Get_Token (File : File_Type) return >> (Matched : Boolean; Length : Positive) record >> ... > > In order to be competitive in the current discussion, > pro "end [X]", the example would have to be > > type Get_Token is function (File : File_Type) return > ((Matched : Boolean; Length : Positive) record > case Matched is > when True => Token : String (1..Length); > when False => null; > end case; > end record) > end Get_Token; No, Get_Token would be a function-type. E.g. type Func is function (X : Float) return Float; Then function Integrate (...; What : Func) return Float; Which could be be anonymous as well: function Integrate (...; What : function (X : Float) return Float) return Float; Or the example with Get_Token: procedure Parse ( File : File_Type; Get_Token : function (File : File_Type) return ((Matched : Boolean; Length : Positive) record case Matched is when True => Token : String (1..Length); when False => null; end case; end record ); -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-10 12:08 ` Dmitry A. Kazakov @ 2011-05-10 12:18 ` Georg Bauhaus 2011-05-10 12:50 ` Dmitry A. Kazakov 0 siblings, 1 reply; 20+ messages in thread From: Georg Bauhaus @ 2011-05-10 12:18 UTC (permalink / raw) On 10.05.11 14:08, Dmitry A. Kazakov wrote: >> Anything wrong with (i.e. makes you shudder) >> >> Label_A: loop >> ... >> end loop Label_A; >> >> ? > > loop A do > ... > end A; Consequently, if ... then A do ... else ... end A; I guess? >> type Get_Token is function (File : File_Type) return >> ((Matched : Boolean; Length : Positive) record >> case Matched is >> when True => Token : String (1..Length); >> when False => null; >> end case; >> end record) >> end Get_Token; > > No, Get_Token would be a function-type. Yes. It was suggested that the meat part of type declarations should end in "end [X]", not "end keyword", so that > E.g. type Func is function (X : Float) return Float; end Func; ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-10 12:18 ` Georg Bauhaus @ 2011-05-10 12:50 ` Dmitry A. Kazakov 2011-05-10 14:20 ` Martin 2011-05-11 2:28 ` Shark8 0 siblings, 2 replies; 20+ messages in thread From: Dmitry A. Kazakov @ 2011-05-10 12:50 UTC (permalink / raw) On Tue, 10 May 2011 14:18:28 +0200, Georg Bauhaus wrote: > On 10.05.11 14:08, Dmitry A. Kazakov wrote: > >>> Anything wrong with (i.e. makes you shudder) >>> >>> Label_A: loop >>> ... >>> end loop Label_A; >>> >>> ? >> >> loop A do >> ... >> end A; > > Consequently, > > if ... then A do > ... > else > ... > end A; > > I guess? What is the reason to name statements? But if you wanted to, it would be if A do <condition> then ... else ... end A; >>> type Get_Token is function (File : File_Type) return >>> ((Matched : Boolean; Length : Positive) record >>> case Matched is >>> when True => Token : String (1..Length); >>> when False => null; >>> end case; >>> end record) >>> end Get_Token; >> >> No, Get_Token would be a function-type. > > Yes. It was suggested that the meat part of type declarations > should end in "end [X]", not "end keyword", so that > >> E.g. > > type Func is > function (X : Float) return Float; > end Func; No, because here there is no left bracket that follows "is". Compare type String is array (...) of ...; The type declaration syntax is: type <name> is <definition>; <definition> can be: 1. plain, e.g. private; range ...; delta ...; array; access ...; mod ... 2. nested, like task, record, protected object. Their declarations are unfortunately irregular. They should have been type Worker is task ... end Worker; type Mutex is protected ... end Mutex; type Data is record ... end Data; Of course one could deploy the alternative schema: <class-name> type <name> is <definition>; E.g. task type A is ... end A; record type B is ... end B; array type String is (Positive range <>) of Character; range type Integer is -2**31-1..2**31-1; But mixing them was a bad idea. P.S. task and protected should have been record types with entries being primitive operations. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-10 12:50 ` Dmitry A. Kazakov @ 2011-05-10 14:20 ` Martin 2011-05-11 7:32 ` Dmitry A. Kazakov 2011-05-11 2:28 ` Shark8 1 sibling, 1 reply; 20+ messages in thread From: Martin @ 2011-05-10 14:20 UTC (permalink / raw) On May 10, 1:50 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Tue, 10 May 2011 14:18:28 +0200, Georg Bauhaus wrote: > > On 10.05.11 14:08, Dmitry A. Kazakov wrote: > > >>> Anything wrong with (i.e. makes you shudder) > > >>> Label_A: loop > >>> ... > >>> end loop Label_A; > > >>> ? > > >> loop A do > >> ... > >> end A; > > > Consequently, > > > if ... then A do > > ... > > else > > ... > > end A; > > > I guess? > > What is the reason to name statements? But if you wanted to, it would be > > if A do <condition> then > ... > else > ... > end A; > > > > > > > > > > >>> type Get_Token is function (File : File_Type) return > >>> ((Matched : Boolean; Length : Positive) record > >>> case Matched is > >>> when True => Token : String (1..Length); > >>> when False => null; > >>> end case; > >>> end record) > >>> end Get_Token; > > >> No, Get_Token would be a function-type. > > > Yes. It was suggested that the meat part of type declarations > > should end in "end [X]", not "end keyword", so that > > >> E.g. > > > type Func is > > function (X : Float) return Float; > > end Func; > > No, because here there is no left bracket that follows "is". Compare > > type String is array (...) of ...; > > The type declaration syntax is: > > type <name> is <definition>; > > <definition> can be: > > 1. plain, e.g. private; range ...; delta ...; array; access ...; mod ... > > 2. nested, like task, record, protected object. Their declarations are > unfortunately irregular. They should have been > > type Worker is task ... end Worker; > type Mutex is protected ... end Mutex; > type Data is record ... end Data; > > Of course one could deploy the alternative schema: > > <class-name> type <name> is <definition>; > > E.g. > > task type A is ... end A; > record type B is ... end B; > array type String is (Positive range <>) of Character; > range type Integer is -2**31-1..2**31-1; > > But mixing them was a bad idea. > > P.S. task and protected should have been record types with entries being > primitive operations. > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de Doesn't 'type' become redundant at this point?... -- Martin ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-10 14:20 ` Martin @ 2011-05-11 7:32 ` Dmitry A. Kazakov 0 siblings, 0 replies; 20+ messages in thread From: Dmitry A. Kazakov @ 2011-05-11 7:32 UTC (permalink / raw) On Tue, 10 May 2011 07:20:21 -0700 (PDT), Martin wrote: [...] > Doesn't 'type' become redundant at this point?... At which point? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-10 12:50 ` Dmitry A. Kazakov 2011-05-10 14:20 ` Martin @ 2011-05-11 2:28 ` Shark8 2011-05-11 7:32 ` Dmitry A. Kazakov 1 sibling, 1 reply; 20+ messages in thread From: Shark8 @ 2011-05-11 2:28 UTC (permalink / raw) On May 10, 7:50 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > What is the reason to name statements? Simple: to aid in readability. I have a few rather deeply nested items where I'm tokenizing PostScript (due the rules of the language) and it is handy to have things like -- Case C, When C '<' => Read_Character( C, Input ); HANDLE_LT: -- less than if C = '<' then Return Dictionary_Type; elsif C = '~' then Return String_Type; else Unread_Character( C, Input ); Return -- I forgot what the last case, just '<', was... end if HANDLE_LT; There's even a few in blocks where I handle things like names ['identifiers'] vs. numbers; the PLRM defines a name as a string of "regular characters which cannot be interpreted as a string." This means that 23E4 is a number while 24F4 is a name as are $4, 2i3, @, 2^4 and so forth. It REALLY does help in sorting where you are in the decoding. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-11 2:28 ` Shark8 @ 2011-05-11 7:32 ` Dmitry A. Kazakov 2011-05-18 22:55 ` Shark8 0 siblings, 1 reply; 20+ messages in thread From: Dmitry A. Kazakov @ 2011-05-11 7:32 UTC (permalink / raw) On Tue, 10 May 2011 19:28:16 -0700 (PDT), Shark8 wrote: > On May 10, 7:50�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> >> What is the reason to name statements? > > Simple: to aid in readability. > I have a few rather deeply nested items where I'm tokenizing > PostScript > (due the rules of the language) and it is handy to have things like > -- Case C, When C '<' => > Read_Character( C, Input ); > HANDLE_LT: -- less than > if C = '<' then > Return Dictionary_Type; > elsif C = '~' then > Return String_Type; > else > Unread_Character( C, Input ); > Return -- I forgot what the last case, just '<', was... > end if HANDLE_LT; The above should have been a "case", or better matching the input against a token table with semantic callbacks doing things. > There's even a few in blocks where I handle things like > names ['identifiers'] vs. numbers; the PLRM defines a name > as a string of "regular characters which cannot be interpreted > as a string." This means that 23E4 is a number while 24F4 is > a name as are $4, 2i3, @, 2^4 and so forth. That is semantic analysis to me. No need to burden parser with that. You parse 23E4 as a token and later interpret it as an identifier or number. > It REALLY does help in sorting where you are in the decoding. I don't think that large "if"s is a good style. No names may help that. BTW, in your case "then", "else", "elsif" must carry the name of the "if" they belong. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-11 7:32 ` Dmitry A. Kazakov @ 2011-05-18 22:55 ` Shark8 2011-05-19 8:12 ` Dmitry A. Kazakov 0 siblings, 1 reply; 20+ messages in thread From: Shark8 @ 2011-05-18 22:55 UTC (permalink / raw) On May 11, 2:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Tue, 10 May 2011 19:28:16 -0700 (PDT), Shark8 wrote: > > On May 10, 7:50 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > > wrote: > > >> What is the reason to name statements? > > > Simple: to aid in readability. > > I have a few rather deeply nested items where I'm tokenizing > > PostScript > > (due the rules of the language) and it is handy to have things like > > -- Case C, When C '<' => > > Read_Character( C, Input ); > > HANDLE_LT: -- less than > > if C = '<' then > > Return Dictionary_Type; > > elsif C = '~' then > > Return String_Type; > > else > > Unread_Character( C, Input ); > > Return -- I forgot what the last case, just '<', was... > > end if HANDLE_LT; > > The above should have been a "case", or better matching the input against a > token table with semantic callbacks doing things. > > > There's even a few in blocks where I handle things like > > names ['identifiers'] vs. numbers; the PLRM defines a name > > as a string of "regular characters which cannot be interpreted > > as a string." This means that 23E4 is a number while 24F4 is > > a name as are $4, 2i3, @, 2^4 and so forth. > > That is semantic analysis to me. No need to burden parser with that. You > parse 23E4 as a token and later interpret it as an identifier or number. True, it is semantic analysis. The way I have it set up is this case structure is inside my tokenizer; the tokenizer may or may not be on the same machine as the parser itself. One of the reasons that I'm forced to use if-statements in the cases for the various constructs is because some of them are dependent on state: Strings, for example are delimited with parentheses, BUT may contain balanced pairs or be escaped out. So, (Here we are (nowhere).) is equal to the Ada String "Here we are (nowhere)." A quick/easy "go to the next closing paren" will produce incorrect results, just as it would in the string (:/)) which is equal the Ada String ":)". Finally, the case I was writing from memory, the [first] less-than can be: 1 - The first part of the "<<", a Dictionary, which is self- delimiting. 2 - The first part of the "<~", which is a Hex-encoded String (IIRC). 3 - I still can't remember what just '<' was... > > It REALLY does help in sorting where you are in the decoding. > > I don't think that large "if"s is a good style. No names may help that. > BTW, in your case "then", "else", "elsif" must carry the name of the "if" > they belong. I don't either; but the PLRM does describe the parser as consuming the characters/tokens from the input and then producing the proper object*. Also, I want to have the ability to have the parser a separate component, likely a server on a remote-machine handling multiple clients, and that imposes its own constraints as well. * Not as in OOP-Object, but as in component... though you could use OOP. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-18 22:55 ` Shark8 @ 2011-05-19 8:12 ` Dmitry A. Kazakov 0 siblings, 0 replies; 20+ messages in thread From: Dmitry A. Kazakov @ 2011-05-19 8:12 UTC (permalink / raw) On Wed, 18 May 2011 15:55:03 -0700 (PDT), Shark8 wrote: > One of the reasons that I'm forced to use if-statements in the cases for > the various constructs is because some of them are dependent on state: > Strings, for example are delimited with parentheses, BUT may contain > balanced pairs or be escaped out. > > So, (Here we are (nowhere).) is equal to the Ada String "Here we are > (nowhere)." > A quick/easy "go to the next closing paren" will produce incorrect > results, > just as it would in the string (:/)) which is equal the Ada String > ":)". I see, I likely would do this differently as well. Either brackets are parts of an expression to be evaluated later or a part of a literal expression handled by a recursively descend part (i.e. in a physically different case-statement). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 18:59 ` Adam Beneschan 2011-05-09 19:51 ` Niklas Holsti @ 2011-05-09 20:49 ` Randy Brukardt 1 sibling, 0 replies; 20+ messages in thread From: Randy Brukardt @ 2011-05-09 20:49 UTC (permalink / raw) "Adam Beneschan" <adam@irvine.com> wrote in message news:90148303-4dc4-4c05-882f-88dd69a95494@z13g2000prk.googlegroups.com... On May 9, 10:47 am, Anh Vo <anhvofrc...@gmail.com> wrote: >> Some time I am wondering why record type has different syntax pattern >> than the rest with respect to type ending text. ... >Heh ... good question. I have to say I get tripped up by this a lot; >I type things like "type Some_Type is record ... end Some_Type;" >fairly frequently, and sometimes I don't catch it before the compiler >does. > >Maybe the BNF gives a clue. In Ada 83, the "task type" and "end" were >part of the same syntax definition, so it was clear that the "end" >ended the "task type" and thus sort of belonged to it; while the >"record" and "end record" keywords were part of the >"record_type_definition" syntax rule, which is separate from the rule >that contains "type identifier [discriminant_part] is >type_definition;", so maybe they didn't want an "end" in one syntax >rule to refer to something in another rule. Just a wild guess, but >perhaps that's the rationale for the original syntax. (Note that this >doesn't apply in Ada 95+ since the "end" of a task type is now in a >different syntax rule. I'm just speculating about the original >rationale.) I would guess that you have most of the reason. My guess (and I don't know anything more about this than you do) is that the definition syntax exists to allow for anonymous types. If you had an anonymous record type, it would be hard to write the matching identifier. :-) But most of the anonymous types were stripped out of Ada early on, because they caused problems with where declarations happened (think about the rules of 7.3.1 applied to nested, anonymous types - gag!) And they forgot to change the syntax. Every once in a while, someone has suggested some sort of fix for this syntax glitch (I think it affects everyone), but we've never actually followed through. Probably someone should send a request to Ada-Comment so it makes it onto an agenda someday. Randy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 17:47 Pondering what rationale behind record type Anh Vo 2011-05-09 18:59 ` Adam Beneschan @ 2011-05-19 9:50 ` J-P. Rosen 2011-05-20 6:10 ` anon 2 siblings, 0 replies; 20+ messages in thread From: J-P. Rosen @ 2011-05-19 9:50 UTC (permalink / raw) Le 09/05/2011 19:47, Anh Vo a �crit : > Some time I am wondering why record type has different syntax pattern > than the rest with respect to type ending text. That is it ends with > 'end record;' no matter what the identifier is. The rest of others end > with 'end identifier'. 'if' ends with 'end if', 'loop' ends with 'end loop'... Granted, if the loop is named, then it ends with 'end loop L'. So, maybe the perfect solution would be 'end record Rec' - but some would find that too much. TBH, there is not always a strong rationale to issues related with concrete syntax. It reflects the feeling, ideas, and sense of aesthetic of the design team. These may vary with people, but also over time: in the 80s, it was considered good practice to have variables in all caps, now it is regarded as shouting. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Adalog a d�m�nag� / Adalog has moved: 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Pondering what rationale behind record type 2011-05-09 17:47 Pondering what rationale behind record type Anh Vo 2011-05-09 18:59 ` Adam Beneschan 2011-05-19 9:50 ` J-P. Rosen @ 2011-05-20 6:10 ` anon 2 siblings, 0 replies; 20+ messages in thread From: anon @ 2011-05-20 6:10 UTC (permalink / raw) All specification for executable units that have both public and private declarations such as task and protected (since Ada 95) types have the same basic design. <type> "type" <unit name> [ discriminant part ) is declaration section private declaration section end <unit name> And To change it to now for Ada 2012. For what reason? The difference is the task and protected types defines an executable unit while normally type declarations define data objects. It is easier and less misunderstood to keep the two designs structures separate. And I think it would cause a bigger problem in the Ada programming community. Too many design changes causes too many re-writes of existing code to use on newer systems. Plus, there's the learn curve which as been a big problem for Ada from the start. Every time someone learns a version of Ada there's a new one coming out that contains too many changes with a few changes having no real reason for that change. That happen when Ada first came out. When programmers finally had a working knowledge of Ada 83. Then Ada 95 comes out with some improvement and a lot of changes to Ada 83. And no concern or corrections for compiler checkable "Erroneous Errors". Some Ada programmers spent their time back learning the new rules and rewriting a lot of Ada 83 code. While others say too many new rules and drop Ada for a less altered language like as C. So, you could say this type of concepts is just another nail to hurt Ada. In <e49186b6-9c80-4788-a64f-dd9aba151f02@u26g2000vby.googlegroups.com>, Anh Vo <anhvofrcaus@gmail.com> writes: >Some time I am wondering why record type has different syntax pattern >than the rest with respect to type ending text. That is it ends with >'end record;' no matter what the identifier is. The rest of others end >with 'end identifier'. Below are examples regarding this subject. > >type Data is record > X_Coord : Integer := 0; > Y_Coord : Integer := 0; > -- more components >end record; > >task type Event_Monitor is > entry Start; > entry Process (...) >end Event_Monitor; > >Anh Vo ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-05-20 6:10 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-09 17:47 Pondering what rationale behind record type Anh Vo 2011-05-09 18:59 ` Adam Beneschan 2011-05-09 19:51 ` Niklas Holsti 2011-05-09 20:02 ` Dmitry A. Kazakov 2011-05-09 20:12 ` Anh Vo 2011-05-09 22:03 ` Georg Bauhaus 2011-05-10 7:45 ` Dmitry A. Kazakov 2011-05-10 10:12 ` Georg Bauhaus 2011-05-10 12:08 ` Dmitry A. Kazakov 2011-05-10 12:18 ` Georg Bauhaus 2011-05-10 12:50 ` Dmitry A. Kazakov 2011-05-10 14:20 ` Martin 2011-05-11 7:32 ` Dmitry A. Kazakov 2011-05-11 2:28 ` Shark8 2011-05-11 7:32 ` Dmitry A. Kazakov 2011-05-18 22:55 ` Shark8 2011-05-19 8:12 ` Dmitry A. Kazakov 2011-05-09 20:49 ` Randy Brukardt 2011-05-19 9:50 ` J-P. Rosen 2011-05-20 6:10 ` anon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox