Re: [sv-bc] part selects on arbitrary expressions

Bresticker, Shalom wrote:
> However, I still think there are problems with parentheses.

One view that Jim Brown (from IBM) espoused in the context of his APL2 language
is that parentheses exist solely to "group and separate tokens" for the purposes
of setting up the parse of an expression.  Any other uses (i.e. grouping a single
token, or separating a token from something it would not otherwise bind to) are
simply redundant and without semantic meaning.  In APL, parentheses had no
other special meanings, e.g., in function application.

By seeing them lexically as punctuation we can eat our cake...
> ... today “(a)” is treated semantically like “a”...

... and have it, too:

 > ... allow (e+x-p*r)[3], where “e+x-p*r” has bounds [N-1:0].

In other words, it isn't the parentheses that force us to regard
something as an expression; that arises from the sequence of tokens
they enclose.  Likewise, parentheses would not convert an lvalue
to an rvalue, so "++(a)" would mean "++a".

Going further, we must place [] into the precedence order.
One goal might be to parse "foo(a)[2]" as a subscript of a
function application, which ranks it below the prefix-function call
that uses parentheses.   Of course "++a[2]" works today, and thus
ranks subscript higher than monadic function call without parentheses.


Greg Jaxon

> 
> For example, if a is of type ‘logic [5:2]”, then $left(a) gives 5 and so 
> does $left((a)).
> 
> Similarly, if a is of type ‘enum logic {ZERO,ONE}’, then “a = (ZERO);” 
> is legal, just as “a = ZERO;” is.
> 
> I’m not sure that it is clear from the LRM that it should work that day, 
> but that is what I have seen in the tools in practice.
> 
>  
> 

> 
> Today, if a is [5:2], then “(a)” is also [5:2], and not [3:0].
> 
> So that is one ambiguity.
> 
> Even if it would be defined in the LRM clearly, it becomes a “gotcha”, 
> as Stu calls it, a pitfall, where people are going to become confused, 
> and we put a stumbling block in their paths. We need to remember that we 
> deal with human beings. Human beings are those who need to read and 
> write this language.
> 
>  
> 
> Similarly, the question of when “(expr)” is context-determined and when 
> it is self-determined. If in “(expr)[3]”, it becomes self-determined, 
> then it is going to confuse people and be a gotcha.
> 
>  
> 
>  From those points of view, using concatenations, i.e., allowing 
> bit-selects and part-selects of concatenations, is much less ambiguous. 
> It is only a partial solution, in that it would only deal with 1-D 
> arrays, but that is in my experience the main case where it is needed, 
> and it would not prevent allowing in the future selects on a different 
> syntax. It would only be an extension of an existing syntax without 
> preventing extending other syntaxes in the future.
> 
>  
> 
> Shalom
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Feldman, Yulik
> *Sent:* Tuesday, March 06, 2007 4:01 PM
> *To:* Bresticker, Shalom; 'sv-bc@server.eda.org'
> *Subject:* RE: [sv-bc] part selects on arbitrary expressions
> 
>  
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Bresticker, Shalom
> *Sent:* Tuesday, March 06, 2007 3:28 PM
> *To:* Feldman, Yulik; 'sv-bc@server.eda.org'
> *Subject:* RE: [sv-bc] part selects on arbitrary expressions
> 
>  
> 
> For example, “$select(a+b,3,3)” makes it clear that a+b is a 
> self-determined expression, and the subscript/index 3 relates to that.
> 
> */[Yulik] You will get into serious problems with this syntax if the 
> type of the selected expression is not going to be a simple one-dim 
> array. In some cases, it will be advantageous to have such types. A 
> trivial example is (a)[3], but you may say it is redundant. A more 
> complex example is a part select over part select: (a[3])[4], which may 
> come in handy in Dmitry’s example and other situations. Another example 
> may be the conditional operator: (c ? a : b)[3]. I would say that if “a” 
> and “b” both have the same type, it may be nice if the type of the 
> conditional operator would be the same, and not converted to the one-dim 
> array. If the type of the selected expression is not a simple one-dim 
> array, then you will need a variable number of arguments for the 
> selections, and you will need a way to distinguish between a bit/part 
> select and the member select (not mentioning that a reference to a 
> member as an expression will be illegal in the $select(<>, member) 
> syntax). In these situations, using the existing syntax of part select 
> will be much more convenient than introducing a new syntax, like the one 
> with the operands of a system function./*
> 
> */ /*
> 
> */Moreover, the existing part select syntax provides you an option to 
> specify a bit select (a[3]), a part select (a[4:3]) or a 
> ascending/descending part select (a[3+:4], a[3-:4]). This is also quite 
> handy, and won’t be directly available with the syntax above 
> ($select(a+b,3,3))./*
> 
> */ /*
> 
> Otherwise, you get into questions such as whether a and b are 
> bit-extended and/or type-converted before the bit/part-select is performed.
> 
> */[Yulik] I don’t think it will be difficult to apprehend that the 
> “(a+b)” operand of “(a+b)[3]” is self-determined, once it is defined 
> clearly in the LRM and people get accustomed to it. I understand that it 
> may be not intuitive from the first glance, but after all we’re talking 
> about a new construct, and its semantics doesn’t have to be 100% clear 
> for the one who never looked on the definition of the construct in the 
> LRM. Compared to the syntactic issues of the system function approach, 
> it seems to me a minor issue./*
> 
>  
> 
> Shalom
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Feldman, Yulik
> *Sent:* Tuesday, March 06, 2007 3:20 PM
> *To:* Bresticker, Shalom; 'sv-bc@server.eda.org'
> *Subject:* RE: [sv-bc] part selects on arbitrary expressions
> 
>  
> 
> Hi Shalom,
> 
>  
> 
> I agree with everything you have said here, but I didn’t understand what 
> led you to conclude that adding a system function is better than not 
> adding it. To me, “(a+b)[3]” is simpler to write and to read than 
> “$select(a+b)[3]” (or whatever the syntax), and I don’t see any 
> substantial problem with allowing the “(a+b)[3]” (as well as “(a)[3]”), 
> as I argued in the previous posts. Since it is a new construct, the 
> semantics of “(a+b)[3]” may be defined in any appropriate way, including 
> the one that would match the supposed semantics of the system function. 
> However, syntactically, “(a+b)[3]” will be simpler to write and read, 
> and this is why I think it is better than the system function.
> 
>  
> 
> --Yulik.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Bresticker, Shalom
> *Sent:* Tuesday, March 06, 2007 2:46 PM
> *To:* Feldman, Yulik; 'sv-bc@server.eda.org'
> *Subject:* RE: [sv-bc] part selects on arbitrary expressions
> 
>  
> 
> Hi, Yulik.
> 
>  
> 
> I don't agree. The parentheses turn the identifier inside into an 
> expression.
> 
> */[Yulik] I’m not sure I follow you. In my eyes, an identifier placed in 
> a syntactical context where an expression is expected is an expression, 
> even if it not surrounded by parenthesis./*
> 
> [SB] “a” is an identifier. As such, it can be a primary or an 
> expression. Today, only an identifier can be followed by a bit-select, 
> not a general primary or expression. When you put parentheses around the 
> identifier, it is now an expression and a primary, but no longer an 
> identifier, and therefore cannot be followed by a bit-select.
> 
> */ /*
> 
>  So a[2] is legal, whereas today a[2] is not.
> 
> */[Yulik] Apparently, you forgot to put the parenthesis in one of these, 
> so I’m not sure what exactly you meant./*
> 
> [SB] Apparently I meant that a[2] is legal, whereas (a)[2] is not legal 
> today.
> 
>  
> 
> (a) is not the same as a, it is an expression whose value and, to a 
> certain degree, type are the same as those of a.
> 
> */[Yulik] What exactly the differences are and where it is defined in 
> the LRM? I understand that sometimes the syntax requires the presence of 
> parenthesis to avoid ambiguities, but I see that as a purely syntactical 
> issue; not semantic. To be more exact, I expect both the value and the 
> type of the “parenthesis expression” to be exactly the same as those of 
> its “operand” (not “to a certain degree”). If you show an example where 
> this is not the case, I would agree that the parenthesis have a special 
> semantic meaning./*
> 
> [SB] Maybe it does have exactly the same type. But that very syntactic 
> difference is today what prevents directly taking bit-selects from it. 
> The difference is again that the case where the parentheses enclose only 
> a simple identifier is a special case. In general, the parentheses can 
> enclose a complex expression.
> 
>  
> 
> Overall, I came to the conclusion that I liked Dmitry’s suggestion best, 
> of adding a system function to do this.
> 
>  
> 
> Shalom
> 
>  
> 
> 
> -- 
> 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.