Follow-up on text processing functions

OK, I'm stuck; time to expose my ignorance.

I said that you can't have a function parameter of
class VARIABLE, even when it's of mode IN:

function is_empty(variable S: in string) ---illegal
function is_empty(S: in string) --- legal

And two different simulators agree. But then I
remembered that of course you *can* have function
input parameters of class SIGNAL; if this were not
true, then it would be impossible to write function
RISING_EDGE, for example.

The relevant bit of LRM is 1076-2002 clause 2.1.1.
It clearly says that function parameters must be
mode IN and can be CONSTANT or SIGNAL class
(or FILE, which of course is somewhat special).

Does anyone have any idea why VARIABLE is
outlawed here? It's completely mysterious to me.
The IN restriction would make any such variable
parameters read-only, as required by common sense.

Yours confused
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

Jonathan Bromley wrote:

> Does anyone have any idea why VARIABLE is
> outlawed here? It's completely mysterious to me.
> The IN restriction would make any such variable
> parameters read-only, as required by common sense.

Hmmm. What if the variable were an access type?


-- Mike Treseler

Mike Treseler

On Sat, 31 Mar 2007 22:32:45 -0700, Mike Treseler
<> wrote:

>Jonathan Bromley wrote:
>
>> Does anyone have any idea why VARIABLE is
>> outlawed here? It's completely mysterious to me.
>> The IN restriction would make any such variable
>> parameters read-only, as required by common sense.
>
>Hmmm. What if the variable were an access type?

"const ref" vs. "ref const"....

I suppose there would then be no way to stop me taking a
copy of the access variable and using the copy to
mess with the object, thus giving the function side effects.
But it surely should be permissible for an impure function?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

Jonathan Bromley wrote:

> "const ref" vs. "ref const"....
>
> I suppose there would then be no way to stop me taking a
> copy of the access variable and using the copy to
> mess with the object, thus giving the function side effects.
> But it surely should be permissible for an impure function?

It should be.
I use local impure functions
for synthesis and simulation because
I like the clarity of a return value
lacking in a procedure call.

-- Mike Treseler

Mike Treseler

> Jonathan Bromley wrote:
>
>> "const ref" vs. "ref const"....
>>
>> I suppose there would then be no way to stop me taking a
>> copy of the access variable and using the copy to
>> mess with the object, thus giving the function side effects.
>> But it surely should be permissible for an impure function?

Mike Treseler wrote:

> It should be.
> I use local impure functions
> for synthesis and simulation because
> I like the clarity of a return value
> lacking in a procedure call.

.... or maybe SIGNAL class is provided to functions
just to scope in the signal attributes.

The default CONSTANT class works fine to
pass the *value* of a signal or variable
to a function.

What is lost by disallowing a VARIABLE class
for function formals is the possibility
to specify that the actual
*must* be a variable.

-- Mike Treseler

Mike Treseler