default value for subprogram parameter

[John Smith]

Hi,

The specification for default values in subprogram declaration is allowed only
at the end of subprogram declaration? Because anyway may the calling ambigious.

FUNCTION To_bit( s : std_ulogic; xmap : BIT := '0') RETURN BIT;


Thanks

 

[Jonathan Bromley]

On Sat, 30 Jun 2007 22:53:07 +0200,
John Smith <john.smith@hotmail.com> wrote:

The specification for default values in subprogram declaration
is allowed only at the end of subprogram declaration?

No; you must be thinking of C++ or other languages with
impoverished syntax

Because anyway may the calling ambigious.

Find out about named association:

function mangle(a: std_ulogic := '1'; b: integer)
return string is.....
....
str := mangle('X', 7); -- default is not used
str := mangle(b=>3); -- a => default
str := mangle(3); -- no matching function definition

--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[John Smith]

Jonathan Bromley wrote:

On Sat, 30 Jun 2007 22:53:07 +0200,
John Smith <john.smith@hotmail.com> wrote:


The specification for default values in subprogram declaration
is allowed only at the end of subprogram declaration?

No; you must be thinking of C++ or other languages with
impoverished syntax

Because anyway may the calling ambigious.

Find out about named association:

function mangle(a: std_ulogic := '1'; b: integer)
return string is.....
...
str := mangle('X', 7); -- default is not used
str := mangle(b=>3); -- a => default
str := mangle(3); -- no matching function definition

How work then To_bit in std_logic_1164? Calling To_bit( 'Z' ) is valid.

FUNCTION To_bit( s : std_ulogic; xmap : BIT := '0') RETURN BIT IS



Thanks

 

[Paul Floyd]

On Sun, 01 Jul 2007 09:30:44 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Sat, 30 Jun 2007 22:53:07 +0200,
John Smith <john.smith@hotmail.com> wrote:


The specification for default values in subprogram declaration
is allowed only at the end of subprogram declaration?

No; you must be thinking of C++ or other languages with
impoverished syntax

Because anyway may the calling ambigious.

Find out about named association:

function mangle(a: std_ulogic := '1'; b: integer)
return string is.....
...
str := mangle('X', 7); -- default is not used
str := mangle(b=>3); -- a => default
str := mangle(3); -- no matching function definition

It's not supported by the language, but there are C++ libraries that do
this, e.g., the Boost Parameter Library (see
http://www.boost.org/libs/parameter/doc/html/index.html).

A bientot
Paul
(Not speaking for Mentor Graphics)


--
Q1. How long does it take HP to deliver a workstation?
A1. 28 days for the wrong configuration.
Q2. How long does it take HP to deliver a workstation with the right config?
A2. I don't know, but it's 67 days and counting (2007-07-01).

 

[Jonathan Bromley]

On Sun, 01 Jul 2007 11:53:55 +0000,
Paul Floyd <root@127.0.0.1> wrote:

It's not supported by the language, but there are C++ libraries that do
this, e.g., the Boost Parameter Library (see
http://www.boost.org/libs/parameter/doc/html/index.html).

Oh dear... it's all terribly clever, but does little to
dispel my private conviction that the OO priesthood, and
the C++ OO priesthood in particular, grows fat by making
an ego-trip out of a workaround.

It took me about ten minutes to learn how to use named
parameter association, and defaults, in VHDL. Despite
spending considerable periods since without doing any
VHDL at all, I've remembered it. I wonder how long it
would take for me to get familiar with the Boost
feature you referenced? And I wonder how well that
mass of detailed information would stick, if not
used daily?

Feature-rich libraries are a huge turn-off for people
(like me) who lack an encyclopaedic memory. I want
my core, lightweight, memorable language to meet my
halfway on my journey to an application, providing
me with the malleable tools I need to create the
stuff I want. Over-simplicity in the language
means re-inventing the wheel every time you want
to do something; excessive complexity in a set of
libraries has exactly the same effect, by making it
impossible to remember everything that's out there.

Of course there are obvious exceptions: for example,
if I want to write an application that grabs an HTTP
page from a website, I expect to be able to find a
library function somewhere that does the whole of
that rather complicated activity. I think my point
here is that libraries for well-defined application
requirements are fine, but libraries that attempt to
cover up for alanguage's deficiencies by providing
a meta-toolkit are likely to be either very inflexible,
or absurdly complicated to learn and deploy.

Just my ignorant $0.02-worth; I'm not a "real" C++
programmer at all (thank heavens).
--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[Paul Floyd]

On Sun, 01 Jul 2007 14:36:49 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Sun, 01 Jul 2007 11:53:55 +0000,
Paul Floyd <root@127.0.0.1> wrote:

Jonathan,

It's not supported by the language, but there are C++ libraries that do
this, e.g., the Boost Parameter Library (see
http://www.boost.org/libs/parameter/doc/html/index.html).

Oh dear... it's all terribly clever, but does little to
dispel my private conviction that the OO priesthood, and
the C++ OO priesthood in particular, grows fat by making
an ego-trip out of a workaround.

Not wanting to sound too picky, but in general, Boost is more about
templates (thus generics) than OO.

It took me about ten minutes to learn how to use named
parameter association, and defaults, in VHDL. Despite
spending considerable periods since without doing any
VHDL at all, I've remembered it. I wonder how long it
would take for me to get familiar with the Boost
feature you referenced? And I wonder how well that
mass of detailed information would stick, if not
used daily?

For the case of the Parameter Library, then I'd say another 10 inutes
should be enough.

Feature-rich libraries are a huge turn-off for people
(like me) who lack an encyclopaedic memory. I want
my core, lightweight, memorable language to meet my
halfway on my journey to an application, providing
me with the malleable tools I need to create the
stuff I want. Over-simplicity in the language
means re-inventing the wheel every time you want
to do something; excessive complexity in a set of
libraries has exactly the same effect, by making it
impossible to remember everything that's out there.

IMO Boost does not conflict with your wishes here. It _is_ a dauntingly
large project as a whole, but you don't at all have to use it in an "all
or nothing" manner. Boost is more of a federation of small libraries
than a single monolithic library. Part of the package is a little tool
to copy all of the bits that are needed for one of the constituent
libraries to your project. So if you want to just use smart pointers and
named parameters, then there's no need to be bothered by the rest of it.

Of course there are obvious exceptions: for example,
if I want to write an application that grabs an HTTP
page from a website, I expect to be able to find a
library function somewhere that does the whole of
that rather complicated activity. I think my point
here is that libraries for well-defined application
requirements are fine, but libraries that attempt to
cover up for alanguage's deficiencies by providing
a meta-toolkit are likely to be either very inflexible,
or absurdly complicated to learn and deploy.

The ISO/ANSI standards committee for C++ decided (and I tend to think
that they were right) that as little as possible should be added to the
language. C++ is already large and complicated, adding tens or hundreds
more keywords would turn it into an unuasable monster.

C++ does have plenty of shortcomings (imperfect parts of its standard
library, sometimes incomprehensible rules for name lookup, bizarre
possibilities for combining templates and inheritance, almost anything
that involves multiple inheritance and the preprocessor). In my view,
the wealth of libraries that are available for C++ are one of its
strengths, not a weakness.

A bientot
Paul
(Not speaking for Mentor Graphics)

 

[John Smith]

The specification for default values in subprogram declaration
is allowed only at the end of subprogram declaration?

No; you must be thinking of C++ or other languages with impoverished syntax

Because anyway may the calling ambigious.

Find out about named association:

function mangle(a: std_ulogic := '1'; b: integer)
return string is.....
...
str := mangle('X', 7); -- default is not used
str := mangle(b=>3); -- a => default
str := mangle(3); -- no matching function definition

Could you answer my original question? Before we go in C++ depth.


How work then To_bit in std_logic_1164? Calling To_bit( 'Z' ) is valid.

FUNCTION To_bit( s : std_ulogic; xmap : BIT := '0') RETURN BIT IS

Is this correct?

str := mangle(3); -- no matching function definition

Thanks

 

[Jonathan Bromley]

On Sun, 01 Jul 2007 20:57:33 +0200, John Smith
<john.smith@hotmail.com> wrote:

How work then To_bit in std_logic_1164? Calling To_bit( 'Z' ) is valid.

FUNCTION To_bit( s : std_ulogic; xmap : BIT := '0') RETURN BIT IS

Is this correct?

Of course it is. If you associate the parameters by position, then
your one-and-only actual parameter 'Z' obviously associates with
the first formal parameter s, just as if you had written
To_bit(s => 'Z');

str := mangle(3); -- no matching function definition

Indeed. 3 is type-compatible with the SECOND formal of "mangle",
not the first.
--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[Evan Lavelle]

On Sun, 01 Jul 2007 09:30:44 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Sat, 30 Jun 2007 22:53:07 +0200,
John Smith <john.smith@hotmail.com> wrote:


The specification for default values in subprogram declaration
is allowed only at the end of subprogram declaration?

No; you must be thinking of C++ or other languages with
impoverished syntax

C99 got some of the way there, with designated initializers (named
association for structure initialisers), but it didn't get into C++.
The usual arguments against named association and defaults are that
defaults can make a program hard to read, and named associations bind
the subprogram declaration and the call more tightly than you may like
(since you can't just swap out one library for another; the parameter
names may have changed). Neither of these seem to me to be significant
problems, though.

Evan

 

[John Smith]

Jonathan Bromley wrote:

On Sun, 01 Jul 2007 20:57:33 +0200, John Smith
john.smith@hotmail.com> wrote:

How work then To_bit in std_logic_1164? Calling To_bit( 'Z' ) is valid.

FUNCTION To_bit( s : std_ulogic; xmap : BIT := '0') RETURN BIT IS

Is this correct?

Of course it is. If you associate the parameters by position, then
your one-and-only actual parameter 'Z' obviously associates with
the first formal parameter s, just as if you had written
To_bit(s => 'Z');

str := mangle(3); -- no matching function definition

Indeed. 3 is type-compatible with the SECOND formal of "mangle",
not the first.
(1)

There is a simple case. When only this available
FUNCTION To_bit( s : std_ulogic; xmap : BIT := '0') RETURN BIT IS

To_bit( 'Z' ) call this function.


(2)
FUNCTION To_bit( s : std_ulogic; xmap : BIT := '0') RETURN BIT IS
FUNCTION To_bit( xmap2 : BIT := '1'; s : std_ulogic; xmap : BIT := '0') RETURN
BIT IS

Which function will be called by To_bit('Z')?


Thanks

 

[Jonathan Bromley]

On Tue, 03 Jul 2007 14:47:50 +0200, John Smith
<john.smith@hotmail.com> wrote:

FUNCTION To_bit( s : std_ulogic; xmap : BIT := '0') RETURN BIT IS
FUNCTION To_bit( xmap2 : BIT := '1'; s : std_ulogic; xmap : BIT := '0') RETURN
BIT IS

Which function will be called by To_bit('Z')?

The first one. What makes you think it might be otherwise?
Your actual parameter 'Z' is the first in a positional
association, and so it can associate only with the first
formal parameter of any subprogram.

You seem to be trying to turn something rather simple
and elegant into something rather messy and complicated.
Luckily, VHDL won't let you do that.
--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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