Advertisements

"Grigorios Angelis" <> schreef in bericht
news:c1006g$kl0$...
> Does anyone know if it is possible and how to define new operators in
vhdl.
>
> A very usefull one for example would be a "++" operator which would behave
> as its c counterpart.
>
> Possible use:
> signal MySignal : integer := 0;
> .
> .
> .
> process (clock) is
> begin
> if rising_edge(clock) then
> MySignal ++
> end if;
> end process;
>
> The first (of some) error message that I seem to get from the compiler
when
> I try to declare a function "++" is the following:
>
> Not a predefined operator: "++"
>
> Which is kind of a given because the reason I'm trying to make the
operator
> is exactly because it's not predefined.

Advertisements

"Egbert Molenkamp" <> wrote
in message news:c10jam$2p4$...
>
> Only predefined operators can be overloaded.

It's very interesting to ask why this should be so.

Infix operators may have (or lack) many properties that
the compiler needs to know about:
associativity (left, right, none?)
commutativity (needed when optimising a syntax tree)
distributivity (also important for some optimisations)
binding precedence

When you permit unary operators to be either prefix or
postfix, like ++ in C, then things get even more complicated.

Consequently it's very difficult to design a language in which
you can freely define your own operators. When you overload
the VHDL built-in operators, all their other properties, as
mentioned above, remain unchanged - they are built in to the
compiler.

Algol-68 allowed arbitrary operator definition - it was one
of the most complicated features of the language. Does
anyone know of any other languages that offer it?

Be happy with regular procedures. After all, when you want
s++
it's not outrageously hard to write instead
incr(s)
using your own procedure incr().
--
Jonathan Bromley, Consultant

On Thu, 19 Feb 2004 12:20:55 -0000, "Jonathan Bromley"
<> wrote:
>"Egbert Molenkamp" <> wrote
>in message news:c10jam$2p4$...
>>
>> Only predefined operators can be overloaded.
>
>It's very interesting to ask why this should be so.
>
>Infix operators may have (or lack) many properties that
>the compiler needs to know about:
> associativity (left, right, none?)
> commutativity (needed when optimising a syntax tree)
> distributivity (also important for some optimisations)
> binding precedence
>
>When you permit unary operators to be either prefix or
>postfix, like ++ in C, then things get even more complicated.
>
>Consequently it's very difficult to design a language in which
>you can freely define your own operators. When you overload
>the VHDL built-in operators, all their other properties, as
>mentioned above, remain unchanged - they are built in to the
>compiler.
>
>Algol-68 allowed arbitrary operator definition - it was one
>of the most complicated features of the language. Does
>anyone know of any other languages that offer it?

There seem to be two solutions to this problem; increase the language's
complexity, or reduce it. In the first; when you define a new operator,
you need some mechanism to register it's precedence (say, as equal to
'+', or between '+' and '*') - or allow more general manipulation of
precedences. This is presumably the Algol-68 approach.

Or you can simplify the language.

Linn's Lingo was the language of the Rekursiv object-oriented CPU - it
had much of the dynamic nature of Smalltalk, but with a more 'C' like
syntax. One feature was that you could redefine or add operators as you
wished.

All operators had the same precedence, thereby avoiding the problem!
Association was made explicit by the programmer, with parentheses.

If it's not outrageously hard to write "incr(s)" instead of "s++", then
neither is it too hard to write "a + (b*c) + d" to prevent surprises.
Indeed, I tend to follow that style anyway, I feel it adds clarity for
the (human) reader.

NOTE - I am NOT recommending that VHDL adopt this style! just commenting
that it IS a viable alternative to operator precedence, allowing for
arbitrary operator definition in a very simple and clean manner.

"Brian Drummond" <> wrote in
message news:...
> >Algol-68 allowed arbitrary operator definition - it was one
> >of the most complicated features of the language. Does
> >anyone know of any other languages that offer it?
>
> There seem to be two solutions to this problem; increase the language's
> complexity, or reduce it. In the first; when you define a new operator,
> you need some mechanism to register it's precedence (say, as equal to
> '+', or between '+' and '*') - or allow more general manipulation of
> precedences. This is presumably the Algol-68 approach.

Yup. It's not just precedence, of course. VHDL permits
a and b and c
but forbids
a nand b nand c
for perfectly good reasons - but how could you register this
behaviour when creating a new operator?
> [In] Linn's Lingo [...]
> All operators had the same precedence, thereby avoiding the problem!
> Association was made explicit by the programmer, with parentheses.

occam took the same approach. It also made operators non-associative,
so that
a + b + c
was illegal - you had to write
(a + b) + c
instead. C programmers hated it, of course - especially the
kind that take delight in stuff like
for(i=0,j=k;j--*a++=b+=*c++;
> If it's not outrageously hard to write "incr(s)" instead of "s++", then
> neither is it too hard to write "a + (b*c) + d" to prevent surprises.
> Indeed, I tend to follow that style anyway, I feel it adds clarity for
> the (human) reader.

I tend to agree. I've learnt far too many programming languages
in my time, and I nowadays determinedly refuse to remember trivia
like operator precedence

On Thu, 19 Feb 2004 16:54:24 -0000, "Jonathan Bromley"
<> wrote:
>"Brian Drummond" <> wrote in
>message news:...
>
>> >Algol-68 allowed arbitrary operator definition - it was one
>> >of the most complicated features of the language. Does
>> >anyone know of any other languages that offer it?
>>
>> There seem to be two solutions to this problem; increase the language's
>> complexity, or reduce it.
>> [In] Linn's Lingo [...]
>> All operators had the same precedence, thereby avoiding the problem!
>> Association was made explicit by the programmer, with parentheses.
>
>occam took the same approach. It also made operators non-associative,
>so that
> a + b + c
>was illegal - you had to write
> (a + b) + c
>instead.

Lingo didn't go that far; associativity was strictly left to right, so
that (for example) "a nand b nand c" would at least have a defined
result.
>> If it's not outrageously hard to write "incr(s)" instead of "s++", then
>> neither is it too hard to write "a + (b*c) + d" to prevent surprises.
>> Indeed, I tend to follow that style anyway, I feel it adds clarity for
>> the (human) reader.
>
>I tend to agree. I've learnt far too many programming languages
>in my time, and I nowadays determinedly refuse to remember trivia
>like operator precedence

Yes. And it's interesting how much easier languages with well defined
syntax and semantics are to come back to, after spending time on
something else.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!