RE: pre-defined type names are not keywords

From: Yuri Tsoglin <yurit@cadence.com>
Date: Tue Aug 12 2014 - 00:17:03 PDT
Hi,

I was not aware of that.

Then we probably should choose option (2) - keep the existing section (and table) in place, but make sure that it is up to date.
Still, pre-defined e_core type names will be removed from it.
I already opened mantis issue #4992 for that.

In addition, we need to update the list of e_core types mentioned elsewhere, I'll open a mantis issue for that one, too.

Regarding the other issue I mentioned earlier - the missing of pre-defined constants such as TRUE, FALSE and NULL - apparently they are listed separately in section 4.1.4.4 "Predefined constants".

Thanks,
Yuri.




-----Original Message-----
From: Yaron Kashai
Sent: Monday, August 11, 2014 21:08
To: darren.galpin@infineon.com; Yuri Tsoglin
Cc: ieee1647@eda.org
Subject: Re: pre-defined type names are not keywords

Yuri, Darren and all,

The reason for having a keyword table in the standard is  that one is expected in any language definition. There were comments in the initial ballot (in 2006) regarding this where some commenters speculated the omission was intended as an obstacle for would be compliant implementations.

While the Specman implementation uses context sensitive parsing that allows the wizardry mentioned earlier in this thread, that is not allowed by the current standard. Removing keywords actually extends the standard syntax.

I would suggest leaving in the keyword table, because removing it weakens the standard and is going back on decisions made in view of public comments. We could remove certain type names, even though some languages do include built-in type names as reserved keywords.

Cheers,
-- yaron

On Aug 11, 2014, at 2:33 AM, darren.galpin@infineon.com wrote:

> Hi Yuri,
>
> Then you know my next question ;) Please could you raise a mantis issue for changing the title of 4.1.5.5....
>
> I think that we raise the issue of 4.1.5.3 in tonights' call, and have a vote or removing it, and if not removing it, removing the table at least with modified wording.
>
> Cheers,
>
> Darren
>
> -----Original Message-----
> From: Yuri Tsoglin [mailto:yurit@cadence.com]
> Sent: Monday, August 11, 2014 10:06 AM
> To: Galpin Darren (IFGB ATV MCD SIP CV); ieee1647@eda.org
> Subject: RE: pre-defined type names are not keywords
>
> My whole point here is that keywords are NOT one of the basic concepts of this language.
> As far as I know, in the far past (when I wasn't involved yet in this) there were attempts to introduce this concept, and to actually disallow using keywords in other contexts, but those attempts failed and it was given up, mainly due to backward compatibility reasons.
> Maybe this section 4.1.5.3 was introduced because of that?
> I think we can consider removing this section at all.
> Or, instead of removing it, we can just mention that there are keywords (being introduced by each one of the specific constructs), without listing them. Further, we can mention that the actual set of keywords is extensible, because when a user-defined macro is defined, it may introduce another keyword(s).
>
> BTW, while we are at it, the next section 4.1.5.4 uses the term "macros" and it should be changed to "preprocessor names". We should avoid all the confusion between #define (which are preprocessor names) and define-as/define-as-computed (which are macros).
>
> Thanks,
> Yuri.
>
>
>
> -----Original Message-----
> From: darren.galpin@infineon.com [mailto:darren.galpin@infineon.com]
> Sent: Monday, August 11, 2014 11:55
> To: Yuri Tsoglin; ieee1647@eda.org
> Subject: RE: pre-defined type names are not keywords
>
> If we go with (1), what would you do with 4.1.5.3, what would you change it to? Section 4.1 is going through what makes up the language, and keywords obviously do. Obviously (2) is more work......
>
> Cheers,
>
> Darren
>
> -----Original Message-----
> From: owner-ieee1647@eda.org [mailto:owner-ieee1647@eda.org] On Behalf Of Yuri Tsoglin
> Sent: Sunday, August 10, 2014 4:15 PM
> To: ieee1647@eda.org
> Subject: RE: pre-defined type names are not keywords
>
> To summarize, it seems that we have two alternatives, between which we need to decide:
> 1. Remove the keywords table altogether.
> 2. Or, leave the table but make sure that it is up to date (and also remove e_core type names from it).
>
> Personally, I'm in favor of (1).
>
> Yuri.
>
>
>
> -----Original Message-----
> From: Yuri Tsoglin
> Sent: Wednesday, August 06, 2014 14:14
> To: 'Cristian Amitroaie'
> Cc: Uwe Simm; Silas McDermott; ieee1647@eda.org
> Subject: RE: pre-defined type names are not keywords
>
> Well, "sys" has two meanings.
> It is a name of a unit type. And it is also a name of an instance field under global, which happens to be of that same type.
> For the sake of this discussion, we're of course looking at the first one.
>
> Now, you're right that "sys" is not a "base type" in the sense that it is no more than a subclass of "any_unit".
> But on the other hand, just like "any_unit" (which itself is no more than a subclass of "any_struct", which in turn is a subclass of "base_struct") has some special properties, "sys" also has some special properties.
> For example, the instance under global must be the only instance of "sys", and it cannot be instantiated anywhere in user code (BTW, if this is not mentioned in LRM, we should add it, too).
>
> So, in my opinion, being a "base type" (as opposed to being derived from another type), is orthogonal to the question whether its name is a keyword or not.
>
> Assignment rules are also irrelevant here: they equally apply to types (e.g. scalar types) in general, both pre-defined and user-defined ones.
>
> Yuri.
>
>
>
> -----Original Message-----
> From: Cristian Amitroaie [mailto:cristian@amiq.com]
> Sent: Wednesday, August 06, 2014 13:40
> To: Yuri Tsoglin
> Cc: Uwe Simm; Silas McDermott; ieee1647@eda.org
> Subject: Re: pre-defined type names are not keywords
>
> I look at "sys" as a predefined unit, it exists like any other unit, instantiated under the "global" unit. Leaving aside that these two may not be units under the hood... I mean "sys" is the name of a unit type, it is not a "base type". I mean if we look into assignment rules for example, there will be no section for "sys" in particular. All the notes for structs/units are applicable to "sys".
>
> But maybe I'm confused :)
>
> So maybe we should move the keywords to an appendix, annex?
>
> On Wednesday 06 August 2014 01:27:30 pm Yuri Tsoglin wrote:
>> 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.EA
>>>> 6C8A
>>>> 20
>>>>
>>>>> ]
>>>>
>>>> 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.
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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 Tue Aug 12 00:17:54 2014

This archive was generated by hypermail 2.1.8 : Tue Aug 12 2014 - 00:18:02 PDT