Hi Cristian, What difference do you see between "sys" and "int" in this respect? Both are pre-defined types, and both should not be used as user type names. The current LRM already uses the term "keywords" (without "reserved") as the title to the keywords table, so that's OK. But I start thinking that maybe that table should be removed altogether. (Or else, we would need to update it according to all the other LRM updates we're working on right now - all the newly introduced constructs etc.). That table is purely informative, and it seems to not have any "effect" on the language definition per se. Wherever those keywords are specifically used, they anyway are mentioned in the description of the relevant construct. ("struct" is mentioned in section 6.2 that describes struct definitions, and so on). One more thing. It appears that Specman does treat the following three keywords as reserved, at least partially: TRUE, FALSE, NULL. An attempt to give any of these names to a variable or a type causes a compilation error. Funny is that those three are NOT listed in the table. Yuri. -----Original Message----- From: Cristian Amitroaie [mailto:cristian@amiq.com] Sent: Wednesday, August 06, 2014 13:13 To: Yuri Tsoglin Cc: Uwe Simm; Silas McDermott; ieee1647@eda.org Subject: Re: pre-defined type names are not keywords Hi Yuri, To your list, "sys" is in a different context vs. "int". So "sys" for sure shouldn't be a keyword. As e Language works with "context keywords", whatever context means - see "var x : var", I think there should be some awareness of name collisions, in order to minimize confusion, especially in a verification context - btw do we know of any dramatic stories or instinctively all programmers respect "keywords"?: - in the standard as a list, not sure if it should be called "reserved keywords", maybe just "keywords", or if we are to be rigorous a "context-keyword map", for example to clarify "var x : var" - in tools some flagging: for example in DVT Eclipse IDE, a macro that uses "keywords" like 'define "my int" as {}' is flagged with a warning because "int" is a reserved keyword. And the same is done for "keyphrases" for example "is also" Thanks, Cristian On Wednesday 06 August 2014 11:28:26 am Yuri Tsoglin wrote: > Also, IMO, there is a certain disadvantage in the concept of "reserved > keywords" as in some other languages. For example, there are two languages > such as C and C++, and the former is "considered" to be a sub-set of the > latter. Any legal C program is also a legal C++ program. But, it's not > really the case, because some names used in C became keywords in C++, > making a C program using such names illegal in C++. In contrast, when we > introduce a new construct in e (and we do it from time to time), it doesn't > make existing e programs illegal. > > > From: owner-ieee1647@eda.org [mailto:owner-ieee1647@eda.org] On Behalf Of > Yuri Tsoglin Sent: Wednesday, August 06, 2014 11:21 > To: Uwe Simm; Silas McDermott; Cristian Amitroaie > Cc: ieee1647@eda.org > Subject: RE: pre-defined type names are not keywords > > That's right - not good and not desired. But - allowed. And even further - > because of the extensible nature of e, with the define-as and > define-as-computed macros that allow to "introduce" any new syntax, there > can appear new (user-defined) keywords which are not part of the original > definition. We certainly wouldn't like such a newly introduced keyword to > become disallowed in other contexts. > > Yuri. > > > From: Uwe Simm > Sent: Wednesday, August 06, 2014 10:26 > To: Yuri Tsoglin; Silas McDermott; Cristian Amitroaie > Cc: ieee1647@eda.org > Subject: RE: pre-defined type names are not keywords > > hi, > > not sure if I would label these code fragments "good" or "desired". context > sensitive parsing isn't making life easier for tool developers and the > value of using something like "struct" as field name or type name is at > best zero. > > /uwe > > From: owner-ieee1647@eda.org [mailto:owner-ieee1647@eda.org] On Behalf Of > Yuri Tsoglin Sent: Wednesday, August 06, 2014 12:27 AM > To: Silas McDermott; Cristian Amitroaie > Cc: ieee1647@eda.org > Subject: RE: pre-defined type names are not keywords > > Or > > unit unit { > unit; > }; > > Or even > > type type: [ type ]; > > > From: Silas McDermott > Sent: Wednesday, August 06, 2014 00:50 > To: Yuri Tsoglin; Cristian Amitroaie > Cc: ieee1647@eda.org<mailto:ieee1647@eda.org> > Subject: Re: pre-defined type names are not keywords > > Which reminds me of my favorite e code example ever: > > struct struct { > struct; > }; > > Try THAT in a different language! > > - Silas. > > > > [cid:image002.png@01CFB169.89C909D0] > > > > Silas McDermott | AE Director | Systems and Advanced Verification > > P: 503.970.2916 www.cadence.com<http://www.cadence.com/> > > > > > > > > > From: Yuri Tsoglin <yurit@cadence.com<mailto:yurit@cadence.com>> > Date: Tuesday, August 5, 2014 at 1:53 PM > To: Cristian Amitroaie <cristian@amiq.com<mailto:cristian@amiq.com>> > Cc: "ieee1647@eda.org<mailto:ieee1647@eda.org>" > <ieee1647@eda.org<mailto:ieee1647@eda.org>> Subject: RE: pre-defined type > names are not keywords > > Apparently yes, e_core is mentioned in Annex D. > Here it is, I am quoting: > > > D.2.5 Reserved type names > One set of types in e is considered essential or core, e.g., int, string, > and sys. No reasonable e program would assign the name of any of those > types to a user-defined type. Core types are declared under a special > package called e_core. Within the name space model, e_core type names are > reserved. Unlike other type names, they cannot be used in another package. > For more information, see D.3.3. > > > D.3.3 e_core types > The set of types declared in the built-in package e_core is privileged. > Unlike all other types, the names of the e_core types remain unique, even > if they have been added by user extension. When a user tries to define a > type using the name of an e_core type, an error is reported. However, these > names are not reserved keywords; they can be used as identifiers in any > other context (variable names, method names, and so on). The e_core types > are: int, uint, byte, bit, bool, string, sys, global, base_struct, > any_struct, any_unit, and event_port. > > > BTW, it seems that the above list of e_core types is incomplete. For > example, "real" is missing. > > Also, there are no "reserved keywords" in e in general. > Even keywords which are not e_core type names, are such only in the sense > that each one of them has a special meaning in a certain context. But no > one of them is reserved, and they may also be used in other contexts. For > example, the word "struct" can be used to define a struct (and in this > sense it is a keyword), but it is also allowed to be a name of a type, > field, variable, method, and anything else. > > Thanks, > Yuri. > > > > > > > > -----Original Message----- > From: Cristian Amitroaie [mailto:cristian@amiq.com] > Sent: Tuesday, August 05, 2014 23:07 > To: Yuri Tsoglin > Cc: ieee1647@eda.org<mailto:ieee1647@eda.org> > Subject: Re: pre-defined type names are not keywords > > > > Hi Yuri, > > > > I think it makes sense. > > > > The question is weather we want users to be able to redefine "int" for > > example... BTW, is "e_core" in the standard? > > > > Thanks, > > Cristian > > On Sunday 03 August 2014 07:29:56 pm Yuri Tsoglin wrote: > > Hi, > > > > > > > > I think we should remove type names such as "int", "string", or "sys", > > from > > > > the keywords table (section 4.1.5.3 in the current LRM). > > > > > > > > These words are just type names, which happen to belong to the "e_core" > > > > package. In this sense, they are not different from any other pre-defined > > > > types, which may belong to other packages (e.g. rf_manager or > > > > any_sequence_driver). > > > > > > > > Does this make sense? > > > > > > > > Thanks, > > > > Yuri. > > > > > > > > > > > > > > > > > > > > [cid:image002.jpg@01CFAF50.EA6C8A20<mailto:image002.jpg@01CFAF50.EA6C8A20 > >>] > > > > > > > > Yuri Tsoglin | e Language team, Specman RnD > > > > > > > > P: 972.3.9004305 M: 972.54.6468177 F: 972.3.9004001 > > > > www.cadence.com<http://www.cadence.com> > > -- > This message has been scanned for viruses and > dangerous content by MailScanner<http://www.mailscanner.info/>, and is > believed to be clean. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner<http://www.mailscanner.info/>, and is > believed to be clean. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner<http://www.mailscanner.info/>, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Aug 6 03:28:16 2014
This archive was generated by hypermail 2.1.8 : Wed Aug 06 2014 - 03:28:25 PDT