Re: generic function with val?

On Wed, Jan 27, 2010 at 2:46 PM, Raoul Duke <raould@gmail.com> wrote:

> There is none.  Functions cannot take type parameters.

ah, well, that explains it. although it is confusing given that you
can do it with def (and i mean that as def for a function, not def for
a method, if i've correctly interned things so far). what is the
reason?

There is no "def for a function".  The 'def' keyword defines a method with is associated with a class.
 

thanks.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

It's wrong because it implies that def is the only way to create a function.  What he's described there is a method.
For all practical purposes you can always think of methods as functions because, as soon as you need them to be, they *are* functions.


2010/1/27 Raoul Duke <raould@gmail.com>

hi,

On Wed, Jan 27, 2010 at 2:50 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
> There is no "def for a function".  The 'def' keyword defines a method with
> is associated with a class.

oh.

http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/scalagp.pdf

is horribly wrong in its use of the term "function"?

"Functions are defined using the def keyword. For example, the squaring
function on Doubles could be written:
def square (x : Double) : Double = x ∗ x
Scala distinguishes between definitions and values. In a definition def
x = e, the expression e will not be evaluated until x is used. Scala
also offers a value definition val x = e, in which the right-hand side
e is evaluated at the point of definition. However, only definitions can
take parameters; values must be constants."

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On Wed, Jan 27, 2010 at 2:59 PM, David Pollak
wrote:
> Yes, this is incorrect.

ok, thanks -- phew, maybe things will start to make some sort of
coherent sense. i get the feeling that Google's results for my
questions about Scala inevitably turn up "answers" which are simply
bad confusion on the part of other people. :-( i wish somebody could
redact that crap.

so anyway: why doesn't or can't Scala support generics for functions?
at some high enough level of abstraction and hand-waving, it would
'simply' ha ha mean that the [T] in val f = [T](x:T)=>x would be
"copied and pasted" into a [T] on the Apply method in the generated
object underlying the function?

sincerely.

On Wed, Jan 27, 2010 at 2:53 PM, Raoul Duke <raould@gmail.com> wrote:

hi,

On Wed, Jan 27, 2010 at 2:50 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
> There is no "def for a function".  The 'def' keyword defines a method with
> is associated with a class.

oh.

http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/scalagp.pdf

is horribly wrong in its use of the term "function"?

"Functions are defined using the def keyword. For example, the squaring
function on Doubles could be written:
def square (x : Double) : Double = x ∗ x
Scala distinguishes between definitions and values. In a definition def
x = e, the expression e will not be evaluated until x is used. Scala
also offers a value definition val x = e, in which the right-hand side
e is evaluated at the point of definition. However, only definitions can
take parameters; values must be constants."

Yes, this is incorrect. 



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Scala does support generics for functions.
Any function formed from a promoted method has generics, as does any function defined by explicitly defining apply() in an object (and preferably also subclassing FunctionNN)
The only place you can't have generics is with the sugared / anonymous function syntax, to the best of my knowledge.

2010/1/27 Raoul Duke <raould@gmail.com>

On Wed, Jan 27, 2010 at 2:59 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
> Yes, this is incorrect.

ok, thanks -- phew, maybe things will start to make some sort of
coherent sense. i get the feeling that Google's results for my
questions about Scala inevitably turn up "answers" which are simply
bad confusion on the part of other people. :-( i wish somebody could
redact that crap.

so anyway: why doesn't or can't Scala support generics for functions?
at some high enough level of abstraction and hand-waving, it would
'simply' ha ha mean that the [T] in val f = [T](x:T)=>x would be
"copied and pasted" into a [T] on the Apply method in the generated
object underlying the function?

sincerely.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

hi,

On Wed, Jan 27, 2010 at 3:11 PM, Kevin Wright
wrote:
> Scala does support generics for functions.
> Any function formed from a promoted method has generics, as does any
> function defined by explicitly defining apply() in an object (and preferably
> also subclassing FunctionNN)
> The only place you can't have generics is with the sugared / anonymous
> function syntax, to the best of my knowledge.

that doesn't explain /why/ not, which is what i was (attempting to?) asking. :}

sincerely.

> For all practical purposes you can always think of methods as functions
> because, as soon as you need them to be, they *are* functions.

no offense, but PLEASE do not perpetuate that meme, i really think it
has a lot to do with the problems i've had and seen others have in
learning what should be simple things about Scala. (i understand that
sometimes it is useful to sweep details under the carpet, but in this
case my overall call is that it does more harm than good, really.)

This is no more a meme than the theory of gravity.It's a hard fact about the behaviour of the scala compiler and is not at risk of suddenly becoming unfashionable.
The better simplification is to ignore 'methods' entirely and just think of everything as functions.  In which case, methods can just be viewed as a behind-the-scenes internal compiler optimisation.

2010/1/27 Kevin Wright <kev.lee.wright@googlemail.com>

I think a def inside a def actually gets lambda-lifted by the compiler and just becomes a privately named method...

or explicit outer, or some such thing 

2010/1/27 Naftoli Gugenheim <naftoligug@gmail.com>

What do you call a def say inside another def?

-------------------------------------
David Pollak<feeder.of.the.bears@gmail.com> wrote:

On Wed, Jan 27, 2010 at 2:46 PM, Raoul Duke <raould@gmail.com> wrote:

> > There is none.  Functions cannot take type parameters.
>
> ah, well, that explains it. although it is confusing given that you
> can do it with def (and i mean that as def for a function, not def for
> a method, if i've correctly interned things so far). what is the
> reason?
>

There is no "def for a function".  The 'def' keyword defines a method with
is associated with a class.


>
> thanks.
>



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

hi,

On Wed, Jan 27, 2010 at 3:00 PM, Kevin Wright
wrote:
> For all practical purposes you can always think of methods as functions
> because, as soon as you need them to be, they *are* functions.

no offense, but PLEASE do not perpetuate that meme, i really think it
has a lot to do with the problems i've had and seen others have in
learning what should be simple things about Scala. (i understand that
sometimes it is useful to sweep details under the carpet, but in this
case my overall call is that it does more harm than good, really.)

sincerely.

What do you call a def say inside another def?

-------------------------------------
David Pollak wrote:

On Wed, Jan 27, 2010 at 2:46 PM, Raoul Duke wrote:

> > There is none. Functions cannot take type parameters.
>
> ah, well, that explains it. although it is confusing given that you
> can do it with def (and i mean that as def for a function, not def for
> a method, if i've correctly interned things so far). what is the
> reason?
>

There is no "def for a function". The 'def' keyword defines a method with
is associated with a class.

>
> thanks.
>

On Wed, Jan 27, 2010 at 3:18 PM, Kevin Wright
wrote:
> This is no more a meme than the theory of gravity.
> It's a hard fact about the behaviour of the scala compiler and is not at
> risk of suddenly becoming unfashionable.
> The better simplification is to ignore 'methods' entirely and just think of
> everything as functions.  In which case, methods can just be viewed as a
> behind-the-scenes internal compiler optimisation.

hm, i think there is something still going "wrong" here because while
i can sorta parse what you say, it just doesn't ring true with how i
(think i) understand Scala. it could be something about connotation of
the term "function". or it could be that you are talking about 3
layers of abstraction whereas i have in mind only 2 vis.

SourceCodeFn->MethodOnObj->FnInCompiler
vs.
just SourceCodeFn->MethodOnObj.

??

sincerely.

but the question is, what is it _from a user point of view_. i mean you don't want to know the magic the compiler does to create java bytecode -- and hence since java doesn't have "functions" there can never be such thing as a function "in reality", but from a user perspective doesn't it make sense to speak of functions here? because they behave like them...

Am 27.01.2010 um 23:23 schrieb Kevin Wright:

>
>
> 2010/1/27 Kevin Wright
> I think a def inside a def actually gets lambda-lifted by the compiler and just becomes a privately named method...
>
> or explicit outer, or some such thing
>
> 2010/1/27 Naftoli Gugenheim
>
> What do you call a def say inside another def?
>
> -------------------------------------
> David Pollak wrote:
>
> On Wed, Jan 27, 2010 at 2:46 PM, Raoul Duke wrote:
>
> > > There is none. Functions cannot take type parameters.
> >
> > ah, well, that explains it. although it is confusing given that you
> > can do it with def (and i mean that as def for a function, not def for
> > a method, if i've correctly interned things so far). what is the
> > reason?
> >
>
> There is no "def for a function". The 'def' keyword defines a method with
> is associated with a class.
>
>
> >
> > thanks.
> >
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>
>

There are some differences between method defs and functions defs, such as overloading. Also, I'm not sure but I think sometimes to lift a method into a function, a class method needs a trailing _ while a nested function def may not.

-------------------------------------
Kevin Wright wrote:

>
>
> > For all practical purposes you can always think of methods as functions
> > because, as soon as you need them to be, they *are* functions.
>
> no offense, but PLEASE do not perpetuate that meme, i really think it
> has a lot to do with the problems i've had and seen others have in
> learning what should be simple things about Scala. (i understand that
> sometimes it is useful to sweep details under the carpet, but in this
> case my overall call is that it does more harm than good, really.)
>
>
This is no more a meme than the theory of gravity.
It's a hard fact about the behaviour of the scala compiler and is not at
risk of suddenly becoming unfashionable.

The better simplification is to ignore 'methods' entirely and just think of
everything as functions. In which case, methods can just be viewed as a
behind-the-scenes internal compiler optimisation.

In other words, why does the function literal syntax not support type arguments.

-------------------------------------
Raoul Duke wrote:

On Wed, Jan 27, 2010 at 3:39 PM, Rex Kerr wrote:
> Depends what you mean.

i just wanted (which i'm told is not at all supported, although nobody
has yet explained the rationale for it) something like:

val F = [T](x:T) => x

sincerely.

I think a def inside a def actually gets lambda-lifted by the compiler and just becomes a privately named method...

2010/1/27 Naftoli Gugenheim <naftoligug@gmail.com>

What do you call a def say inside another def?

-------------------------------------
David Pollak<feeder.of.the.bears@gmail.com> wrote:

On Wed, Jan 27, 2010 at 2:46 PM, Raoul Duke <raould@gmail.com> wrote:

> > There is none.  Functions cannot take type parameters.
>
> ah, well, that explains it. although it is confusing given that you
> can do it with def (and i mean that as def for a function, not def for
> a method, if i've correctly interned things so far). what is the
> reason?
>

There is no "def for a function".  The 'def' keyword defines a method with
is associated with a class.


>
> thanks.
>



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On Wed, Jan 27, 2010 at 3:39 PM, Rex Kerr wrote:
> Depends what you mean.

i just wanted (which i'm told is not at all supported, although nobody
has yet explained the rationale for it) something like:

val F = [T](x:T) => x

sincerely.

On Wed, Jan 27, 2010 at 4:04 PM, Miles Sabin wrote:
> there's no (useful) way to make it conform to scala.Function1, so even
> if we extended the function literal syntax in the way you've suggested
> we wouldn't easily be able to fit the resulting values into Scala's
> functional framework.

i know enough to know that i don't know enough in this case, so i'll
go with the old coor's ad claim of "if it's a fact, i'll believe it."

on the other hand i dream that somebody will one day wake up with the
solution apparent in a vision, and implement it. :-)

sincerely.

Could probably do something in a compiler-plugin, of course.
Though I can't say I've got any ambitions on this one myself...


2010/1/28 Raoul Duke <raould@gmail.com>

On Wed, Jan 27, 2010 at 4:04 PM, Miles Sabin <miles@milessabin.com> wrote:
> there's no (useful) way to make it conform to scala.Function1, so even
> if we extended the function literal syntax in the way you've suggested
> we wouldn't easily be able to fit the resulting values into Scala's
> functional framework.

i know enough to know that i don't know enough in this case, so i'll
go with the old coor's ad claim of "if it's a fact, i'll believe it."

on the other hand i dream that somebody will one day wake up with the
solution apparent in a vision, and implement it. :-)

sincerely.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On Wed, Jan 27, 2010 at 4:09 PM, Tony Morris wrote:
> See the RankNTypes extension to GHC.

i can't tell if that was meant for me, or for Scala devs? if the
former, i wasn't aware that Haskell had trouble with "generic" types
for functions :-)

fnC x = show x
fnB x = fnC x
fnA1 = putStrLn (fnB 42)
fnA2 = putStrLn (fnB "bar")

On Wed, Jan 27, 2010 at 11:42 PM, Raoul Duke wrote:
> On Wed, Jan 27, 2010 at 3:39 PM, Rex Kerr wrote:
>> Depends what you mean.
>
> i just wanted (which i'm told is not at all supported, although nobody
> has yet explained the rationale for it) something like:
>
> val F = [T](x:T) => x

The closest you can get to this is,

val f = new { def apply[T](x : T) = x }

Unfortunately, although it behaves exactly the way you want it to behave, eg.,

val s : String = f(23) // Error
val s : String = f("Hello world") // OK

there's no (useful) way to make it conform to scala.Function1, so even
if we extended the function literal syntax in the way you've suggested
we wouldn't easily be able to fit the resulting values into Scala's
functional framework.

Cheers,

Miles

Sadly, we're not cross-compiling to Haskell yet, though I do think somebody once asked for it...

2010/1/28 Tony Morris <tonymorris@gmail.com>

Raoul Duke wrote:
> On Wed, Jan 27, 2010 at 4:04 PM, Miles Sabin <miles@milessabin.com> wrote:
>
>> there's no (useful) way to make it conform to scala.Function1, so even
>> if we extended the function literal syntax in the way you've suggested
>> we wouldn't easily be able to fit the resulting values into Scala's
>> functional framework.
>>
>
> i know enough to know that i don't know enough in this case, so i'll
> go with the old coor's ad claim of "if it's a fact, i'll believe it."
>
> on the other hand i dream that somebody will one day wake up with the
> solution apparent in a vision, and implement it. :-)
>
> sincerely.
>
>
See the RankNTypes extension to GHC.

--
Tony Morris
http://tmorris.net/

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Raoul Duke wrote:
> On Wed, Jan 27, 2010 at 4:09 PM, Tony Morris wrote:
>
>> See the RankNTypes extension to GHC.
>>
>
> i can't tell if that was meant for me, or for Scala devs? if the
> former, i wasn't aware that Haskell had trouble with "generic" types
> for functions :-)
>
> fnC x = show x
> fnB x = fnC x
> fnA1 = putStrLn (fnB 42)
> fnA2 = putStrLn (fnB "bar")
>
>
It's an existing manfistation of your "dream".

$ ghci -XRankNTypes
> let f :: a -> (forall b. b) -> a; f = undefined
>

Raoul Duke wrote:
> On Wed, Jan 27, 2010 at 4:04 PM, Miles Sabin wrote:
>
>> there's no (useful) way to make it conform to scala.Function1, so even
>> if we extended the function literal syntax in the way you've suggested
>> we wouldn't easily be able to fit the resulting values into Scala's
>> functional framework.
>>
>
> i know enough to know that i don't know enough in this case, so i'll
> go with the old coor's ad claim of "if it's a fact, i'll believe it."
>
> on the other hand i dream that somebody will one day wake up with the
> solution apparent in a vision, and implement it. :-)
>
> sincerely.
>
>
See the RankNTypes extension to GHC.

Fortunately, one needn't cross-compile to Haskell to investigate an
existing open source solution to this problem.

Kevin Wright wrote:
> Sadly, we're not cross-compiling to Haskell yet, though I do think somebody
> once asked for it...
>
> 2010/1/28 Tony Morris
>
>
>> Raoul Duke wrote:
>>
>>> On Wed, Jan 27, 2010 at 4:04 PM, Miles Sabin
>>>
>> wrote:
>>
>>>> there's no (useful) way to make it conform to scala.Function1, so even
>>>> if we extended the function literal syntax in the way you've suggested
>>>> we wouldn't easily be able to fit the resulting values into Scala's
>>>> functional framework.
>>>>
>>>>
>>> i know enough to know that i don't know enough in this case, so i'll
>>> go with the old coor's ad claim of "if it's a fact, i'll believe it."
>>>
>>> on the other hand i dream that somebody will one day wake up with the
>>> solution apparent in a vision, and implement it. :-)
>>>
>>> sincerely.
>>>
>>>
>>>
>> See the RankNTypes extension to GHC.
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>
>

> Tony Morris
>>> See the RankNTypes extension to GHC.
> It's an existing manfistation of your "dream".

reading a little bit about RankNTypes e.g.

http://thread.gmane.org/gmane.comp.lang.haskell.cafe/40508/focus=40610

i'm still confused by your suggestion; i did not think that i wanted
the "callee" to determine the type of the argument, only the "caller".
like, i don't see how (from my perspective of not knowing or really
thinking i should have to care about the Scala compiler internals)

def F[T](x:T) = x

requires rank > 1, and so since i want the val version to be basically
the same idea i don't see how it should require rank-n support. but
perhaps it really does, for some creepy in-the-compiler reasons.

val F = [T](x:T) => x

sincerely.

hi,

On Wed, Jan 27, 2010 at 5:34 PM, Daniel Sobral wrote:
> And it _can't_ be provided, because F is a val, and vals do not receive
> parameters. Let's stand back and consider this again.
> We know that when we declare a "val", we assign the value of the expression
> into a field. So, into this field must go a function that receives a type
> parameter T and returns a Function1[T,T]. This does not exists in Scala at
> the present time.

thanks, i think the bit about "vals do not receive parameters" sorta
makes the most sense to me as an explanation. :)

i think part of my problem here is that i somehow thought val meant
function and def meant method. which i'm a little bit disabused of
now. i think.

sincerely.

On Thu, Jan 28, 2010 at 2:45 AM, Raoul Duke wrote:
> thanks, i think the bit about "vals do not receive parameters" sorta
> makes the most sense to me as an explanation. :)

Yeah, and I think that's a good explanation. There are simply no
values with polymorphic types. As I heard the restriction comes from
serious problems in typing/type infering when subtyping is involved.

> i think part of my problem here is that i somehow thought val meant
> function and def meant method. which i'm a little bit disabused of
> now. i think.

Actually, do you know how it came you mixed up things up like that?
The keyword val always defines a strictly evaluated value, even if
that value is a function object [1]. Def always defines a thing which
can be called. In an OOP context you would call that thing mostly
method because if it belongs to a class it always gets a this value
passed implicitly [2].

I'm asking, because I'm trying to see the bigger picture here. I'm not
yet sure how well Scala can be learned. You would expect some synergy
in this hybrid functional/OO setting but to understand these subtle
differences I've got the feeling that you need to know both sides of
the spectrum quite well, OO programming and concepts from functional
programming and finally some insights into the actual implementation.

That's no critic per se, because having done much OOP in the years
before Scala, I do understand most of the issues and I can reason and
decide about what I'm doing. (And coming from Java, Scala fixed most
of the obvious problems, so many things are just natural.) But Scala
as a first or second language seems to me quite confusing with all
those different possibilities how to do things.[3]

On Thu, Jan 28, 2010 at 12:59 AM, Johannes Rudolph
wrote:
> I'm asking, because I'm trying to see the bigger picture here. I'm not
> yet sure how well Scala can be learned. You would expect some synergy
> in this hybrid functional/OO setting but to understand these subtle
> differences I've got the feeling that you need to know both sides of
> the spectrum quite well, OO programming and concepts from functional
> programming and finally some insights into the actual implementation.

yes, i believe i strongly agree, based on my experience.

maybe such a thing exists already somewhere, but i haven't hit it yet:
i think the document i would like to see for teaching Scala is one
that is like 90% code and 10% explanation. like, the explanation can
say in a sentence what is going on, and then link-out to other more
detailed documents. the code would pick a particular topic of
confusion, and work it up slowly through examples from short
dead-simple ones in all their variation up to more complex things. it
would be nice if prior to each set of examples, there were succinct
warnings about mental models brought from other languages (mainly Java
and Haskell). i tried that for function vs. method recently but then
it turns out i was confused about def vs. val still! so there's yet
another thing out there possibly really polluting any future google
searches...

sincerely.

On Thu, Jan 28, 2010 at 12:59 AM, Johannes Rudolph
wrote:
>> i think part of my problem here is that i somehow thought val meant
>> function and def meant method. which i'm a little bit disabused of
>> now. i think.
>
> Actually, do you know how it came you mixed up things up like that?

i think if one uses google to search for scala knowledge, the docs
which come up often misuse or interchange "method" and "function". i
don't have more specific answers than that at the moment.

it would *really* be great if somebody could focus on making scala doc
pages that are (1) correct and (2) the top hits in any
scala-language-related searches! :-)

sincerely.

The problem is that the word "function" means several different things

1) a kind of platonic ideal of a certain kind of relation on sets.   f(x) = x + x and g(x) = 2 * x are two definitions for the same function.  Mostly only mathematicians think this way.
2) a "procedure", i.e. a callable body of code does something at runtime when called.  println is a function.  f and g are two different functions.  Methods are functions selected dynamically based on target object type.  This is very computer sciency.
3) a procedure that isn't a method.  This is very OO wonky.
4) apparently, in Scala-land, some people use "function" to mean specifically an object that instantiates one of the Function1, Function2, etc. classes. 
5) Others (e.g. a function is a procedure that does not return unit/void)

I can't even say that any of these are "misuses" except that maybe all of 2 through 5 are misuses.

On Thu, Jan 28, 2010 at 10:37 AM, Raoul Duke <raould@gmail.com> wrote:

On Thu, Jan 28, 2010 at 12:59 AM, Johannes Rudolph
<johannes.rudolph@googlemail.com> wrote:
>> i think part of my problem here is that i somehow thought val meant
>> function and def meant method. which i'm a little bit disabused of
>> now. i think.
>
> Actually, do you know how it came you mixed up things up like that?

i think if one uses google to search for scala knowledge, the docs
which come up often misuse or interchange "method" and "function". i
don't have more specific answers than that at the moment.

it would *really* be great if somebody could focus on making scala doc
pages that are (1) correct and (2) the top hits in any
scala-language-related searches! :-)

sincerely.

On Thu, Jan 28, 2010 at 10:46 AM, James Iry wrote:
> The problem is that the word "function" means several different things

i suspected as much, and agree.

> I can't even say that any of these are "misuses" except that maybe all of 2
> through 5 are misuses.

i a little bit don't agree in that i think people should be smart
enough (er, including me?) to know that such terms are overloaded, and
should try to be more clear/explicit.

sincerely.

On Thu, Jan 28, 2010 at 10:46 AM, James Iry <jamesiry@gmail.com> wrote:

The problem is that the word "function" means several different things

1) a kind of platonic ideal of a certain kind of relation on sets.   f(x) = x + x and g(x) = 2 * x are two definitions for the same function.  Mostly only mathematicians think this way.

I like to think of functions this way. But a function isn't a relation between sets, it *is* a set. In the same way that in elementary school geometry you learned that a circle is a set of points (all the ones exactly X distance from the center of your plane); a function is a set of (input, output) pairs that a) have some relationship between each input:output; and b) all input values are unique.

Pure functional programming operates on or near this definition of functions, I think.

Best regards,
Brian Maso
(949) 395-8551
brian@blumenfeld-maso.com
twitter: @bmaso
skype: brian.maso
LinkedIn: http://www.linkedin.com/in/brianmaso
 

2) a "procedure", i.e. a callable body of code does something at runtime when called.  println is a function.  f and g are two different functions.  Methods are functions selected dynamically based on target object type.  This is very computer sciency.
3) a procedure that isn't a method.  This is very OO wonky.
4) apparently, in Scala-land, some people use "function" to mean specifically an object that instantiates one of the Function1, Function2, etc. classes. 
5) Others (e.g. a function is a procedure that does not return unit/void)

I can't even say that any of these are "misuses" except that maybe all of 2 through 5 are misuses.

On Thu, Jan 28, 2010 at 10:37 AM, Raoul Duke <raould@gmail.com> wrote:

On Thu, Jan 28, 2010 at 12:59 AM, Johannes Rudolph
<johannes.rudolph@googlemail.com> wrote:
>> i think part of my problem here is that i somehow thought val meant
>> function and def meant method. which i'm a little bit disabused of
>> now. i think.
>
> Actually, do you know how it came you mixed up things up like that?

i think if one uses google to search for scala knowledge, the docs
which come up often misuse or interchange "method" and "function". i
don't have more specific answers than that at the moment.

it would *really* be great if somebody could focus on making scala doc
pages that are (1) correct and (2) the top hits in any
scala-language-related searches! :-)

sincerely.

On Thu, Jan 28, 2010 at 2:19 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

On Thu, Jan 28, 2010 at 10:46 AM, James Iry <jamesiry@gmail.com> wrote:

The problem is that the word "function" means several different things

1) a kind of platonic ideal of a certain kind of relation on sets.   f(x) = x + x and g(x) = 2 * x are two definitions for the same function.  Mostly only mathematicians think this way.

Pure functional programming operates on or near this definition of functions, I think.

Near: because even a purely functional programmer might care about the operational differences between f and g or some other pair of procedures that compute the same function, yet they'll still think of f and g "functions" rather than "procedures."

On Thu, Jan 28, 2010 at 6:39 PM, James Iry <jamesiry@gmail.com> wrote:

On Thu, Jan 28, 2010 at 2:19 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

On Thu, Jan 28, 2010 at 10:46 AM, James Iry <jamesiry@gmail.com> wrote:

The problem is that the word "function" means several different things

1) a kind of platonic ideal of a certain kind of relation on sets.   f(x) = x + x and g(x) = 2 * x are two definitions for the same function.  Mostly only mathematicians think this way.

Pure functional programming operates on or near this definition of functions, I think.

Near: because even a purely functional programmer might care about the operational differences between f and g or some other pair of procedures that compute the same function, yet they'll still think of f and g "functions" rather than "procedures."

Also "near" because from what I've observed, purely functional programmers think about types in a rather different way than a typical mathematician will.  (Unless, perhaps, that mathematician happens to specialize in category theory.)  Mathematical functions don't diverge, for example, and their definitions can get arbitrarily deep into special cases, which is not allowed as far as I can tell in languages like Haskell.

  --Rex