FUNCTION keyword ?

[es_91]

Hi.

A procedure that does give a value back should be called a function. Why not introduce the keyword Function in Addition to Procedure?

[ostapas]

But, as PB name says, it is Basic. Why add additional mess and backwards incompatibility.

[luis]

A procedure that does give a value back should be called a function.

No, not really IMHO. A procedure returning a value it's just a procedure doing some stuff and also returning a value.
In C for example, and in many other languages, the distinction has been dropped.
A "pure" function, worth some kind of differentiation, is usually a different thing. See below.

The distinction through a new keyword would makes sense if the effect, scope, usability inside the language are different.
For example if one can be used inside expressions and the other can't.
If they do the same stuff, logically there is no need to differentiate.
A pure function should operate on its parameters only and return a result.
Also the result should always be the same when invoked with the same params (not a mandatory requirement for a procedure) and not alter the state of the outside system in any way. So it should not contain any code causing side effects.
Causing side effects it's exactly what a procedure do.

If your proposal it's not cosmetic, then you are asking to add restrictions to what a procedure can do (no side effects) and call that a function.
This would require not trivial changes to the language (possibly) and the compiler if it has to certify a function it's really just that and not a procedure with a meaningless keyword stamped on its head. I don't see an advantage so important to justify it, considering I can already write a self-restricted procedure behaving like a pure function today.

If your proposal it's cosmetic, then you would end up adding a new keyword (like PB didn't have enough) for nothing and you would also be forced to use it just because the ex-procedure returns a value. Just annoying I think.

[es_91]

So far, thanks for the replies. I hope i understood everyone of you correctly.

I mostly agree with what luis said, however i would find it, as a newcommer to PureBasic, wonderous why a procedure returns a value when it, by definition, can not.

I would submit to the replacement of the word "procedure" by the word "function" so that everybody knows, aha! this CAN give something back. It should, of course, not be strict, means nobody should be forced to do a Find/Search-Overwork to his or her works just to replace the old Procedure calls with new word Function. But, it could be a possibility. Allow the new "Function" and still support the old "Procedure".

I asked this thread because it looked to me like there was a time, when PureBasic was not so developed as it is now, when a procedure really could not return something. But it seems to me now, Fred planed it in the first way. And, if that is the case, there is no chance asking for this at all.

[Little John]

why a procedure returns a value when it, by definition, can not.

Hu? To what definition are you referring?

I would submit to the replacement of the word "procedure" by the word "function" so that everybody knows, aha! this CAN give something back.

For such a cosmetic purpose, you can just use a macro:

Code: Select all

Macro Function
   Procedure
EndMacro

[es_91]

Hu? To what definition are you referring?

In Basic and Pascal, procedures returning values are usually called "functions", only otherwise they are "procedures".

Thanks for the hint with the macro.

[Little John]

Hu? To what definition are you referring?

In Basic and Pascal, procedures returning values are usually called "functions", only otherwise they are "procedures".

You are talking about conventions in other languages, not about a definition of PureBasic's keyword "Procedure".

And it is not that simple. "BASIC" denotes a rather heterogeneous family of programming languages. There are, for instance, BASIC flavours that do not have a "Procedure" keyword at all, but use "Sub" instead. If I had enough time, I could give much more examples of differences between so called "BASIC" flavours. And neither Pascal nor other BASIC flavours are authoritative for PureBasic. The definition of PureBasic's keyword "Procedure" is given here. According to that definition, a PureBasic procedure can return a value.

[Tenaja]

So far, thanks for the replies. I hope i understood everyone of you correctly.

I mostly agree with what luis said, however i would find it, as a newcommer to PureBasic, wonderous why a procedure returns a value when it, by definition, can not.

I would submit to the replacement of the word "procedure" by the word "function" so that everybody knows, aha! this CAN give something back. It should, of course, not be strict, means nobody should be forced to do a Find/Search-Overwork to his or her works just to replace the old Procedure calls with new word Function. But, it could be a possibility. Allow the new "Function" and still support the old "Procedure".

I asked this thread because it looked to me like there was a time, when PureBasic was not so developed as it is now, when a procedure really could not return something. But it seems to me now, Fred planed it in the first way. And, if that is the case, there is no chance asking for this at all.

PureBasic is a language that stands on its own two feet. Many of us (myself included) get tripped up or challenged by its syntax for the first week or two. (At first, I made my own macros for "Local" instead of using the keyword Protected variables.) However, once you get to know it, the language becomes second nature, just like any other language. Give it some time before posting too many "nitpicky" requests (i.e. keyword "a" should be keyword "b").

BTW, I never liked the way some other languages have different keywords for functions depending on whether a value is returned or not. I much prefer the PureBasic (...and C!) syntax, where one construct covers both requirements. And yes, I call them functions, even in PB, because that is what they are, whether they return a value or not. Because that's what I learned first, they will always be functions.

[es_91]

Fine. Just one thing...

However, once you get to know it, the language becomes second nature, just like any other language. Give it some time before posting too many "nitpicky" requests (i.e. keyword "a" should be keyword "b").

...you are telling that to a person who is been using PureBasic as primary language for 8 years now. And i still got a little pissed by that procedure thing. It just does not look good as the rest of PureBasic does.

[heartbone]

Fine. Just one thing...

However, once you get to know it, the language becomes second nature, just like any other language. Give it some time before posting too many "nitpicky" requests (i.e. keyword "a" should be keyword "b").

...you are telling that to a person who is been using PureBasic as primary language for 8 years now. And i still got a little pissed by that procedure thing. It just does not look good as the rest of PureBasic does.

8 years of love and still pissed over a keyword?
Wow.

Now I'm not pissed about this, but a peeve of mine would be the opposite of yours.
I feel the use of the term FUNCTION where usually applied as a programming language keyword seems too vague and overused.

For example es_91, by your definition the + operator is actually a context mapped function which requires two argument/parameters/inputs, and returns a single value.
The classification of that type of common function is called an operator.
It's spoken keyword is plus, and programmically it has the single plus character as a keyword.
Referring to another computing function as a FUNCTION is somewhat confusing.
Perhaps the keyword for the various Sub/Subroutine/Proc/Procedure/Function type of functionality in a programming language should be named EntryPoint.
Of course one of the biggest concerns if that change were to happen would be what to do about this. Right?

And all the high level programming languages should work towards using that standardized expression EntryPoint for module entry points, just as they have with + for the addition function.
(That line was supposed to be poking fun at your topic here es_91, I'm not serious about wanting keywords to be changed. )

[PB]

> 8 years of love and still pissed over a keyword?

LOL! That's what I was thinking.

PureBasic is NOT "Basic". It's "PureBasic". That's why Pure is in the name.
It takes the elements of Basic, but enhances them to becomes its own product.

It's not that hard to get used to PureBasic. I also prefer Instr() to FindString(),
and "Local" to "Protected" for variables, but I'm not going have an 8-year chip
on my shoulder about it. Every Basic does things differently to what you expect
from other Basics. It's nothing to stress over. Just use macros to tailor it to your
own cosmetic needs -- that's one reason macros exist.

[Gadget]

Must admit, I still miss the "Function" keyword from HiSoft Basic, way back. It made a nice distinction from Procedure and, at the risk of being flamed, I too would like to see it in PureBasic (without modifying how Procedure currently works).

Still, Little Johns example of using a macro looks like a great workaround that I'll move forward with. Thanks es_91, for raising the suggestion !

[es_91]

8 years of love and still pissed over a keyword?

Yes. "Pissed" might be to strong, but how do ya say? It concerns me since we all use Procedure a lot and it is so obviously a lone-walk of Fantaisie Software.

Perhaps the keyword for the various Sub/Subroutine/Proc/Procedure/Function type of functionality in a programming language should be named EntryPoint.

If it would add to the "scientificement" of that language, why not?

[Shield]

That's just a matter of definition and not a matter that matters.

As mentioned before, some languages have separate meanings of functions and
procedures, other don't. In C, procedures are called functions with return type 'void'.
In Java / C#, routines within classes are called methods while C++ calls them member functions,
Visual Basic calls procedures sub routines.

For most intents and purposes, all of those can be used synonymously.