Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Sharon Tuttle
(Just my two cents, because in my scanning of this thread so far, I don’t 
*think* I have seen this…)

Hmm; there are still languages where function and procedure are two 
syntactically-different things (and subroutine is a useful “overall" term there 
so you don’t have to always say “procedure or function”). For example, in 
PL/SQL, a function is a subroutine that returns a value, and a procedure is a 
subroutine that does not return a value, and their header syntaxes are distinct 
accordingly.
(And I have wondered whether PL/SQL “inherited” that distinction from Ada, but 
I’ve never been sure about that.)

(Of course, PL/SQL actually has three syntactically-distinct kinds of 
subroutines, as it also has triggers, which are not explicitly called at all, 
but get invoked before or after a triggering action, and have their own 
distinct header syntax accordingly… 8 - ) )

So, since the terms aren’t really synonyms, I would hope that Racket 
documentation would, over time, converge on using them in an agreed-upon way 
that goes with the history of those terms. (That is, decide in the community 
about how terms should work with regard to side-effects, and go from there. 
But, putting on my curmudgeon hat, by gum, functions return something and 
procedures don’t! 8 - ) )

— Sharon Tuttle

--
Sharon M. Tuttle, Professor
Department of Computer Science
Humboldt State University, Arcata, CA
sharon.tut...@humboldt.edu






> On Jan 22, 2019, at 5:49 PM, Anthony Carrico  wrote:
> 
> On 1/22/19 6:56 PM, Jon Zeppieri wrote:
>>[25 messages]
>> 
>> 
>> I think Wadler's Law needs an update.
> 
> Long live the internet!
> 
> Op: Should we call them functions or procedures?
> A: Functions!
> B: Functions!
> C: Functions!
> D: Functions!
> E: But it's a procedural language, and we've called them procedures for
> 30 years, so why not call them procedures?
> F: Functions don't really exist only procedures! So let's call them
> functions!
> G: Huh?
> H: Wadler's Law
> Me: Must... Resist... Being... A... Troll...
> 
> Fail
> 
> -- 
> Anthony Carrico
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Anthony Carrico
On 1/22/19 6:56 PM, Jon Zeppieri wrote:
> [25 messages]
> 
> 
> I think Wadler's Law needs an update.

Long live the internet!

Op: Should we call them functions or procedures?
A: Functions!
B: Functions!
C: Functions!
D: Functions!
E: But it's a procedural language, and we've called them procedures for
30 years, so why not call them procedures?
F: Functions don't really exist only procedures! So let's call them
functions!
G: Huh?
H: Wadler's Law
Me: Must... Resist... Being... A... Troll...

Fail

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread George Neuner



On 1/22/2019 6:25 PM, Zelphir Kaltstahl wrote:

>> I disagree on one more point. It is not necessary to always remember
>> the low level character of code running on a machine, if the language
>> we are using abstracts it well and guarantees us, that there will not
>> be strange effects in all the relevant cases for our programs.
>
> But a language CAN'T guarantee that there will not be effects -
> "strange" or otherwise.  Spectre attacks work even against code that
> is correct WRT its programming language because languages either are
> ignorant of - or are intentionally ignoring - side effects of those
> fiddly little machine operations.


That is a connection I do not fully understand. Spectre attack is
something designed to break the system, or out of previously known
bounds of what some code could do.


Spectre is a family of related attacks.  They are not against the 
program per se, they are against the *hardware* - the CPU and/or the 
memory system of the computer.  They (ab)use side effects of those 
fiddly little machine operations that you seem determined to ignore.  
Modern CPUs provide many information channels that can leak data from 
running programs if you know how to force them to do so.


Spectre attacks do not care what language was used to write the program, 
and they work against code which is perfectly correct at the language level.


There's a lot of very technical information out there, but a pretty good 
primer on the problem and explanation of the 1st discovered variant is 
at:  https://spectreattack.com/spectre.pdf




Can such a thing happen
unintentionally, when we write useful / constructive / productive / well
meaning programs? I guess theoretically, but very very unlikely?


Last I looked there were over 100 known Spectre variants - exploiting 
various information channels in various and different ways - with 
researchers announcing one or more new variants each week.




I get that there is a chance of something having a strange effect, when
the CPU is this kind of buggy (Intel cutting corners, still waiting for
my free of charge sent replacement CPU, free from such bugs, being
inserted in my machines for me by Intel :D), but that problem is on a
lower layer of abstraction. If the language we use is in itself correct,
isn't it then up to the lower layers to get things right? Afaik Spectre
(or was that Meltdown?) are only possible, because of over optimistic
branch prediction stuff (not an expert on such low level details at all,
just from what I read online). Couldn't we construct hardware free of
such mistakes? Or is there something fundamental, that will not allow
that, so that we cannot ever have a language guaranteeing things?


You absolutely can construct a CPU that is resistant to Spectre: one 
such WAS called the 80486 and it was obsolete 25 years ago.


Branch prediction is only ONE variant of the problem - there are many 
others.  And Intel is not unique in being vulnerable - Spectre affects 
chips from nearly every vendor, and in fact, it affects most chips on 
the market today.


Spectre vulnerability can't be designed out without either a radical 
rethink of CPU architecture (e.g., the Mill, which still is vaporware - 
https://millcomputing.com) or by returning to the [lack of] performance 
of designs from decades past.


Go poke around in comp.arch - they discuss Spectre rather frequently, 
and in more detail than you can imagine.



George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Jon Zeppieri
>
> [25 messages]
>

I think Wadler's Law needs an update.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Zelphir Kaltstahl


On 1/23/19 12:32 AM, Hendrik Boom wrote:
> On Tue, Jan 22, 2019 at 01:52:15AM -0500, George Neuner wrote:
>
>> I am arguing that, in computing, functions and procedures have no
>> significant difference, and that distinguishing them erroneously conflates
>> computing with mathematics and thus confuses people.
> The distinction I've heard from people that care abut these things and that
> seems to make sense are fo divide these subrutines into
>
> * procedures
>   * do things, have side effects
> * Value-returning procedures
>   * procedures that happen to return values
> * functions
>   * that return values and have no side effects (or side dependencies?)
>
> But it hasn't been very practical to make these distinctions in computer
> programs, because there is no effective way to distinguish such 
> functions from value-returning proedures.
>
> The restriction that functions can use only other functions doesn't 
> really work because
>   * Too many things that behave like functions use side-effects 
> internally while returning values that depend only on their arguments.
>   * Applied strictly, it rules out memo pads.
>
> The distinction, if it could be practically enforced, would give 
> optimisers significant opportunity for program tranformation.
>
> -- hendrik
>
I think this is a vocabulary and definitions question. It is very useful
to be able to talk about these things and distinguish between them. For
example, one could demand a side effect free thing to be able to easily
write unit tests later on for that thing. Many parts of a program can
consist of side effect free things, before at some point there will be
side effects. Might be the only side effects are putting something out
on command line and the whole rest is always only depending on arguments
and never accessing anything global or outside of the scope. Also side
effect free parts can be distinguished in natural language, by the way
we talk about them and tested separately and more easily. Someone new to
the field will hopefully ask what the differences are and will learn
then and then be able to talk precisely about it as well.

This is a reason why I personally think making the distinction is
useful, even if you cannot have the side effect free stuff all the way
through every part of a useful usable program. Communication is an
important part, not only writing the code.

The definition you gave of the categories of subroutines is what I heard
/ read / saw as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Hendrik Boom
On Sun, Jan 20, 2019 at 12:10:13AM -0500, George Neuner wrote:
> 
> As Ellen already mentioned, fixed width integers - although exact values -
> have computational properties that are not shared with mathematical
> integers.  As soon as the computation overflows, all bets are off ... any
> number of mathematical invariants may no longer hold.

So Algol 68 called the usual integer type "int" instead of "integer".

> 
> The troubles with floating point are caused by the representation, but they
> aren't limited by it.  FP numbers are not simply "limited precision"
> approximations of real numbers, but actually are a fuzzy range that only
> contains the "limited precision" approximation, and you don't know where
> within that range the actual value lies.
> 
> FP math bears little resemblance to real math:
> 
>  * FP numbers are neither associative nor distributive
>  * even simple invariants like (A+B)-B = A or A+A = 2*A may not hold
>  * FP numbers don't necessarily have a multiplicative inverse: not all
>A have a B= 1/A such that A*B = 1
>  * FP numbers are not continuous:  e.g., B > 0 doesn't mean A+B > A
> 
> and there is plenty more.  The so-called BigFloat implementations don't
> change these properties - they simply push them out further away from the
> programmer [who still can be bitten by problems].

And that's why I approve of the practice of calling floating point 
types "float" instead of "real".

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Hendrik Boom
On Tue, Jan 22, 2019 at 01:52:15AM -0500, George Neuner wrote:

> 
> I am arguing that, in computing, functions and procedures have no
> significant difference, and that distinguishing them erroneously conflates
> computing with mathematics and thus confuses people.

The distinction I've heard from people that care abut these things and that
seems to make sense are fo divide these subrutines into

* procedures
  * do things, have side effects
* Value-returning procedures
  * procedures that happen to return values
* functions
  * that return values and have no side effects (or side dependencies?)

But it hasn't been very practical to make these distinctions in computer
programs, because there is no effective way to distinguish such 
functions from value-returning proedures.

The restriction that functions can use only other functions doesn't 
really work because
  * Too many things that behave like functions use side-effects 
internally while returning values that depend only on their arguments.
  * Applied strictly, it rules out memo pads.

The distinction, if it could be practically enforced, would give 
optimisers significant opportunity for program tranformation.

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Zelphir Kaltstahl
On 1/22/19 11:08 PM, George Neuner wrote:
>
> On 1/22/2019 2:31 PM, Zelphir Kaltstahl wrote:
>> If the terms procedures and functions in computing have no
>> significant difference, then why use two terms for the same thing, of
>> which one is already used in mathematics, enabling confusion to appear?
>>
>> This would make a fine argument for not using the word "function" for
>> computing at all and keep to using the term "procedure" all the way.
>
> That's what many older languages did - Fortran and Lisp being notable
> exceptions, but they can be forgiven because they were the first
> (abstraction able) programming languages, and their early users were
> people who knew and understood the difference between computing and
> mathematics. 
>
> In the world of syntax design, wholesale use of the term "function" -
> *relatively* - is a new thing.


Hmmm. In general I have to say, I tend to "vote" for using the terms,
that are most precise, even if people do not understand, in hope of
making them wonder and maybe ask themselves, why someone would use that
term instead of another: "Why are they talking about procedures all the
time, instead of functions? Is there a difference?" and then maybe they
will find out or ask. Also to not contribute to making people think it
is the same as mathematical functions.
I think using the term "function" rather hides that and does not inspire
thinking about it. For example the recorded SICP lecture also made me
more conscious about my usage of the word "function". So did some other
FP articles and language tutorials.
I ask myself: Shouldn't we strive to understand just as much as people
before us, even if that means getting used to using their terminology,
since they knew what they were talking about?


>> I disagree on one more point. It is not necessary to always remember
>> the low level character of code running on a machine, if the language
>> we are using abstracts it well and guarantees us, that there will not
>> be strange effects in all the relevant cases for our programs.
>
> But a language CAN'T guarantee that there will not be effects -
> "strange" or otherwise.  Spectre attacks work even against code that
> is correct WRT its programming language because languages either are
> ignorant of - or are intentionally ignoring - side effects of those
> fiddly little machine operations.


That is a connection I do not fully understand. Spectre attack is
something designed to break the system, or out of previously known
bounds of what some code could do. Can such a thing happen
unintentionally, when we write useful / constructive / productive / well
meaning programs? I guess theoretically, but very very unlikely?

I get that there is a chance of something having a strange effect, when
the CPU is this kind of buggy (Intel cutting corners, still waiting for
my free of charge sent replacement CPU, free from such bugs, being
inserted in my machines for me by Intel :D), but that problem is on a
lower layer of abstraction. If the language we use is in itself correct,
isn't it then up to the lower layers to get things right? Afaik Spectre
(or was that Meltdown?) are only possible, because of over optimistic
branch prediction stuff (not an expert on such low level details at all,
just from what I read online). Couldn't we construct hardware free of
such mistakes? Or is there something fundamental, that will not allow
that, so that we cannot ever have a language guaranteeing things?


>> What I am relating to is:
>>
>> > The computer abstraction of "applying a function" can only be
>> stretched
>> > so far.  Those fiddly little "steps" that approximate the function
>> can't
>> > legitimately be ignored: they consumed time and energy, and [barring
>> > bugs] in the end they gave you only an approximation - not an answer
>>
>> Yes it can only be stretched that far (not infinite resources,
>> precision etc.), however, there are many situations, where I think
>> the stepwise nature can be legitimately ignored. I would say, if a
>> language is well designed and the interpreter / compiler and things
>> in between that run it are proven to be correct, I do not see, why we
>> should not ignore the stepwise nature of code execution. Why would it
>> be useful to look at that, provided our program is sufficiently
>> performant and does what we want? Furthermore they often do give me
>> an answer. It may not always be the case for numbers, because of
>> precision and such things, but think of things like joining together
>> some strings, some constructs well defined in the language we use and
>> the result of such procedure call would be an answer and not only an
>> approximation.
>>
>> I don't think it's a good idea to conflate the meaning of "function",
>> from my current level of experience at least ;)
>
> The problem is that there are far more situations where the
> abstraction leaks (or fails utterly) than there are situations where
> the abstraction holds.  That's why programming should 

Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread George Neuner


On 1/22/2019 2:31 PM, Zelphir Kaltstahl wrote:
If the terms procedures and functions in computing have no significant 
difference, then why use two terms for the same thing, of which one is 
already used in mathematics, enabling confusion to appear?


This would make a fine argument for not using the word "function" for 
computing at all and keep to using the term "procedure" all the way.


That's what many older languages did - Fortran and Lisp being notable 
exceptions, but they can be forgiven because they were the first 
(abstraction able) programming languages, and their early users were 
people who knew and understood the difference between computing and 
mathematics.


In the world of syntax design, wholesale use of the term "function" - 
*relatively* - is a new thing.



I disagree on one more point. It is not necessary to always remember 
the low level character of code running on a machine, if the language 
we are using abstracts it well and guarantees us, that there will not 
be strange effects in all the relevant cases for our programs.


But a language CAN'T guarantee that there will not be effects - 
"strange" or otherwise.  Spectre attacks work even against code that is 
correct WRT its programming language because languages either are 
ignorant of - or are intentionally ignoring - side effects of those 
fiddly little machine operations.




What I am relating to is:

> The computer abstraction of "applying a function" can only be stretched
> so far.  Those fiddly little "steps" that approximate the function 
can't

> legitimately be ignored: they consumed time and energy, and [barring
> bugs] in the end they gave you only an approximation - not an answer

Yes it can only be stretched that far (not infinite resources, 
precision etc.), however, there are many situations, where I think the 
stepwise nature can be legitimately ignored. I would say, if a 
language is well designed and the interpreter / compiler and things in 
between that run it are proven to be correct, I do not see, why we 
should not ignore the stepwise nature of code execution. Why would it 
be useful to look at that, provided our program is sufficiently 
performant and does what we want? Furthermore they often do give me an 
answer. It may not always be the case for numbers, because of 
precision and such things, but think of things like joining together 
some strings, some constructs well defined in the language we use and 
the result of such procedure call would be an answer and not only an 
approximation.


I don't think it's a good idea to conflate the meaning of "function", 
from my current level of experience at least ;)


The problem is that there are far more situations where the abstraction 
leaks (or fails utterly) than there are situations where the abstraction 
holds.  That's why programming should be considered engineering rather 
than science.  [In truth, I think programming is more an art than an 
engineering discipline, but that's a different discussion.]



As you noted, a major problem area is numerics.  But it's more of a 
problem than you realize.  The average programmer today has had no math 
beyond high school, and consequently most uses of floating point are 
unstable and buggy.  There is far too much code that works by 
happenstance rather than by careful design.


In the past, it was true that more programs worked with strings (or 
symbols) than with numbers, but that no longer is the case.  Today, 
numerically dominated programs vastly outnumber symbolically dominated ones.


There are quite a few CS scholars who think the default for safe 
programming languages should be arbitrary precision, decimal 
arithmetic.  Rational arithmetic in Racket (and Scheme and Lisp) 
similarly is safe, but the fractional representation is off-putting to 
many people.  Something more like BigFloat would be a more palatable 
choice for the masses.


[1] You may (or not) remember that stock prices used to be quoted using 
fractions: e.g., $42 ^3 /_8 .  When online brokerages allowed the masses 
to begin trading, stock pricing was changed to be in decimal units 
because it was found that ordinary people found it too difficult to 
compare prices expressed as fractions: e.g., is ^3 /_8 greater or less 
than ^11 /_32 ?


[2] The tee shirt saying "5 out of 4 people have a problem with 
fractions" is, unfortunately, not a joke.



YMMV,
George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Zelphir Kaltstahl
If the terms procedures and functions in computing have no significant 
difference, then why use two terms for the same thing, of which one is 
already used in mathematics, enabling confusion to appear?

This would make a fine argument for not using the word "function" for 
computing at all and keep to using the term "procedure" all the way. This 
is also btw. what I take from the recorded videos of SICP lectures 
(https://www.youtube.com/watch?v=2Op3QLzMgSY=PL8FE88AA54363BC46). 
Somewhere in the first lectures Abelson or Sussman state, that a "function" 
is a term used in mathematics and then he goes over to immediately talking 
about procedures instead. To me this makes perfect sense and makes a point 
of distinguishing between the two things, without introducing the word 
function into our programming or computing vocabulary.

I disagree on one more point. It is not necessary to always remember the 
low level character of code running on a machine, if the language we are 
using abstracts it well and guarantees us, that there will not be strange 
effects in all the relevant cases for our programs. What I am relating to 
is:

> The computer abstraction of "applying a function" can only be stretched 
> so far.  Those fiddly little "steps" that approximate the function can't 
> legitimately be ignored: they consumed time and energy, and [barring 
> bugs] in the end they gave you only an approximation - not an answer

Yes it can only be stretched that far (not infinite resources, precision 
etc.), however, there are many situations, where I think the stepwise 
nature can be legitimately ignored. I would say, if a language is well 
designed and the interpreter / compiler and things in between that run it 
are proven to be correct, I do not see, why we should not ignore the 
stepwise nature of code execution. Why would it be useful to look at that, 
provided our program is sufficiently performant and does what we want? 
Furthermore they often do give me an answer. It may not always be the case 
for numbers, because of precision and such things, but think of things like 
joining together some strings, some constructs well defined in the language 
we use and the result of such procedure call would be an answer and not 
only an approximation.

I don't think it's a good idea to conflate the meaning of "function", from 
my current level of experience at least ;)

On Tuesday, January 22, 2019 at 6:52:22 AM UTC, gneuner2 wrote:
>
>
> On 1/21/2019 11:52 PM, Anthony Carrico wrote: 
> > On 1/18/19 6:36 PM, George Neuner wrote: 
> > > Historically, many computer language designers were mathematicians, 
> and 
> > > they deliberately sought to distinguish "computer" functions from 
> > > "mathematical" functions. 
> > > 
> > > It has yet to work completely - witness the legions of newbies every 
> > > year who don't understand that computer arithmetic differs from the 
> math 
> > > they were taught in school. 
> > 
> > 
> > George: Aren't you making my case here? The mathematicians actually have 
> > the same trouble with their components as we engineers! Stoy says, "a 
> > careful distinction is vital in the case of functions", admonishing us 
> > not to "confuse functions with the algorithms representing them." 
> > Weren't Schemers making this distinction with the word "procedure"? 
>
> You and I may, in fact, agree on the basis - but I don't believe we are 
> arguing the same things. 
>
> If I understand correctly, you are arguing that computing should 
> distinguish functions from procedures because functions have a 
> connection [however tenuous] to mathematics that procedures do not. 
>
> I am arguing that, in computing, functions and procedures have no 
> significant difference, and that distinguishing them erroneously 
> conflates computing with mathematics and thus confuses people. 
>
>
> You began by saying: 
> >> However, for practical reasons, the programming community is now 
> >> placing more emphasis on the distinction between functional and 
> >> procedural abstraction, so I'm very surprised to see the Racket 
> >> community rally to eliminate it. Even within the same abstraction 
> >> mechanism, the two ideas are very useful. 
>
> The problem I see is that the ideas AREN'T separate. 
>
> Somewhere upward in this thread I wrote [not necessarily to you, 
> Anthony] that mathematical functions simply are, whereas their 
> corresponding computer "functions" are a series of steps that, at best, 
> can only approximate the result of the mathematical version. 
>
> There is no "series of steps" distinction between a computer function 
> and procedure - they both are a series of steps. 
>
> The computer abstraction of "applying a function" can only be stretched 
> so far.  Those fiddly little "steps" that approximate the function can't 
> legitimately be ignored: they consumed time and energy, and [barring 
> bugs] in the end they gave you only an approximation - not an answer. 
>
> For computing, "function" vs 

Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Anthony Carrico
On 1/22/19 6:49 AM, Jos Koot wrote:
> "It is often the case that
> arbitrary procedures don't compose meaningfully, whereas procedures that
> represent functions always compose meaningfully. "
> 
> functions f and g can be composed meaningfully only if the domain of
> f is compatible with the co-domain of g.

Perfect.

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-22 Thread Jos Koot
You write:

> "It is often the case that
> arbitrary procedures don't compose meaningfully, whereas procedures that
> represent functions always compose meaningfully. "
>
> functions f and g can be composed meaningfully only if the domain of f is
> compatible with the co-domain of g.


Jos

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-21 Thread George Neuner



On 1/21/2019 11:52 PM, Anthony Carrico wrote:

On 1/18/19 6:36 PM, George Neuner wrote:
> Historically, many computer language designers were mathematicians, and
> they deliberately sought to distinguish "computer" functions from
> "mathematical" functions.
> 
> It has yet to work completely - witness the legions of newbies every

> year who don't understand that computer arithmetic differs from the math
> they were taught in school.


George: Aren't you making my case here? The mathematicians actually have
the same trouble with their components as we engineers! Stoy says, "a
careful distinction is vital in the case of functions", admonishing us
not to "confuse functions with the algorithms representing them."
Weren't Schemers making this distinction with the word "procedure"?


You and I may, in fact, agree on the basis - but I don't believe we are 
arguing the same things.


If I understand correctly, you are arguing that computing should 
distinguish functions from procedures because functions have a 
connection [however tenuous] to mathematics that procedures do not.


I am arguing that, in computing, functions and procedures have no 
significant difference, and that distinguishing them erroneously 
conflates computing with mathematics and thus confuses people.



You began by saying:
However, for practical reasons, the programming community is now 
placing more emphasis on the distinction between functional and 
procedural abstraction, so I'm very surprised to see the Racket 
community rally to eliminate it. Even within the same abstraction 
mechanism, the two ideas are very useful.


The problem I see is that the ideas AREN'T separate.

Somewhere upward in this thread I wrote [not necessarily to you, 
Anthony] that mathematical functions simply are, whereas their 
corresponding computer "functions" are a series of steps that, at best, 
can only approximate the result of the mathematical version.


There is no "series of steps" distinction between a computer function 
and procedure - they both are a series of steps.


The computer abstraction of "applying a function" can only be stretched 
so far.  Those fiddly little "steps" that approximate the function can't 
legitimately be ignored: they consumed time and energy, and [barring 
bugs] in the end they gave you only an approximation - not an answer.


For computing, "function" vs "procedure" is a distinction without a 
difference [at least a significant difference].  The mathematical sense 
of "function" doesn't exist, and teaching people that computers / 
languages can provide mathematical guarantees is - I think - both 
misleading and a disservice to the learner.




Should an engineering education sweep the distinction between the
abstract and the concrete under the rug?


In engineering the distinction actually exists - and it is not ignored.  
Engineering takes great pains to call attention to the difference 
because there is NO mathematical certainty in engineering - however 
close, everything is just an approximation.


Computing IS engineering - which I think is at least part of your point.
My [not quite the same] point is that computing IS NOT math and should 
not be conflated with it.




> The problem is that quite a lot of the talk about functional programming
> is just marketing.

So, are people gravitating away from the word "procedure" because
"functional" is now being marketed? But seriously...


What people choose to call something is related to their understanding 
[or lack thereof] of the subject.


In any case, it's a different question than why people are gravitating 
toward languages that *claim* to provide more mathematical guarantees.  
The average programmer today has only high school math, no computer 
science education, and has programming skills that are only slightly 
better than "script kiddie".


I would argue that they don't understand that the so-called 
"mathematical guarantees" being offered are a sham, and so most of the 
increased use of such "mathematical" languages is merely the result of a 
marketing effect.



There is also the "shiny new object" effect.  I don't put any stock in 
growth numbers ... the real measure of a language is its steady state - 
how many adopters are still using it 10 years later.


I've had a similar argument many times about sales of books.  I keep 
pointing out that sales of intro books are not a real measure of 
language use - lots of people will buy an intro book and then abandon 
the subject shortly thereafter.  Sales of intermediate/advanced books 
are a much better measure, but they too can be misleading because at 
that level buyers may be interested in something *related* to the 
language but not the language itself.



YMMV,
George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, 

Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-21 Thread Anthony Carrico
On 1/18/19 6:36 PM, George Neuner wrote:
> Historically, many computer language designers were mathematicians, and
> they deliberately sought to distinguish "computer" functions from
> "mathematical" functions.
> 
> It has yet to work completely - witness the legions of newbies every
> year who don't understand that computer arithmetic differs from the math
> they were taught in school.

Ellen: I don't disagree with most of the points here, I just draw the
opposite conclusion.

Look at the example you selected: "compose". It is often the case that
arbitrary procedures don't compose meaningfully, whereas procedures that
represent functions always compose meaningfully. This is a hot topic
among programmers these days. Maybe the person who wrote this
documentation choose the word "function" for this reason?

As a parent, I wish Javascript had adopted the word "procedure" as
Scheme did. It is frustrating to try to teach your kids good
mathematical intuition with the help of resources like Khan Academy,
only to have the intuition undermined by conflicting lessons from the CS
side of the curriculum.

-

George: Aren't you making my case here? The mathematicians actually have
the same trouble with their components as we engineers! Stoy says, "a
careful distinction is vital in the case of functions", admonishing us
not to "confuse functions with the algorithms representing them."
Weren't Schemers making this distinction with the word "procedure"?

Should an engineering education sweep the distinction between the
abstract and the concrete under the rug? It's useful to distinguish the
mappings/functions/relationships that interest me from the toolbox of
algorithms/procedures/languages/devices that I use to represent them.
Consider:

"This procedure perfectly captures our (finite) function".

"This system is a compact realization of the function, but unstable for
certain inputs. On the other hand, this system converges for all inputs,
but has a long phase delay."

"This (infinite) function is impossible to represent on a computer, but
we can generate whatever finite portion you require."

You can't even make these statements if you abolish the distinctions.
Hence my astonishment that Racketeers, teaching experts, are stepping
away from the word they inherited from Scheme.

> The problem is that quite a lot of the talk about functional programming
> is just marketing.

So, are people gravitating away from the word "procedure" because
"functional" is now being marketed? But seriously...

> The languages can't live up to the promise of mathematical purity,
... etc.

Nobody is looking to program a pure function devoid of effects. It's
about making computation (including effects) understandable to people.
The motivation behind functional programming (and most engineering
discipline) is that humans can't really understand complex systems of
effects very well, and so we try to look for components whose meanings
compose. Functions are emblematic of that sort of composition--hence the
name. Operating under this slogan, people have come up with several ways
of composing effects, and we haven't seen the final chapter in that
story. Computer scientists haven't quite broken down their field into
the pieces that fit together nicely, but why discount the progress they
are making?

> WRT eliminating the distinction - that was dead and buried before
> Racket began.  There are no pure functional computer languages, and
> there never will be:  real programs have to interact with the impure
> real world.

Wait: you say the distinction is dead and buried, and then proceed to
highlight it? Where would humanity be if we adopted the stance that we
should never model anything just because our models can't be perfectly
realized on a finite computer, or even worse, an analog machine?

I didn't have a CS education, so maybe I just have a different
perspective, however, I also haven't seen much evidence presented in
this thread that the word "procedure" hurts anything. Why not stick with
what seems to be an accurate term and avoid confusion down the line?

> YMMV,
> George

PS: Thanks for the sparring. Think on this: we couldn't even have this
conversation without the distinction.

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-19 Thread George Neuner



And one by our own Jay McCarthy (with Neil Toronto)

https://www.computer.org/cms/Computer.org/ComputingNow/issues/2014/10/mcs2014040080.pdf

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-19 Thread George Neuner


On 1/19/2019 10:37 PM, David Storrs wrote:
On Fri, Jan 18, 2019, 6:36 PM George Neuner  wrote:



 witness the legions of newbies every
year who don't understand that computer arithmetic differs from
the math
they were taught in school.


Does it? Bit of a philosophical question, it seems. I mean, so long as 
you stick with integers, if you start with the same numbers and run 
them through the same operations then you will end up with the same 
results regardless of whether you did it on paper or in a computer. 
Things get a little weird once you start going into floating point, 
but I contend that that's a difference in 
implementation/representation, not in math.




As Ellen already mentioned, fixed width integers - although exact values 
- have computational properties that are not shared with mathematical 
integers.  As soon as the computation overflows, all bets are off ... 
any number of mathematical invariants may no longer hold.


The troubles with floating point are caused by the representation, but 
they aren't limited by it.  FP numbers are not simply "limited 
precision" approximations of real numbers, but actually are a fuzzy 
range that only contains the "limited precision" approximation, and you 
don't know where within that range the actual value lies.


FP math bears little resemblance to real math:

 * FP numbers are neither associative nor distributive
 * even simple invariants like (A+B)-B = A or A+A = 2*A may not hold
 * FP numbers don't necessarily have a multiplicative inverse: not all
   A have a B= 1/A such that A*B = 1
 * FP numbers are not continuous:  e.g., B > 0 doesn't mean A+B > A

and there is plenty more.  The so-called BigFloat implementations don't 
change these properties - they simply push them out further away from 
the programmer [who still can be bitten by problems].


There are any number of good references available, but here are a few 
[increasing in technicality] to get you started.


[1] 
http://www.phys.uconn.edu/~rozman/Courses/P2200_15F/downloads/floating-point-guide-2015-10-15.pdf

[2] http://people.ds.cam.ac.uk/nmm1/Arithmetic/index.html
[3] https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf


George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-19 Thread Ellen Spertus
On Sat, Jan 19, 2019 at 7:37 PM David Storrs  wrote:

>
>
> On Fri, Jan 18, 2019, 6:36 PM George Neuner 
>>
>>  witness the legions of newbies every
>> year who don't understand that computer arithmetic differs from the math
>> they were taught in school.
>>
>
> Does it? Bit of a philosophical question, it seems. I mean, so long as you
> stick with integers, if you start with the same numbers and run them
> through the same operations then you will end up with the same results
> regardless of whether you did it on paper or in a computer. Things get a
> little weird once you start going into floating point, but I contend that
> that's a difference in implementation/representation, not in math.
>

Even integers operations behave differently on computers than in math. Most
programming languages (or implementations) have 32- or 64-bit integers.

ob. xkcd: https://xkcd.com/571/

[image: image.png]

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-19 Thread David Storrs
On Fri, Jan 18, 2019, 6:36 PM George Neuner 
>  witness the legions of newbies every
> year who don't understand that computer arithmetic differs from the math
> they were taught in school.
>

Does it? Bit of a philosophical question, it seems. I mean, so long as you
stick with integers, if you start with the same numbers and run them
through the same operations then you will end up with the same results
regardless of whether you did it on paper or in a computer. Things get a
little weird once you start going into floating point, but I contend that
that's a difference in implementation/representation, not in math.

>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-18 Thread George Neuner



On 1/17/2019 11:41 AM, Anthony Carrico wrote:

Weird!

A procedure is a (branching) sequence of instructions.

Non-programmers have an accurate notion of the word from outside of
computer programming in recipes and instruction manuals.

A function maps inputs to outputs.

Non-programmers often use the word to denote a relationship between values.

Computer programmers lost or muddled the distinction (probably because
the same syntactic abstraction mechanism was used for both ideas).


Historically, many computer language designers were mathematicians, and 
they deliberately sought to distinguish "computer" functions from 
"mathematical" functions.


It has yet to work completely - witness the legions of newbies every 
year who don't understand that computer arithmetic differs from the math 
they were taught in school.




However, for practical reasons, the programming community is now placing
more emphasis on the distinction between functional and procedural
abstraction, so I'm very surprised to see the Racket community rally to
eliminate it. Even within the same abstraction mechanism, the two ideas
are very useful.


The problem is that quite a lot of the talk about functional programming 
is just marketing.  The languages can't live up to the promise of 
mathematical purity, and implementations, for the most part, don't even 
recognize and apply all the static optimizations that use of pure 
functions would make possible.


WRT eliminating the distinction - that was dead and buried before Racket 
began.  There are no pure functional computer languages, and there never 
will be:  real programs have to interact with the impure real world.


YMMV,
George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-17 Thread Anthony Carrico
Weird!

A procedure is a (branching) sequence of instructions.

Non-programmers have an accurate notion of the word from outside of
computer programming in recipes and instruction manuals.

A function maps inputs to outputs.

Non-programmers often use the word to denote a relationship between values.

Computer programmers lost or muddled the distinction (probably because
the same syntactic abstraction mechanism was used for both ideas).

However, for practical reasons, the programming community is now placing
more emphasis on the distinction between functional and procedural
abstraction, so I'm very surprised to see the Racket community rally to
eliminate it. Even within the same abstraction mechanism, the two ideas
are very useful.

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-15 Thread Greg Hendershott
I feel like every traditional term is subject to "how many angels can
dance on the tip of a parenthesis?" debates.

For example I prefer "function" but if we rename procedure-arity to
function-arity there will be people who complain that 1 is the only
correct value. :)

There are terms like "callable", but we have tail elimination.
"callable-and/or-jumpable" seems like a name that is both more
accurate and more horrible.

Something like "apply-able" or "applicable" seems better?  But we have
things like structs with prop:procedure, instances of which can be
applied.

So. Yeah. :)

I agree with you, George, what's most interesting is the possibilities
and the history trying them.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-14 Thread George Neuner



On 1/14/2019 9:56 AM, Laurent wrote:
I'm not entirely sure where I got that from, but to me a procedure is 
a ("impure") function with possible side effects (printing, mutating a 
global variable, sending emails, etc.). By contrast, in any given 
context, a function is (again, to me) synonymous with "pure 
function"(*) and can be called with the same values and will always 
return the same value, and could in principle be substituted with any 
other function implementating the same input-output specification 
without changing the meaning of the whole program.


(*) https://en.wikipedia.org/wiki/Pure_function


There is at least one language where the "subroutines" can't return 
values ... so what would you call them?

[Before you ask, the answer is Prolog.]

I've been programming [in a variety of languages] since the early 80s, 
and I've never heard this notion that "procedure" was synonymous with 
"impure function".   If you look through old texts, what distinguished 
procedures from functions was the *absence* of return values - which in 
turn meant that a procedure could do useful work only through side effects.


historically, most languages have conflated the two notions - 
syntactically offering a single impure form that can be either a 
function or a procedure.  But for the compiler - even with impurity - 
there can be considerable benefit to distinguish the form that returns 
values from the form that does not.   [Again, I would encourage people 
to study compiler texts - there's a lot of benefit to seeing how things 
are really done.]



Potentially, at least, there is even more benefit to knowing a function 
is pure - in theory at least a call with a given set of arguments could 
simply be replaced by the result.  But in practice, pure functions 
rarely are evaluated at compile time - far more often results computed 
at runtime are cached in case the same arguments are seen again.


George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-14 Thread Matthew Flatt
Just to confirm, some of us used to prefer the word "procedure" on the
grounds that Racket functions can have side effects. But we have
generally agreed to just prefer the word "function" from now on,
because the distinction isn't all that helpful and "function" is nicer
--- not just in HtDP, but in Racket documentation generally:

http://docs.racket-lang.org/style/reference-style.html#%28part._.Prose_and_.Terminology%29

Unfortunately, many Racket functions have "procedure" in the name, such
as `procedure?`. That's one of the things to fix a future variant of
Racket.

At Mon, 14 Jan 2019 14:56:36 +, Laurent wrote:
> I'm not entirely sure where I got that from, but to me a procedure is a
> ("impure") function with possible side effects (printing, mutating a global
> variable, sending emails, etc.). By contrast, in any given context, a
> function is (again, to me) synonymous with "pure function"(*) and can be
> called with the same values and will always return the same value, and
> could in principle be substituted with any other function implementating
> the same input-output specification without changing the meaning of the
> whole program.
> 
> (*) https://en.wikipedia.org/wiki/Pure_function
> 
> On Sun, Jan 13, 2019 at 8:30 PM George Neuner  wrote:
> 
> >
> > On 1/13/2019 1:49 PM, Alexis King wrote:
> >
> > Disclaimer: this answer is extremely non-authoritative.
> >
> >
> > Ditto.
> >
> > I think that, in Racket, the terms are used more or less interchangeably.
> > The technical term is “procedure”, but as you point out, the term
> > “function” is also used to mean the same thing. I don’t believe there is
> > any distinction there that would be universally understood.
> >
> > On the other hand, in How to Design Programs (and its various teaching
> > languages), my understanding is that “function” is the correct term and
> > “procedure” is strongly discouraged. The documentation on implementing new
> > teachpacks supports this understanding, in a section entitled Prohibited
> > Words
> > .
> > It states explicitly that “function” should be used instead of “procedure”,
> > “selector”, “constructor”, or any number of other terms. It includes the
> > following justification:
> >
> > These guidelines use few terms intentionally, emphasizing
> > commonality among concepts rather than technical precision (which most
> > students do not appreciate anyway).
> >
> >
> > I imagine others on this list who wrote the above words can give a more
> > authoritative answer should they find this one inadequate. :)
> >
> > Alexis
> >
> >
> >
> > Back in the day, "procedures" and "functions" were both considered a form
> > of "subroutine"  [see compiler texts from 70s .. 90s].  They were
> > distinguished from inline (GOTO) subroutines by being lexically scoped and
> > taking arguments.   Additionally, there was the distinction that (like its
> > mathematical counterpart) a "function" computed something and returned a
> > value (or values), while a "procedure" primarily was intended to create
> > side effects and (importantly) DID NOT return a value.
> >
> > Pascal enshrined that last distinction in its syntax, but it existed
> > already in earlier languages.
> >
> > Scheme uses the term "procedure" I *think* because it was influenced by
> > Algol.  For whatever reason, Algol called subroutines "proc" consistently
> > regardless of whether they returned a value.  Possibly Algol's designers
> > did that deliberately to avoid association with mathematical "functions".
> >
> > Racket began as PLT Scheme and remains (relatively) closely associated
> > with Scheme.  So it's not surprising that there are wrinkles in the
> > documentation.
> >
> >
> > Aside:  also back in the day, the term  "pure procedural"  referred to
> > programming without functions.  PP subsumed the notion of CPS, but was not
> > synonymous with it - if the language supported it, procedures were
> > permitted [in Ada parlance] to have "OUT" or "INOUT" parameters, through
> > which results could be passed back up the call chain.
> >
> >
> > To Ellen:  You might wish to educate your students re: the history.  For
> > modern use I think Alexis is right - the terms are used more or less
> > interchangeably and the historical distinctions largely have become
> > meaningless.
> >
> > YMMV,
> > George
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit 

Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-14 Thread Laurent
I'm not entirely sure where I got that from, but to me a procedure is a
("impure") function with possible side effects (printing, mutating a global
variable, sending emails, etc.). By contrast, in any given context, a
function is (again, to me) synonymous with "pure function"(*) and can be
called with the same values and will always return the same value, and
could in principle be substituted with any other function implementating
the same input-output specification without changing the meaning of the
whole program.

(*) https://en.wikipedia.org/wiki/Pure_function

On Sun, Jan 13, 2019 at 8:30 PM George Neuner  wrote:

>
> On 1/13/2019 1:49 PM, Alexis King wrote:
>
> Disclaimer: this answer is extremely non-authoritative.
>
>
> Ditto.
>
> I think that, in Racket, the terms are used more or less interchangeably.
> The technical term is “procedure”, but as you point out, the term
> “function” is also used to mean the same thing. I don’t believe there is
> any distinction there that would be universally understood.
>
> On the other hand, in How to Design Programs (and its various teaching
> languages), my understanding is that “function” is the correct term and
> “procedure” is strongly discouraged. The documentation on implementing new
> teachpacks supports this understanding, in a section entitled Prohibited
> Words
> .
> It states explicitly that “function” should be used instead of “procedure”,
> “selector”, “constructor”, or any number of other terms. It includes the
> following justification:
>
> These guidelines use few terms intentionally, emphasizing
> commonality among concepts rather than technical precision (which most
> students do not appreciate anyway).
>
>
> I imagine others on this list who wrote the above words can give a more
> authoritative answer should they find this one inadequate. :)
>
> Alexis
>
>
>
> Back in the day, "procedures" and "functions" were both considered a form
> of "subroutine"  [see compiler texts from 70s .. 90s].  They were
> distinguished from inline (GOTO) subroutines by being lexically scoped and
> taking arguments.   Additionally, there was the distinction that (like its
> mathematical counterpart) a "function" computed something and returned a
> value (or values), while a "procedure" primarily was intended to create
> side effects and (importantly) DID NOT return a value.
>
> Pascal enshrined that last distinction in its syntax, but it existed
> already in earlier languages.
>
> Scheme uses the term "procedure" I *think* because it was influenced by
> Algol.  For whatever reason, Algol called subroutines "proc" consistently
> regardless of whether they returned a value.  Possibly Algol's designers
> did that deliberately to avoid association with mathematical "functions".
>
> Racket began as PLT Scheme and remains (relatively) closely associated
> with Scheme.  So it's not surprising that there are wrinkles in the
> documentation.
>
>
> Aside:  also back in the day, the term  "pure procedural"  referred to
> programming without functions.  PP subsumed the notion of CPS, but was not
> synonymous with it - if the language supported it, procedures were
> permitted [in Ada parlance] to have "OUT" or "INOUT" parameters, through
> which results could be passed back up the call chain.
>
>
> To Ellen:  You might wish to educate your students re: the history.  For
> modern use I think Alexis is right - the terms are used more or less
> interchangeably and the historical distinctions largely have become
> meaningless.
>
> YMMV,
> George
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-13 Thread George Neuner


On 1/13/2019 1:49 PM, Alexis King wrote:

Disclaimer: this answer is extremely non-authoritative.


Ditto.

I think that, in Racket, the terms are used more or less 
interchangeably. The technical term is “procedure”, but as you point 
out, the term “function” is also used to mean the same thing. I don’t 
believe there is any distinction there that would be universally 
understood.


On the other hand, in How to Design Programs (and its various teaching 
languages), my understanding is that “function” is the correct term 
and “procedure” is strongly discouraged. The documentation on 
implementing new teachpacks supports this understanding, in a section 
entitled Prohibited Words 
. 
It states explicitly that “function” should be used instead of 
“procedure”, “selector”, “constructor”, or any number of other terms. 
It includes the following justification:


These guidelines use few terms intentionally, emphasizing 
commonality among concepts rather than technical precision (which 
most students do not appreciate anyway).


I imagine others on this list who wrote the above words can give a 
more authoritative answer should they find this one inadequate. :)


Alexis



Back in the day, "procedures" and "functions" were both considered a 
form of "subroutine"  [see compiler texts from 70s .. 90s].  They were 
distinguished from inline (GOTO) subroutines by being lexically scoped 
and taking arguments.   Additionally, there was the distinction that 
(like its mathematical counterpart) a "function" computed something and 
returned a value (or values), while a "procedure" primarily was intended 
to create side effects and (importantly) DID NOT return a value.


Pascal enshrined that last distinction in its syntax, but it existed 
already in earlier languages.


Scheme uses the term "procedure" I *think* because it was influenced by 
Algol.  For whatever reason, Algol called subroutines "proc" 
consistently regardless of whether they returned a value.  Possibly 
Algol's designers did that deliberately to avoid association with 
mathematical "functions".


Racket began as PLT Scheme and remains (relatively) closely associated 
with Scheme.  So it's not surprising that there are wrinkles in the 
documentation.



Aside:  also back in the day, the term  "pure procedural"  referred to 
programming without functions.  PP subsumed the notion of CPS, but was 
not synonymous with it - if the language supported it, procedures were 
permitted [in Ada parlance] to have "OUT" or "INOUT" parameters, through 
which results could be passed back up the call chain.



To Ellen:  You might wish to educate your students re: the history. For 
modern use I think Alexis is right - the terms are used more or less 
interchangeably and the historical distinctions largely have become 
meaningless.


YMMV,
George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-13 Thread Alexis King
Disclaimer: this answer is extremely non-authoritative.

I think that, in Racket, the terms are used more or less interchangeably. The 
technical term is “procedure”, but as you point out, the term “function” is 
also used to mean the same thing. I don’t believe there is any distinction 
there that would be universally understood.

On the other hand, in How to Design Programs (and its various teaching 
languages), my understanding is that “function” is the correct term and 
“procedure” is strongly discouraged. The documentation on implementing new 
teachpacks supports this understanding, in a section entitled Prohibited Words 
. It 
states explicitly that “function” should be used instead of “procedure”, 
“selector”, “constructor”, or any number of other terms. It includes the 
following justification:

> These guidelines use few terms intentionally, emphasizing commonality among 
> concepts rather than technical precision (which most students do not 
> appreciate anyway).

I imagine others on this list who wrote the above words can give a more 
authoritative answer should they find this one inadequate. :)

Alexis

> On Jan 13, 2019, at 11:37, Ellen Spertus  wrote:
> 
> Are "procedure" and "function" synonymous in Racket? It seems to be implied 
> by the documentation . For 
> example, the documentation for compose 
> 
>  describes it as a procedure that
> 
> [r]eturns a procedure that composes the given functions...The compose 
> function allows the given functions to consume and produce any number of 
> values...
> 
> (All of the above italicization was added by me.)
> 
> 
> 
> I understand that procedure? is a library procedure and function? is not. I 
> also understand the difference between a mathematical function and a computer 
> procedure (which might have side effects). What I'm trying to determine is 
> what language to use with my students this semester. (I like to use both 
> "procedure" and "function" because it's sometimes useful to have two 
> different words, as in the above documentation excerpt.)
> 
> 
> 
> FYI, I posted a version of this question to Stack Overflow 
> .
>  I got an answer but was referred here.
> 
> 
> 
> Thanks.
> 
> 
> 
> Ellen
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Are the terms "function" and "procedure" synonymous in Racket?

2019-01-13 Thread Ellen Spertus


Are "procedure" and "function" synonymous in Racket? It seems to be implied 
by the documentation . 
For example, the documentation for compose 

 describes 
it as a *procedure* that

[r]eturns a *procedure* that composes the given *functions*...The compose 
*function* allows the given *functions* to consume and produce any number 
of values...

(All of the above italicization was added by me.)


I understand that procedure? is a library procedure and function? is not. I 
also understand the difference between a mathematical function and a 
computer procedure (which might have side effects). What I'm trying to 
determine is what language to use with my students this semester. (I like 
to use both "procedure" and "function" because it's sometimes useful to 
have two different words, as in the above documentation excerpt.)


FYI, I posted a version of this question to Stack Overflow 
.
 
I got an answer but was referred here.


Thanks.


Ellen

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.