Language Change Specification History for Environment API

Voting Results: Cast your votes here

Yes:

1. Thomas Preusser - 2017-02-09 - ver 5
2. Ryan Hinton - 2017-02-10 - ver 2
3. Martin Thompson - 2017-02-17 - ver 2
4. Jim Lewis - 2017-03-06 - ver 4
5. Patrick Lehmann - 2017-03-14 - ver 5

No:

Abstain:

1. Brent Hayhoe - 2017-02-16 Version 2 - Abstain due to lack of personal time for review.
2. Martin Zabel - 2017-03-07 - ver 5 - I prefer separate functions for environment variables and conditional analysis identifiers.

Comments

I much prefer the LINE return in order to distinguish between the "undefined" and "empty" cases. It's not unusual to define an empty environment variable.

-- Ryan Hinton - 2017-02-11

@Ryan: I will happily switch to returning a line rather than a string. However, the statement I would need from you would be: It is not unusual that you have to distinguish an empty environment variable from an undefined one. I would assume (maybe falsely) that very often both of these options are semantically equivalent. If so, returning a string rather than a line would do no harm but would be more convenient for constructing string expressions.

-- Thomas Preusser - 2017-02-13

string return values are awkward to work with. It would need to be called with a corresponding call to justify to be even usable. Otherwise, the only thing one can do with it is use the return value in an expression.

We need some indication to size the string return value. see SREAD.

-- Jim Lewis - 2017-02-14

Created Version #2 changing the return type of GETENV from STRING to LINE.

-- Thomas Preusser - 2017-02-15

I like GETENV and GETDEF, they're nice and clean and a minimal change to the language. The _NAMES ones, though, don't we have the same problem with a LINE_VECTOR that we do with a STRING? That you can't actually put the return value into a variable because it would require that the variable be unsized?

If I'm right, one solution would be a shared variable of protected type.

type t_envvar is protected
  procedure Initialize;
  impure function Count return NATURAL;
  impure function NextVar return LINE;
end protected type;

Another, possibly lighter solution would be to return them all in a LINE, and let the program parse them back out using READ [LINE, STRING].

impure function GETENV_NAMES(delimiter : string := " ") return LINE;

Meanwhile, with all the new LINEs we're going to be adding to the language, I'm really really glad we're passing Garbage Collection. Relying on all of this getting deallocated correctly would be a nightmare.

-- Rob Gaddi - 2017-02-20

Rather than GetDef, I would like one deferred constant or function per conditional analysis variable/named value.

"Conditional compilation" has been corrected to be "Conditional analysis".

-- Jim Lewis - 2017-02-21

@Jim: I will gladly change conditional compilation to conditional analysis.

I do not think that using a deferred constant or function per conditional analysis identifier is sensible. This either precludes tool- or user-defined identifiers from being accessible or it clobbers the VHDL namespace unpredictably. In the end, the sets of environment variables and of conditional analysis identifiers are very much alike: They both define a standard set of values and allow flexible additions by the tool and the user. So why should we use different styles for accessing them?

-- Thomas Preusser - 2017-02-21

@Rob: Well, you are right that you cannot safely put a LINE_VECTOR result into a variable. The protected type solution is too heavy-weight for my taste. What I would probably do is either use a constant (definitely my preference) or a variable of an access type:

-- with LCS 007(a), this becomes possible and concise even in sequential code
block
  constant env_names : line_vector := GETENV_NAMES;
begin
  ...
end block:

block
  type ENV_TYPE is access LINE_VECTOR;
  variable  env : ENV_TYPE;
begin
  env := new LINE_VECTOR'(GETENV_NAMES);
end block:

-- Thomas Preusser - 2017-02-21

Hi Thomas, WRT your reply on 2017-02-21, on 2017-01-03 on LCS_2016_061, you posted the following comment and are voting no because:

=== Copied from LCS_2016_061

"I am not very fond of creating another namespace for compilation identifiers that is inaccessible for other more flexible statements like conditional <b>generate</b>s. This will provoke libraries with code like:"

'if VHDL_VERSION = "1987"
constant VHDL_VERSION : string := "1987";
'elsif VHDL_VERSION = "1993"
constant VHDL_VERSION : string := "1993";
'elsif
  ...
'end if

The fixed set of compilation identifiers also precludes the most useful specification of user-defined identifiers.

=== End of copied from LCS_2016_061

If you want conditional compilation names visible, make it so here. I checked, the name space of conditional compilation is totally independent from the VHDL name space and the same name can peacefully co-exist in both.

Do you have a technical reason for voting no on LCS_2016_061? If so, please post it there. However, note that the above quoted text is no longer a valid reason as you have the opportunity to address it here - and oddly you have stated it is a bad thing.

-- Jim Lewis - 2017-02-23

This LCS enables both: (a) The conditional analysis identifiers become accessible through a lookup mechanism while (b) also avoiding to clobber the VHDL namespace. Although a well-defined finite set of identifiers can also be directly copied into the VHDL namespace as I have suggested originally, the lookup approach is also simple, more flexible and naturally applicable to tool- and user-defined extensions.

-- Thomas Preusser - 2017-02-24

That is the nice thing about it being in std.env. It is not in the name space unless someone says std.env.all. And if someone only wants part of std.env, they can simply say, std.env.stop or std.env.VHDL_VERSION. It is easy and clear. In fact, since the library std is automatically visible and the package env is new, I always call stop as std.env.stop - as that way it tells people where it is from and I don't have to do the package reference.

-- Jim Lewis - 2017-02-24

@Jim: Your desired extension is addressed by LCS006f.

-- Thomas Preusser - 2017-02-27

Each subprogram in section 16 is described as one paragraph. Please adhere to this pattern.

The LRM uses prefixes to group functions and procedures. This pattern is also used by LCS 006a and 006c. In contrast, the proposed subprograms in this LCS have another naming pattern. Moreover the subprogram name GetDef is an abbreviation of "define" but section 24.2 doesn't define "defines", these are conditional analysis identifiers.

The proposed API returns allocated data structures, but does not provide a functionality to deallocate that memory.

Distinguishing non-existent from empty environment variables is quite difficult with that API.

The GETDEF* interface does not provide access to tool or user defined conditional analysis identifiers.

-- Patrick Lehmann - 2017-03-02

In reply to 21.02.2017

constant env_names : line_vector : GETENV_NAMES;=

Is not valid. You cannot create a constant of an access type or a composite type containing access types.

-- Patrick Lehmann - 2017-03-02

Why is this a two step process? Get a line vector to find my name, then a second function call to return the value. Why not just get a data structure that gives me both?

-- Jim Lewis - 2017-03-05

I am curious about NULL return. Have you written code for this? Would a null string (meaning "") work better than NULL or is NULL better?

Does the LRM use null or NULL?

-- Jim Lewis - 2017-03-06

Why are we putting tool directives and environment in different functions? Why not just 006f and one function? And allow that one function to access either environment or compiler directives with scope precedence to compiler directives

-- Jim Lewis - 2017-03-06

@Jim: The LRM uses null, first introduced as a literal on page 35. It was an explicit request by Ryan to be able to differentiate an empty environment variable defined as "" from an undefined one. null achieves this.

-- Thomas Preusser - 2017-03-06

@Jim: I would be willing to go for GETENV + GETALLENV only - with a precedence of conditional analysis identifiers. At this point of time, this is, however, plain gambling as I might loose other voters with this choice.

-- Thomas Preusser - 2017-03-06

For any LCS 006**: I'm against merging the scopes of environment variables and conditional analysis identifiers. These are disjunctive concepts and shouldn't be mixed in one single scope.

The parameter Name is not described in the function description.

The wording "this environment" should be changed to "host environment".

-- Patrick Lehmann - 2017-03-06

@PL: with one procedure, there is one less thing to remember.

-- Jim Lewis - 2017-03-07

Trade-off between "" (null string) and null pointer value:
"" Pro: can immediately check against expected values.

Con

must deallocate

null Pro: if not exist, nothing to deallocate
Con: must check to see if it is non-null before dereferencing the pointer.

Not sure which I like better, however, we need to make a conscious decision that what is in the LCS is what we want.

-- Jim Lewis - 2017-03-07

@Jim: I think we can resolve the null vs. an empty string by an overload returning string rather than line. You should not be concerned so much about deallocation, however, as we will have GC (LCS 030).

@Jim and @Patrick: It is really hard to please the two of you at the same time. I am rather emotionless about merging the CA identifiers with the environment or not. However, this is a binary decision. If either choice is blocked by one of you, we will not have a solution at all. If you can come up with a decision in a bilateral discussion, I will gladly adopt either choice. Once it is decided, it is just a very quick edit.

-- Thomas Preusser - 2017-03-07