What evil would happen?

What evil would happen?

[Wojtek Narczynski]

Hello,

What would happen if a procedure could return a value like a function,
or a function could accept an out parameter? Would it make procedures
less procedural? Or impure functions even less impure? Or is there a
reason for this in compiler implementation details?

I feel like with SML like tagged union datatypes I'd be done long
ago... Is there an AI for this maybe?

I am trying to create a parser for CLFF files.

Regards,
Wojtek

Re: What evil would happen?

[Hyman Rosen]

Wojtek Narczynski wrote:
> What would happen if a procedure could return a value like a function,
> or a function could accept an out parameter?

I don't know Ada well enough to answer this myself,
so I'll ask here - can you make a generic function
with generic parameters which correspond to the out
parameters that you would like to pass into the
function, and have the function write to those? If
so, is that an acceptable workaround?

Re: What evil would happen?

[Wojtek Narczynski]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1057954025.510093@master.nyc.kbcfp.com>...
����
>(...) - can you make a generic function
> with generic parameters which correspond to the out
> parameters that you would like to pass into the
> function, and have the function write to those? If
> so, is that an acceptable workaround?

I have tried it and the compiler told me "left hand side of assignment
must be a variable".

Regards,
Wojtek

Re: What evil would happen?

[Martin Dowie]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0307120430.56d11616@posting.google.com...
> Hyman Rosen <hyrosen@mail.com> wrote in message
news:<1057954025.510093@master.nyc.kbcfp.com>...
>
> >(...) - can you make a generic function
> > with generic parameters which correspond to the out
> > parameters that you would like to pass into the
> > function, and have the function write to those? If
> > so, is that an acceptable workaround?
>
> I have tried it and the compiler told me "left hand side of assignment
> must be a variable".

Have you looked at the 'Rosen Trick' for converting a constant view into
a variable one? See
http://home.earthlink.net/~matthewjheaney/charles/charles-vectors-limited_bounded.html
and search for 'rosen'.

Re: What evil would happen?

[Hyman Rosen]

Wojtek Narczynski wrote:
> I have tried it and the compiler told me "left hand side of assignment
> must be a variable".

Hmm... The Ada Reference manual says that "formal objects" can have mode
"in" or "in out". Did you use the latter?

Re: What evil would happen?

[Wojtek Narczynski]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<8S2Qa.2572$3G5.1937@nwrdny03.gnilink.net>...
> Wojtek Narczynski wrote:
> > I have tried it and the compiler told me "left hand side of assignment
> > must be a variable".
> 
> Hmm... The Ada Reference manual says that "formal objects" can have mode
> "in" or "in out". Did you use the latter?

No. Thanks!

Regards,
Wojtek

Re: What evil would happen?

[chris.danx]

Wojtek Narczynski wrote:
> Hello,
> 
> What would happen if a procedure could return a value like a function,

Surely, it would be a function?

Re: What evil would happen?

[Nick Roberts]

"chris.danx" <spamoff.danx@ntlworld.com> wrote in message
news:1LEPa.9034$nP.7178@newsfep4-winn.server.ntli.net...
> Wojtek Narczynski wrote:
> > Hello,
> >
> > What would happen if a procedure could return a value
> > like a function,
>
> Surely, it would be a function?

I think the idea is that the result returned by the procedure is written
into an implicit variable with a conventional name. Suppose the name is
'Result', then you might have something such as:

   procedure P(...) is
   begin
      ...
      return X*25.4;
   end;

and then:

   P(...);
   if Result > 200.0 then
      ...

Some languages which are typeless (and/or fully polymorphic) have this kind
of facility. Nearly all assembly languages essentially work this way (think
of registers). I think it is clear how badly suited it is to a strongly
typed language such as Ada.

Obviously you could simulate the effect by simply writing into a global
variable, e.g.:

   Result: Float;

   procedure P(...) is
   begin
      ...
      Result := X*25.4;
   end;

but this is not considered good programming style.

A situation in which it might make sense for Ada to permit a return
statement with an expression in a procedure body is for a procedure which
will be called from a foreign language (and so to which pragma Export
applies). The call in the foreign language may look like a procedure call,
but the language may require a value to be invisibly returned by the
procedure (e.g. indicating success or some kind of failure).

Regarding the parameter modes of functions, I think the main Ada Issue to
refer to is AI-323.

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: What evil would happen?

[Wojtek Narczynski]

I don't follow. 

What would be unsafe about:

procedure Parse_Username( S: in String; Result: out Boolean) return String;

?

> Regarding the parameter modes of functions, I think the main Ada Issue to
> refer to is AI-323.

I have read, well - at lest some of it :-)

Regards,
Wojtek

Re: What evil would happen?

[Preben Randhol]

Wojtek Narczynski wrote:
> I don't follow. 
> 
> What would be unsafe about:
> 
> procedure Parse_Username( S: in String; Result: out Boolean) return String;

What would be the point of it?

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: What evil would happen?

[Larry Kilgallen]

In article <slrnbh00ch.3fv.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> Wojtek Narczynski wrote:
>> I don't follow. 
>> 
>> What would be unsafe about:
>> 
>> procedure Parse_Username( S: in String; Result: out Boolean) return String;
> 
> What would be the point of it?

Being able to return an unconstrained value along with one or more
constrained values from the same subprogram:

	declare
	    my_result : Boolean;
	    my_username : constant := Parse_Username (
		s => "SYSTEM",
		result => my_result );
	begin
	    -- make use of that
	end;

Re: What evil would happen?

[Preben Randhol]

Larry Kilgallen wrote:
> Being able to return an unconstrained value along with one or more
> constrained values from the same subprogram:
> 
> 	declare
> 	    my_result : Boolean;
> 	    my_username : constant := Parse_Username (

       my_username : constant String := ...


> 		s => "SYSTEM",
> 		result => my_result );
> 	begin
> 	    -- make use of that
> 	end;

Well then functions with side effects should be more resonable than to
make procedures into functions.

But one could also simply use a function here and return "" if the
parsing failed and then simply check if my_username /= "". You have to
do if my_result then anyway so there is really not much difference to
the code. However I would have concidered throwing an exception in the
case the parsing failed.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: What evil would happen?

[Larry Kilgallen]

In article <slrnbh02sj.4kj.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> Larry Kilgallen wrote:
>> Being able to return an unconstrained value along with one or more
>> constrained values from the same subprogram:
>> 
>> 	declare
>> 	    my_result : Boolean;
>> 	    my_username : constant := Parse_Username (
> 
>        my_username : constant String := ...
> 
> 
>> 		s => "SYSTEM",
>> 		result => my_result );
>> 	begin
>> 	    -- make use of that
>> 	end;
> 
> Well then functions with side effects should be more resonable than to
> make procedures into functions.
> 
> But one could also simply use a function here and return "" if the
> parsing failed and then simply check if my_username /= "".

That presumes:

	1. There is no valid meaning for returning a null username.
	2. There is no desire to return _two_ constrained values.
	3. There is no desire to return a non-Boolean constrained value.

> You have to
> do if my_result then anyway so there is really not much difference to
> the code. However I would have concidered throwing an exception in the
> case the parsing failed.

That presumes:

	4. The only use for a constrained value return is to indicate
	   failure.

Re: What evil would happen?

[Preben Randhol]

Larry Kilgallen wrote:
> 
> That presumes:
> 
> 	1. There is no valid meaning for returning a null username.
> 	2. There is no desire to return _two_ constrained values.
> 	3. There is no desire to return a non-Boolean constrained value.
> 
>> You have to
>> do if my_result then anyway so there is really not much difference to
>> the code. However I would have concidered throwing an exception in the
>> case the parsing failed.
> 
> That presumes:
> 
> 	4. The only use for a constrained value return is to indicate
> 	   failure.

Well if not then use a record with username and the boolean variable and
return that

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: What evil would happen?

[Larry Kilgallen]

In article <slrnbh4r8u.hn.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> Larry Kilgallen wrote:
>> 
>> That presumes:
>> 
>> 	1. There is no valid meaning for returning a null username.
>> 	2. There is no desire to return _two_ constrained values.
>> 	3. There is no desire to return a non-Boolean constrained value.
>> 
>>> You have to
>>> do if my_result then anyway so there is really not much difference to
>>> the code. However I would have concidered throwing an exception in the
>>> case the parsing failed.
>> 
>> That presumes:
>> 
>> 	4. The only use for a constrained value return is to indicate
>> 	   failure.
> 
> Well if not then use a record with username and the boolean variable and
> return that

Nobody has claimed there was no way to program around this obstacle.
The claim under discussion was that there is "no use" for the capability.

Re: What evil would happen?

[Preben Randhol]

Larry Kilgallen wrote:
> Nobody has claimed there was no way to program around this obstacle.
> The claim under discussion was that there is "no use" for the capability.

Well a great many things can have some usage, but it doesn't mean it has
to be implemented.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: What evil would happen?

[Larry Kilgallen]

In article <slrnbh53ir.48d.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> Larry Kilgallen wrote:
>> Nobody has claimed there was no way to program around this obstacle.
>> The claim under discussion was that there is "no use" for the capability.
> 
> Well a great many things can have some usage, but it doesn't mean it has
> to be implemented.

Certainly if everything suggested were implemented Ada _would_ be as
overly large as claimed by detractors.

Re: What evil would happen?

[Wojtek Narczynski]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<zSeTW0M3CTPU@eisner.encompasserve.org>...
> In article <slrnbh53ir.48d.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> > Larry Kilgallen wrote:
> >> Nobody has claimed there was no way to program around this obstacle.
> >> The claim under discussion was that there is "no use" for the capability.
> > 
> > Well a great many things can have some usage, but it doesn't mean it has
> > to be implemented.
> 
> Certainly if everything suggested were implemented Ada _would_ be as
> overly large as claimed by detractors.

Oh, then I know one thing that could go away:

type X is (One, Two, Three);

type Y is new Integer;

[new] can go away.

Regards,
Wojtek

Re: What evil would happen?

[Wojtek Narczynski]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbh02sj.4kj.randhol+abuse@kiuk0152.chembio.ntnu.no>...

> Well then functions with side effects should be more resonable

"Functions" with side effects can only inject their side effect into
where they have been hardcoded to. �This is a serious limitation.
Generics won't help here either as stated in a sibling of this thread.

> than to  make procedures into functions.

Sorry, the reasoning that everything that has return <x> statement is
a function is not very viable.

Regards,
Wojtek

Re: What evil would happen?

[Chad R. Meiners]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0307130417.41548778@posting.google.com...
> Preben Randhol <randhol+abuse@pvv.org> wrote in message
news:<slrnbh02sj.4kj.randhol+abuse@kiuk0152.chembio.ntnu.no>...
>
> > Well then functions with side effects should be more resonable
>
> "Functions" with side effects can only inject their side effect into
> where they have been hardcoded to.
This is wrong.  Function have the capability to randomly introduce side
effects just like any other section of code.

>This is a serious limitation.
If it were true, I doubt it.  In my experience, functions are more useful
when they are pure.  Sure there are times when a function cannot be pure,
but sub-routine with a side-effect should be made a procedure in most cases.

> Sorry, the reasoning that everything that has return <x> statement is
> a function is not very viable.

In mathematics, functions only return single elements, which may be a
composite of some sort.  I suggest that if you want return composites from
functions you should return a record type.

type Composite(StringSize : Natural) is record
     User_Name : String(1..StringSize);
     Result    : Boolean;
end record;

function Parse_User_Name(Item : String) return Composite;

However, the following might also be a suitable procedure for the task

procedure Parse_UserName (Item : String;
                                              UserName : out String;
                                              NameSize : out Natural) ;

> Regards,
> Wojtek
-CRM

Re: What evil would happen?

[Wojtek Narczynski]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<bes4uv$1o29$1@msunews.cl.msu.edu>...

> > "Functions" with side effects can only inject their side effect into
> > where they have been hardcoded to.
> This is wrong.  Function have the capability to randomly introduce side
> effects just like any other section of code.

Have you read the whole thread?

> In my experience, functions are more useful
> when they are pure.  Sure there are times when a function cannot be pure,
> but sub-routine with a side-effect should be made a procedure in most cases.

I agree that functions should be pure. But procedures cannot return an
unconstrained value. Again, this is what this thread is about.

> In mathematics, functions only return single elements, which may be a
> composite of some sort.

Well, in the mathematical definition there is no "call" so there may
not be a "return". Instead there are two sets...

> I suggest that if you want return composites from
> functions you should return a record type.
> 
> type Composite(StringSize : Natural) is record
>      User_Name : String(1..StringSize);
>      Result    : Boolean;
> end record;
> 
> function Parse_User_Name(Item : String) return Composite;
> 
> However, the following might also be a suitable procedure for the task

Yes, this works, but causes code explosion, and memory copying (when
gathering all the parsed pieces together). This is what you can neatly
do in SML with tagged union types, by the way :-)
 
> procedure Parse_UserName (Item : String;
>                                               UserName : out String;
>                                               NameSize : out Natural) ;

This works fine for shor strings, but for longer there will be
unnecessary storage allocation.

Regards,
Wojtek

Re: What evil would happen?

[Chad R. Meiners]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0307131407.4955979e@posting.google.com...
> "Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:<bes4uv$1o29$1@msunews.cl.msu.edu>...
>
> > > "Functions" with side effects can only inject their side effect into
> > > where they have been hardcoded to.
> > This is wrong.  Function have the capability to randomly introduce side
> > effects just like any other section of code.
>
> Have you read the whole thread?
I read all the root nodes, but I was responding to the single sentence which
is incorrect.
>
> > In my experience, functions are more useful
> > when they are pure.  Sure there are times when a function cannot be
pure,
> > but sub-routine with a side-effect should be made a procedure in most
cases.
>
> I agree that functions should be pure. But procedures cannot return an
> unconstrained value. Again, this is what this thread is about.

However, procedure's can return parse trees.

> > I suggest that if you want to return composites from
> > functions you should return a record type.
> >
> > type Composite(StringSize : Natural) is record
> >      User_Name : String(1..StringSize);
> >      Result    : Boolean;
> > end record;
> >
> > function Parse_User_Name(Item : String) return Composite;
> >
> > However, the following might also be a suitable procedure for the task
>
> Yes, this works, but causes code explosion, and memory copying (when
> gathering all the parsed pieces together). This is what you can neatly
> do in SML with tagged union types, by the way :-)

You are prematurely trying to optimize.  Furthermore,  returning records
does not automatically cause code explosion or extra memory copying.  I have
used similar techniques when writing recursive decent parsers.  The code is
both readable and concise (it is also fast enough for any test I cared to
give it).  If you are going to write any sort of language parser, I
recommended browsing the source for GNAT's parser.  It is probably overkill
for what you want but you can get a lot of good ideas from it.  The way it
represents tokens is inspired. ;-)

-CRM

Re: What evil would happen?

[Wojtek Narczynski]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<bes4uv$1o29$1@msunews.cl.msu.edu>...

> > "Functions" with side effects can only inject their side effect into
> > where they have been hardcoded to.
> This is wrong.  Function have the capability to randomly introduce side
> effects just like any other section of code.

Have you read the whole thread?

> In my experience, functions are more useful
> when they are pure.  Sure there are times when a function cannot be pure,
> but sub-routine with a side-effect should be made a procedure in most cases.

I agree that functions should be pure. But procedures cannot return an
unconstrained value. Again, this is what this thread is about.

> In mathematics, functions only return single elements, which may be a
> composite of some sort.

Well, in the mathematical definition there is no "call" so there may
not be a "return". Instead there are two sets...

> I suggest that if you want return composites from
> functions you should return a record type.
> 
> type Composite(StringSize : Natural) is record
>      User_Name : String(1..StringSize);
>      Result    : Boolean;
> end record;
> 
> function Parse_User_Name(Item : String) return Composite;
> 
> However, the following might also be a suitable procedure for the task

Yes, this works, but causes code explosion, and memory copying (when
gathering all the parsed pieces together). This is what you can neatly
do in SML with tagged union types, by the way :-)
 
> procedure Parse_UserName (Item : String;
>                                               UserName : out String;
>                                               NameSize : out Natural) ;

This works fine for shor strings, but for longer there will be
unnecessary storage allocation.

Regards,
Wojtek

Re: What evil would happen?

[Hyman Rosen]

Chad R. Meiners wrote:
> In mathematics, functions only return single elements, which may be a
> composite of some sort.

As I have said before, one of the most fundamental mistakes made by
academics who get involved in computing is to forget that programming
languages are a means of instructing a computer to accomplish a task,
not a reification of some abstract concept whose beauty and purity
must be preserved at all costs.

Re: What evil would happen?

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:r2pQa.8422$Y92.1451@nwrdny01.gnilink.net...
> Chad R. Meiners wrote:
> > In mathematics, functions only return single elements, which may be a
> > composite of some sort.
>
> As I have said before, one of the most fundamental mistakes made by
> academics who get involved in computing is to forget that programming
> languages are a means of instructing a computer to accomplish a task,
> not a reification of some abstract concept whose beauty and purity
> must be preserved at all costs.
>

Of course you are reading too much into what I said.  I was stating
inspiration towards a solution.
Therefore, your so called saying does apply here. ;-)

On a more serious note, if you think that academics formalize computer
science for the sake of beauty and purity, you are in a sad state of
ignorance.

[ot] languages & academia was Re: What evil would happen?

[chris.danx]

Hyman Rosen wrote:

> As I have said before, one of the most fundamental mistakes made by
> academics who get involved in computing is to forget that programming
> languages are a means of instructing a computer to accomplish a task,
> not a reification of some abstract concept whose beauty and purity
> must be preserved at all costs.

Absolutely.  I dabble in a fair few languages, and although I really 
like functional languages some of the current languages make some things 
which are largely trivial in imperative languages rather difficult or 
advanced.  IO is a good example.

Functional languages like Erlang, which grow in industry seem to be more 
keen to make a sacrifice in purity if it makes things a bit more 
convienant, in comparison to others with a largely academic development 
like Haskell.


Chris

Re: What evil would happen?

[Dmitry A. Kazakov]

On Sun, 13 Jul 2003 13:28:54 -0400, "Chad R. Meiners"
<crmeiners@hotmail.com> wrote:

>"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
>news:5ad0dd8a.0307130417.41548778@posting.google.com...
>> Preben Randhol <randhol+abuse@pvv.org> wrote in message
>news:<slrnbh02sj.4kj.randhol+abuse@kiuk0152.chembio.ntnu.no>...
>>
>> > Well then functions with side effects should be more resonable
>>
>> "Functions" with side effects can only inject their side effect into
>> where they have been hardcoded to.
>This is wrong.  Function have the capability to randomly introduce side
>effects just like any other section of code.

So what is the point?

>>This is a serious limitation.
>If it were true, I doubt it.  In my experience, functions are more useful
>when they are pure.  Sure there are times when a function cannot be pure,
>but sub-routine with a side-effect should be made a procedure in most cases.

It is also my view. But I see rather other consecuences from this:

1. All functions are pure. So no access parameters allowed, no access
to global data from the body is allowed etc.

2. But procedures are allowed to have a result.

This would be perfectly consistent and as safe as possible.

>> Sorry, the reasoning that everything that has return <x> statement is
>> a function is not very viable.
>
>In mathematics, functions only return single elements, which may be a
>composite of some sort.

In mathematics you can encapsulate all side effects in objects of
unlimited complexity. It is not the case for programming languages.
Especially ones with weak type inference capability.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: What evil would happen?

[Chad R. Meiners]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:o9s4hvofb2mtn8ga9ahf7uu530pfacald8@4ax.com...
> On Sun, 13 Jul 2003 13:28:54 -0400, "Chad R. Meiners"
> <crmeiners@hotmail.com> wrote:
>
> >"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
> >news:5ad0dd8a.0307130417.41548778@posting.google.com...
> >> Preben Randhol <randhol+abuse@pvv.org> wrote in message
> >news:<slrnbh02sj.4kj.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> >>
> >> > Well then functions with side effects should be more resonable
> >>
> >> "Functions" with side effects can only inject their side effect into
> >> where they have been hardcoded to.
> >This is wrong.  Function have the capability to randomly introduce side
> >effects just like any other section of code.
>
> So what is the point?

The point is that the statement was wrong.  It was a statement of fact.

> >>This is a serious limitation.
> >If it were true, I doubt it.  In my experience, functions are more useful
> >when they are pure.  Sure there are times when a function cannot be pure,
> >but sub-routine with a side-effect should be made a procedure in most
cases.
>
> It is also my view. But I see rather other consecuences from this:
>
> 1. All functions are pure. So no access parameters allowed, no access
> to global data from the body is allowed etc.
>
> 2. But procedures are allowed to have a result.
>
> This would be perfectly consistent and as safe as possible.

I prefer SPARK's rules on functions, but I think that we should just allow
in out parameters for our unpure functions since passing access parameters
can be ugly.  I really do not see the harm in allowing unpure functions
because good modularity usually nudges the programmer towards writing pure
functions.  However, when an exception is needed being able to write unpure
function should be straight forward and easy to detect at the specification
level.

> >In mathematics, functions only return single elements, which may be a
> >composite of some sort.
>
> In mathematics you can encapsulate all side effects in objects of
> unlimited complexity. It is not the case for programming languages.
> Especially ones with weak type inference capability.
True, I was only stating inspiration for using records to return multiple
values.

> ---
> Regards,
> Dmitry Kazakov
> www.dmitry-kazakov.de
-CRM

Re: What evil would happen?

[tmoran]

> In mathematics ...
  There's a good essay on the pluses and minuses of metaphor in last
week's Science magazine:
http://www.sciencemag.org/cgi/content/full/301/5629/52

Re: What evil would happen?

[Dmitry A. Kazakov]

On Mon, 14 Jul 2003 13:44:26 -0400, "Chad R. Meiners"
<crmeiners@hotmail.com> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:o9s4hvofb2mtn8ga9ahf7uu530pfacald8@4ax.com...

>> 1. All functions are pure. So no access parameters allowed, no access
>> to global data from the body is allowed etc.
>>
>> 2. But procedures are allowed to have a result.
>>
>> This would be perfectly consistent and as safe as possible.
>
>I prefer SPARK's rules on functions, but I think that we should just allow
>in out parameters for our unpure functions since passing access parameters
>can be ugly.  I really do not see the harm in allowing unpure functions
>because good modularity usually nudges the programmer towards writing pure
>functions.  However, when an exception is needed being able to write unpure
>function should be straight forward and easy to detect at the specification
>level.

Exactly, this is why I'd prefer procedures with a result and functions
enforced (as much as possible) to be pure. Then a code reader could
easily figure out from the declaration what to expect, rather than
searching for some obscure pragmas or inspecting the bodies. I believe
that code purity is important enough to deserve extra syntax sugar.
Then we are already going this way - the functions of a protected
object may not change its state, which influences the implementation.
Similarly, function calls could be implemented differently from calls
to procedures. For example, the language could require the exact call
order for procedures. I mean nasty pitfalls like:

Character'Pos (Read (Socket)) * 256 + Character'Pos (Read (Socket))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: What evil would happen?

[Robert I. Eachus]

Wojtek Narczynski wrote:

> What would happen if a procedure could return a value like a function,
> or a function could accept an out parameter? Would it make procedures
> less procedural? Or impure functions even less impure? Or is there a
> reason for this in compiler implementation details?
> 
> I feel like with SML like tagged union datatypes I'd be done long
> ago... Is there an AI for this maybe?

Yes, several, and some language study notes, and I think some sections 
in the Ada Rationale.

> I am trying to create a parser for CLFF files.

I don't follow from this to what you are asking.  Assuming you want to 
parse common log file format files which have a format of

     remotehost rfc931 authuser [date] "request" status bytes

(per http://www.w3.org/Daemon/User/Config/Logging.html) I can't imagine 
why you would be asking about such a feature.  But if I were you I would 
be looking at Ada.Strings.Unbounded.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: What evil would happen?

[Wojtek Narczynski]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message 

> I don't follow from this to what you are asking.  Assuming you want to 
> parse common log file format files which have a format of
> 
>      remotehost rfc931 authuser [date] "request" status bytes
> 
> (per http://www.w3.org/Daemon/User/Config/Logging.html) I can't imagine 
> why you would be asking about such a feature.  But if I were you I would 
> be looking at Ada.Strings.Unbounded.

I have a lot of those logfiles so I wanted it to be fast => tried to
stick with fixed strings and no exceptions. Indeed I may be trying to
optimize something that is not slow...

Regards,
Wojtek

Re: What evil would happen?

[Robert I. Eachus]

Wojtek Narczynski wrote:

> I have a lot of those logfiles so I wanted it to be fast => tried to
> stick with fixed strings and no exceptions. Indeed I may be trying to
> optimize something that is not slow...

The usual is to start out using Ada.Strings.Unbounded, then IF you run 
into time issues, try instantiating Ada.Strings.Bounded for a reasonable 
size, or sizes.

Of course, the rapid increase in computer speeds means that we could 
probably drop Ada.Strings.Bounded and Ada.Strings.Fixed from Ada0Y. 
(But we won't.)  It seems that today any case where you want to use 
these types involves disk I/O, and with modern processors, it is hard to 
get even 30% processor utilization when processing a disk file.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: What evil would happen?

[Preben Randhol]

Robert I. Eachus wrote:
> Of course, the rapid increase in computer speeds means that we could 
> probably drop Ada.Strings.Bounded and Ada.Strings.Fixed from Ada0Y. 
> (But we won't.) 

Good as I think there will be more gadgets that in the future could run
home made apps on slow CPUs (PDAs and stuff). So eventhough the desktop
may be of high speed it may not be so for other things. I would guess
this is also very true for the embedded market?

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: What evil would happen?

[Randy Brukardt]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0307111151.4a08f95a@posting.google.com...
> Hello,
>
> What would happen if a procedure could return a value like a function,
> or a function could accept an out parameter? Would it make procedures
> less procedural? Or impure functions even less impure? Or is there a
> reason for this in compiler implementation details?
>
> I feel like with SML like tagged union datatypes I'd be done long
> ago... Is there an AI for this maybe?

No evil would happen. The world would continue. :-)

However, its clear that it is never going to happen (see the result of
AI-323). There is enough opposition to the idea that it could never get a
consensus.

So functions in Ada will continue to be able to have side effects, just not
be able to show them in their specification. (A paraphrase of Robert Dewar).

Note that the Object.Operation notation (if approved) will help that for
tagged types, as that notation allows using access parameters without
explicitly saying 'Access. (So, for a function with the first parameter as
an access parameter, the call would look the same as an IN parameter).

                  Randy.

P.S. Do we have to discuss this AGAIN?

Re: What evil would happen?

[Hyman Rosen]

Randy Brukardt wrote:
> P.S. Do we have to discuss this AGAIN?

That's the price to be paid for continuing
to allow the mulish and senseless opposition
to keep its roadblock in place.

Re: What evil would happen?

[Alexander Kopilovitch]

Randy Brukardt wrote:

> > What would happen if a procedure could return a value like a function,
> > or a function could accept an out parameter?
>...
>P.S. Do we have to discuss this AGAIN?

Yes, for sure. Just because "there is enough opposition and no hope of
consensus" is not a technical argument. And it isn't an argument at all
outside of the ARG.

Hyman Rosen wrote:

>That's the price to be paid for continuing
>to allow the mulish and senseless opposition
>to keep its roadblock in place.

I am not sure that this is "mulish and senseless" opposition, but the fact is
that this is the silent opposition. There was outbreak of that discussion in
Ada-Comment (past year, I think), and within that discussion I reviewed all
arguments (against IN OUT parameters in functions), which was stated in 1993-1995,
and which blocked this feature in Ada 95. But no one seemed interested in
technical discussion: all participated ARG members simply stated their position
- pro and contra. (Most interesting was Robert Dewar's position: he firmly
stated that for all technical reasons IN OUT parameters for functions should
be permitted, but nevertheless, he warned that he will vote against this feature,
because this feature certainly will not gain consensus within ARG.)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: What evil would happen?

[Wojtek Narczynski]

Randy,

> P.S. Do we have to discuss this AGAIN?

Sorry, my knowledge of what has been discussed, when, and how many
times, is fairly limited.

But AI-323 only discusses functions. It doesn't discuss return <X>
statement for procedures.

Regards,
Wojtek

Re: What evil would happen?

[Randy Brukardt]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0307150019.5370f3a3@posting.google.com...
> Randy,
>
> > P.S. Do we have to discuss this AGAIN?
>
> Sorry, my knowledge of what has been discussed, when, and how many
> times, is fairly limited.
>
> But AI-323 only discusses functions. It doesn't discuss return <X>
> statement for procedures.

I've never heard of any real support for that. Functions in Ada have
side-effects and that is not going to change (else virtually all existing
Ada code would cease to work). There is no point in having value-returning
procedures which are identical to functions with side-effects -- that's just
an extra complication.

In any case, this is a political issue, not a technical one, and it is very
unlikely that a consensus for any change will ever occur. Of course that's
stupid, but politics is generally stupid (look at the majority of our
elected officials).

I've toyed with adding a mode to Janus/Ada to allow in out parameters on
functions, but I haven't seen a compelling use for it (the most valuable
uses would be in Claw, but that has to work with standard Ada).

                             Randy.

Re: What evil would happen?

[Robert I. Eachus]

Randy Brukardt wrote:

> I've toyed with adding a mode to Janus/Ada to allow in out parameters on
> functions, but I haven't seen a compelling use for it (the most valuable
> uses would be in Claw, but that has to work with standard Ada).

And AFAIK, GNAT still supports the "value returning procedures pragmas 
from DEC Ada.

But the rule still won't change, and the reason is not just "politics." 
  This is just one area of the Ada programming culture that seems to rub 
foreigners (to Ada) the wrong way.  If you are used to Ada, the current 
Ada idioms for the few cases that seem to some people to be problems are 
natural to you.

Since I have done a lot of work on random number generators, the Ada 
idiom now seems natural to me:

function Random(Gen: in Generator) return ...
   Local: Generator;
   for Local'Address use Gen'Address;
begin
   ...
end Random;

Unlike RBKD, I did strongly argue for an in out parameter mode for 
functions in Ada 9X.  But in doing so I knew that it would be misused 
more than it would be correctly used.  By now with good implementations 
of Unbounded_String, most of the real needs for functions with in out 
parameters have gone away.  You can always declare a procedure with an 
out parameter of Unbounded_String.  So if the question is reraised I 
will vote against it.  And I will also vote in favor of a generic that 
provides the equivalent of Unbounded_String for all array types, 
including multidimensional array types.

-- 

                                                 Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: What evil would happen?

[Dmitry A. Kazakov]

On Tue, 15 Jul 2003 12:33:12 -0500, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>I've never heard of any real support for that. Functions in Ada have
>side-effects and that is not going to change (else virtually all existing
>Ada code would cease to work). There is no point in having value-returning
>procedures which are identical to functions with side-effects -- that's just
>an extra complication.

There is one. One could impose additional restrictions on procedures
with results, which do not apply to functions:

1. The call order is as-is
2. No call is allowed to be optimized out

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

What evil would happen?

[Kenneth Almquist]

wojtek@power.com.pl (Wojtek Narczynski) wrote:
> I feel like with SML like tagged union datatypes I'd be done long
> ago... Is there an AI for this maybe?

I'm not sure what the problem is here.  In SML you can write
things such as:

    datatype tree = Leaf of int
                  | Tree of {
                        value : int,
                        left : tree,
                        right : tree
                    }
                  | Empty

In Ada, you achieve the same effect by writing:

    type Tree_Tag is (Leaf, General_Tree, Empty);
    type Tree(Tag : Tree_Tag);
    type Tree_Ptr is access Tree;
    type Tree(Tag : Tree_Tag) is record
        case Tag is
            when Leaf =>
                Leaf : Integer;
            when General_Tree =>
                Value : Integer;
                Left : Tree_Ptr;
                Right : Tree_Ptr;
            when Empty =>
                null;
        end case;
    end record;

The Ada code is slightly more complex than the SML code because in
Ada we have to include a type declaration for the tag, and have to
declare an access type.  (The reason we have to declare an access
type in Ada but not in SML is that in SML the fields of a tree cannot
be modified after a tree is created, so the semantics of SML don't
need to distinguish between a tree and a pointer to a tree.)
				Kenneth Almquist

Re: What evil would happen?

[Wojtek Narczynski]

ka@sorry.no.email (Kenneth Almquist) wrote in message news:<bf02o2$dno$1@shell.monmouth.com>...
> wojtek@power.com.pl (Wojtek Narczynski) wrote:
> > I feel like with SML like tagged union datatypes I'd be done long
> > ago... Is there an AI for this maybe?
> 
> I'm not sure what the problem is here.  In SML you can write
> things such as:
> 
>     datatype tree = Leaf of int
>                   | Tree of {
>                         value : int,
>                         left : tree,
>                         right : tree
>                     }
>                   | Empty
> 
> In Ada, you achieve the same effect by writing:
> 
>     type Tree_Tag is (Leaf, General_Tree, Empty);
>     type Tree(Tag : Tree_Tag);
>     type Tree_Ptr is access Tree;
>     type Tree(Tag : Tree_Tag) is record
>         case Tag is
>             when Leaf =>
>                 Leaf : Integer;
>             when General_Tree =>
>                 Value : Integer;
>                 Left : Tree_Ptr;
>                 Right : Tree_Ptr;
>             when Empty =>
>                 null;
>         end case;
>     end record;
> 

Thanks for the example.

Regards,
Wojtek

Re: What evil would happen?

[Wojtek Narczynski]

Hello,

Now I have a wealth of soluions (no order):

- generic functions with "in out" formal objects(HR),
- Addres clause (RIE),
- passing access types (FR) ,
- SML-like tagged unions (KA),
- ......

Sorry for reviving my old thread, but I wanted to sum up and�to thank everybody.

Regards,
Wojtek

Re: What evil would happen?

[Hyman Rosen]

Wojtek Narczynski wrote:
> - generic functions with "in out" formal objects(HR)

Hey, you mean I was the only one to propose this solution?
I'm going to lose my reputation for not knowing Ada! :-)

Re: What evil would happen?

[Robert I. Eachus]

Wojtek Narczynski wrote:
> Hello,
> 
> Now I have a wealth of soluions (no order):
> 
> - generic functions with "in out" formal objects(HR),
> - Addres clause (RIE),

Incidently this is known as the Rosen trick, for Jean Pierre Rosen.  And 
there is a discussion in the ARG right now on the meaning of RM 
13.3(19).  My "notational" new wording is "the Rosen trick works, plus 
some other things."  (There are other cases being discussed as well.)
The issue is that the RM should say something about the effect on the 
object whose address may have been taken, and whether it is meaningful 
to try to exend that to cases where there is a more complex expression 
for the address.  But:

for A'Address use B'Address; when A and B are the same size, it shoud 
imply the same things about both A and B.

> Sorry for reviving my old thread, but I wanted to sum up and to thank everybody.

Believe me, no matter what is said, thanks are always appreciated.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.