- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Scaladoc that is actually useful?
Are you sure they're not listed?
In Scala at least the primary constructor is looked at as "the arguments to the class." So it would be listed with documentation of the class itself.
-------------------------------------
Donald McLean wrote:
(observations based on 2.7.7 - feel free to say that something will be
better in 2.8 but only if it actually is)
I'm new to Scala but have been using Java for more than 10 years now.
One of the stumbling blocks that I am running into learning the
language is that the Scaladoc for many of the library classes is
nearly useless. The mutable LinkedList, for example is almost
impossible for a newbie to use because it is so completely unlike most
Java collections and the constructor is not listed in the Scaladoc.
So why aren't constructors listed in the Scaladoc? (though I haven't
yet progressed to the point where the syntax for the LinkedList class
makes sense yet, even if I have figured out how to use it)
And maybe some actual, even useful, descriptive text? If the answer is
"well, nobody has gotten around to it yet," I can understand that (and
will probably volunteer to help correct the problem, just as soon as I
can understand it myself)
Re: Scaladoc that is actually useful?
christopher marshall wrote:
> The fact that you are using => to mean the mathematical/logic
> "implies" seems to ignore the fact that in Scala, => means no such
> thing. A, B and C are not statements/sentences: in a scala signature,
> they are types and the signature tells me nothing about what the
> method/function actually does! *Why are we even arguing about this?*
Actually, in Scala it means exactly that. Please see the C-H Isomorphism.
RE: Scaladoc that is actually useful?
def foo(i: Int) : String
Tell me anything about what the function *actually does*, regardless of whether, under some given definition of "implies" the statement Int => String is "true", given foo. I must be completely missing some point here because for the life of me I don't really understand the train of thought that says that the type signature of a function is all you need to parse to understand what the function does.
> Date: Fri, 13 Nov 2009 10:31:34 +1000
> From: tonymorris [at] gmail [dot] com
> To: oxbow_lakes [at] hotmail [dot] com
> CC: jim [dot] andreou [at] gmail [dot] com; ichoran [at] gmail [dot] com; scala-user [at] listes [dot] epfl [dot] ch
> Subject: Re: [scala-user] Scaladoc that is actually useful?
>
>
>
> christopher marshall wrote:
> > The fact that you are using => to mean the mathematical/logic
> > "implies" seems to ignore the fact that in Scala, => means no such
> > thing. A, B and C are not statements/sentences: in a scala signature,
> > they are types and the signature tells me nothing about what the
> > method/function actually does! *Why are we even arguing about this?*
>
> Actually, in Scala it means exactly that. Please see the C-H Isomorphism.
>
> --
> Tony Morris
> http://tmorris.net/
>
>
Use Hotmail to send and receive mail from your different email accounts. Find out how.
Re: Scaladoc that is actually useful?
On Thursday November 12 2009, Dimitris Andreou wrote:
> 2009/11/13 Randall R Schulz :
> > ...
> >
> > A subroutine / method that accesses values not passed to it as
> > arguments does not compute a function. A method that produces
> > different values when called repeatedly with the same arguments
> > does not compute a function.
>
> Why? The world could contain a different B=>C function, and the
> method could be using that one instead of the exlicit B=>C argument
> of it, while still being a function.
Why?? Because _that's not a function_.
It's just some uncharacterized computation about which can say little
and prove nothing.
Randall Schulz
Re: Scaladoc that is actually useful?
On Thu, Nov 12, 2009 at 6:24 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: Scaladoc that is actually useful?
Unfortunately you have subverted the types. There is no ability to print
a universal type. This is an unfortunate part of the Java legacy.
There is only *one possible answer*.
Rex Kerr wrote:
> On Thu, Nov 12, 2009 at 3:55 PM, Tony Morris > wrote:
>
> e.g. What would you (could you possibly) write for this function?
> def boo[A, B, C](f: A => B, g: B => C): A => C
>
>
> That one? I don't know--it's titled "boo", so it should be a
> surprise. Maybe it returns a function that prints out "Boo!" and
> returns null. Maybe it returns the BooException and never completes
> normally.
>
> How about this one?
>
> def printIntermediate[A,B,C](f: A => B, g: B => C): A => C
>
> Same type signature. Maybe it, I don't know, creates a function that
> prints out the intermediate result of type B in addition to doing the
> function composition?
>
> How about
>
> def nullCatch[A,B,C](f: A => B, g: B => C): A => C
>
> Same type signature again. This might possibly catch if inputs are
> null and throw null outputs rather than throwing exceptions, in
> addition to composing the functions.
>
> If you don't document your functions, how are people supposed to know
> whether and what side effects there are, and whether the function is
> value-added (as in nullCatch) or not (as in the straightforward
> function-composition boo that I assume you were imagining)?
>
> --Rex
>
Re: Scaladoc that is actually useful?
2009/11/13 Tony Morris :
> Unfortunately you have subverted the types. There is no ability to print
> a universal type. This is an unfortunate part of the Java legacy.
So that was the implicit assumption all along. I hope this helps
ending this rather fruitless discussion.
As I said yesterday too, Tony is not really talking about scala, as
you can see above, about the "unfortunate part of the Java legacy". He
talks about an abstraction that he wishes is equivalent to scala. Only
through those glasses/assumptions some docs seem redundant. Yet, Tony
is somehow against documenting assumptions, which is basically a
wishful thinking that the whole scala community will just adopt the
same set of assumptions as he, so he does not need to mention them.
_In scala_, which is the context of discussion, there is a type
hierarchy rooted at Any. For all A, A<:Any. Now, Any is proven to have
a whole range of methods applicable to it, like like hashCode(), like
toString(). So, for all A, one can safely call toString(). I'm sure
someone might scream "subverting!" or "lying!" or "goosfraba!" again
and again but that is completely irrelevant. Point is: in scala, a
signature, even as generic as the aptly named "boo" signature, has
*infinite* different implementations. Knock knock, this is the real
world hitting the door. Now, we can all pretend instead that the real
world is irrelevant, and we could rather reason only through our neat
abstractions, but as someone said, this is kind of Platonic. But
again, Plato was Plato for all his life, wasn't he?
Dimitris
> There is only *one possible answer*.
>
> Rex Kerr wrote:
>> On Thu, Nov 12, 2009 at 3:55 PM, Tony Morris > > wrote:
>>
>> e.g. What would you (could you possibly) write for this function?
>> def boo[A, B, C](f: A => B, g: B => C): A => C
>>
>>
>> That one? I don't know--it's titled "boo", so it should be a
>> surprise. Maybe it returns a function that prints out "Boo!" and
>> returns null. Maybe it returns the BooException and never completes
>> normally.
>>
>> How about this one?
>>
>> def printIntermediate[A,B,C](f: A => B, g: B => C): A => C
>>
>> Same type signature. Maybe it, I don't know, creates a function that
>> prints out the intermediate result of type B in addition to doing the
>> function composition?
>>
>> How about
>>
>> def nullCatch[A,B,C](f: A => B, g: B => C): A => C
>>
>> Same type signature again. This might possibly catch if inputs are
>> null and throw null outputs rather than throwing exceptions, in
>> addition to composing the functions.
>>
>> If you don't document your functions, how are people supposed to know
>> whether and what side effects there are, and whether the function is
>> value-added (as in nullCatch) or not (as in the straightforward
>> function-composition boo that I assume you were imagining)?
>>
>> --Rex
>>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
Re: Scaladoc that is actually useful?
Believe what you will Dimitris. It has been very fruitful, as others
have testified on the list, in private email and other forms of
communication, and for that I am glad.
Since this topic is quite interesting, not debatable at all (see proof
by parametricity and theorems for free) and highly relevant to the topic
at hand, I am prepared to take it further for those who are fond of
learning, however, I shall await the outcome of discussions of how it is
most appropriate to do so. For example, the question was raised "what
about signatures with multiple inhabitants?", which is itself interesting.
I hope I don't come up against so much resistance to a provable and
proven basic tenet of computational theory again, but I am regularly
surprised (appalled?) at what appeasing "the average programmer" has
achieved in our industry. I suggest we stop doing that now (please oh
please?), but that's another topic!
Apologies for the noise to those who are well aware of the fact at hand
(and thanks for the emails and suggestions (except for "bash them over
the head" which is just a resignation to the pursuit)), but ultimately,
I am glad I pursued the matter for those who got some benefit in
learning, despite the recursive nature of the discussion.
Please let me know if you are interested in understanding this topic
further and I will see what I can do, but as I indicated in one comment,
I am currently overwhelmed with preparations for writing an essay
(book?) to the state medical health board regarding other matters.
I shall depart from this discussion pending aforementioned outcomes and
with even greater compulsion for improved education in our computer
science classrooms. Sorry again for the noise. Have an awesome weekend!
* Theorems for Free, Philip Wadler
http://homepages.inf.ed.ac.uk/wadler/papers/free/free.ps
* Haskell implementation of free theorems
http://hackage.haskell.org/package/free-theorems
* Example usage of Haskell implementation of free theorems using
lambdabot (Freenode IRC)
@free cmp :: (a -> b) -> (b -> a) -> a -> c
lambdabot> g . k = p . f => f . q = f1 . g => h . cmp k q = cmp p f1 . f
Dimitris Andreou wrote:
> 2009/11/13 Tony Morris :
>
>> Unfortunately you have subverted the types. There is no ability to print
>> a universal type. This is an unfortunate part of the Java legacy.
>>
>
> So that was the implicit assumption all along. I hope this helps
> ending this rather fruitless discussion.
>
> As I said yesterday too, Tony is not really talking about scala, as
> you can see above, about the "unfortunate part of the Java legacy". He
> talks about an abstraction that he wishes is equivalent to scala. Only
> through those glasses/assumptions some docs seem redundant. Yet, Tony
> is somehow against documenting assumptions, which is basically a
> wishful thinking that the whole scala community will just adopt the
> same set of assumptions as he, so he does not need to mention them.
>
> _In scala_, which is the context of discussion, there is a type
> hierarchy rooted at Any. For all A, A<:Any. Now, Any is proven to have
> a whole range of methods applicable to it, like like hashCode(), like
> toString(). So, for all A, one can safely call toString(). I'm sure
> someone might scream "subverting!" or "lying!" or "goosfraba!" again
> and again but that is completely irrelevant. Point is: in scala, a
> signature, even as generic as the aptly named "boo" signature, has
> *infinite* different implementations. Knock knock, this is the real
> world hitting the door. Now, we can all pretend instead that the real
> world is irrelevant, and we could rather reason only through our neat
> abstractions, but as someone said, this is kind of Platonic. But
> again, Plato was Plato for all his life, wasn't he?
>
> Dimitris
>
>
>> There is only *one possible answer*.
>>
>> Rex Kerr wrote:
>>
>>> On Thu, Nov 12, 2009 at 3:55 PM, Tony Morris >> > wrote:
>>>
>>> e.g. What would you (could you possibly) write for this function?
>>> def boo[A, B, C](f: A => B, g: B => C): A => C
>>>
>>>
>>> That one? I don't know--it's titled "boo", so it should be a
>>> surprise. Maybe it returns a function that prints out "Boo!" and
>>> returns null. Maybe it returns the BooException and never completes
>>> normally.
>>>
>>> How about this one?
>>>
>>> def printIntermediate[A,B,C](f: A => B, g: B => C): A => C
>>>
>>> Same type signature. Maybe it, I don't know, creates a function that
>>> prints out the intermediate result of type B in addition to doing the
>>> function composition?
>>>
>>> How about
>>>
>>> def nullCatch[A,B,C](f: A => B, g: B => C): A => C
>>>
>>> Same type signature again. This might possibly catch if inputs are
>>> null and throw null outputs rather than throwing exceptions, in
>>> addition to composing the functions.
>>>
>>> If you don't document your functions, how are people supposed to know
>>> whether and what side effects there are, and whether the function is
>>> value-added (as in nullCatch) or not (as in the straightforward
>>> function-composition boo that I assume you were imagining)?
>>>
>>> --Rex
>>>
>>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>
Re: Scaladoc that is actually useful?
For example,
def boo[A,B,C](f: A => B, g: B => C) : A => C = {
new (a:A) => (c:C) {
val b = f(a)
g(
b match {
case x:Int : -x
case x:Long : -x
case x:Float : -x
case x:Double: -x
case y: y
}
)
}
}
(I didn't run this, so there may be syntax errors, but you get the idea.)
This is *entirely fine* by the type system. It takes exactly what is promised, has no side effects whatsoever, and returns exactly what is promised.
Sure, there are now some subset of inputs that may have had one-to-one mappings that now are not, but that's not the type system's job to handle. (Unless, of course, you think that def square(x:Double):NonNegativeDouble is the proper type signature for the x*x operation; in that case, I'd just point out that such a type system is impractical.)
--Rex
On Thu, Nov 12, 2009 at 5:12 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: Fwd: Scaladoc that is actually useful?
No, it demonstrates that there exist functions for which there are
multiple inhabitants. You gave an example. It raises the question, how
should these ambiguity be resolved? Don't be so fast to reach for an
English description.
The signature I gave is different to yours in that (I absolutely
guarantee) there is only one inhabitant.
Brian Maso wrote:
> (Forgot to send to the list. Der.)
>
> ---------- Forwarded message ----------
> From: *Brian Maso* >
> Date: Thu, Nov 12, 2009 at 3:51 PM
> Subject: Re: [scala-user] Scaladoc that is actually useful?
> To: Randall R Schulz >
>
>
> The following two methods have the signature (Int => String) =>
> (String => Long) => Long, but return different values. Doesn't this
> case demonstrate you're not correct?
>
> def boo(a: Int => String, b: String => Long): Int => Long = {
> def ret(i: Int): Long = {
> return b(a(i));
> }
> return ret;
> }
>
> def boo2(a: Int => String, b: String => Long): Ing => Long = {
> def ret(i: Int): Long = {
> return b(a(i-1) + a(i+1))
> }
> return ret;
> }
>
> Best regards,
> Brian Maso
> (949) 395-8551
> brian [at] blumenfeld-maso [dot] com
> twitter: @bmaso
> skype: brian.maso
> LinkedIn: http://www.linkedin.com/in/brianmaso
>
>
> On Thu, Nov 12, 2009 at 3:32 PM, Randall R Schulz > wrote:
>
> On Thursday November 12 2009, Rex Kerr wrote:
> > There are infinitely many possible answers to what can happen with
> > that type signature, given that A and B can be any type.
>
> Nope. The only thing that you can do with these constraints:
>
> Given:
> a) A function from type A to type B (for any types A and B)
> b) A function from type B to type C (for any types B and C)
>
> Yielding:
> c) A function from type A to type C
>
> When the the thing doing the doing is functional (and hence is
> referentially transparent) is to compose those two functions. That is
> uniquely defined. A function—a proper mathematical function, not some
> arbitrary subroutine—say, an arity-two function—when given two
> particular values must always yield the same resulting value. And
> constraining it to be referentially transparent means that it can
> _only_ use its arguments to produce its output.
>
> Hence, the signature fully constrains the function.
>
> If I'm understanding this correctly, there is conceptually one other
> alternative, which is to return a constant function, but I'm not sure
> how to do that generically (i.e., preserving the A => C of the
> result).
> The only way to do that is to compose the input functions.
>
>
> > ...
> >
> > --Rex
>
>
> Randall Schulz
>
>
>
Re: Scaladoc that is actually useful?
On Thursday November 12 2009, Rex Kerr wrote:
> There are infinitely many possible answers to what can happen with
> that type signature, given that A and B can be any type.
Nope. The only thing that you can do with these constraints:
Given:
a) A function from type A to type B (for any types A and B)
b) A function from type B to type C (for any types B and C)
Yielding:
c) A function from type A to type C
When the the thing doing the doing is functional (and hence is
referentially transparent) is to compose those two functions. That is
uniquely defined. A function—a proper mathematical function, not some
arbitrary subroutine—say, an arity-two function—when given two
particular values must always yield the same resulting value. And
constraining it to be referentially transparent means that it can
_only_ use its arguments to produce its output.
Hence, the signature fully constrains the function.
If I'm understanding this correctly, there is conceptually one other
alternative, which is to return a constant function, but I'm not sure
how to do that generically (i.e., preserving the A => C of the result).
The only way to do that is to compose the input functions.
> ...
>
> --Rex
Randall Schulz
Re: Scaladoc that is actually useful?
You've subverted the types again. forall A B. A -> B is not a theorem.
I assure you, there is only one possible solution and I didn't just make
it up. I refer back to my lobbying for basic type theory in schools. I
predict we wouldn't be having this discussion, but a more interesting one.
Rex Kerr wrote:
> There are infinitely many possible answers to what can happen with
> that type signature, given that A and B can be any type. What if foo
> picks out certain Bs and converts them to different B's, while leaving
> everything else alone? The type system *only says that boo gives a
> function that takes A and returns C*. It doesn't say anything about
> how. There's an obvious path, and lots of non-obvious paths that
> might have practical utility.
>
> For example,
>
> def boo[A,B,C](f: A => B, g: B => C) : A => C = {
> new (a:A) => (c:C) {
> val b = f(a)
> g(
> b match {
> case x:Int : -x
> case x:Long : -x
> case x:Float : -x
> case x:Double: -x
> case y: y
> }
> )
> }
> }
>
> (I didn't run this, so there may be syntax errors, but you get the idea.)
>
> This is *entirely fine* by the type system. It takes exactly what is
> promised, has no side effects whatsoever, and returns exactly what is
> promised.
>
> Sure, there are now some subset of inputs that may have had one-to-one
> mappings that now are not, but that's not the type system's job to
> handle. (Unless, of course, you think that def
> square(x:Double):NonNegativeDouble is the proper type signature for
> the x*x operation; in that case, I'd just point out that such a type
> system is impractical.)
>
> --Rex
>
> On Thu, Nov 12, 2009 at 5:12 PM, Tony Morris > wrote:
>
> Unfortunately you have subverted the types. There is no ability to
> print
> a universal type. This is an unfortunate part of the Java legacy.
>
> There is only *one possible answer*.
>
>
Re: Scaladoc that is actually useful?
Tony Morris wrote
in news:4AFC9602 [dot] 4090200 [at] gmail [dot] com:
> You've subverted the types again. forall A B. A -> B is not a theorem.
>
> I assure you, there is only one possible solution and I didn't just
> make it up. I refer back to my lobbying for basic type theory in
> schools. I predict we wouldn't be having this discussion, but a more
> interesting one.
This is legal Scala
def boo[A, B, C](f : A=>B, g : B=>C) : A=>C = {
println("Hello")
(x : A) => (g(f(x)))
}
Thus boo can have aribtrary side effects. Those side effects (or lack
thereof) must be documented. The type signature does not describe them.
Peter
Re: Re: Scaladoc that is actually useful?
It may legal Scala but it explicitly violates what I said. I didn't say
that Scala disallows subversion of the type signature. It's amazing that
I have said this about 6 times now, yet there are people who insist on
"disagreeing" with a mathematically proven fact. It's not there to be
disagreed with, unless you have found an error in the proof.
I offer nothing but resent and disgust at any future suggestions that we
should "try to make it easier for the typical programmer." No we should
flamin' well educate them!
Peter C. Chapin wrote:
> Tony Morris wrote
> in news:4AFC9602 [dot] 4090200 [at] gmail [dot] com:
>
>
>> You've subverted the types again. forall A B. A -> B is not a theorem.
>>
>> I assure you, there is only one possible solution and I didn't just
>> make it up. I refer back to my lobbying for basic type theory in
>> schools. I predict we wouldn't be having this discussion, but a more
>> interesting one.
>>
>
> This is legal Scala
>
> def boo[A, B, C](f : A=>B, g : B=>C) : A=>C = {
> println("Hello")
> (x : A) => (g(f(x)))
> }
>
>
> Thus boo can have aribtrary side effects. Those side effects (or lack
> thereof) must be documented. The type signature does not describe them.
>
> Peter
>
>
>
>
Re: Re: Scaladoc that is actually useful?
Tony Morris-4 wrote:
>
> No we should flamin' well educate them!
>
And you believe this educational process is best done by screaming,
sneering, belittling, ignoring, and obfuscating? Cause there's sure been a
lot of all of those in this thread.
--Dave Griffith
Re: Scaladoc that is actually useful?
No there hasn't. Be honest.
Dave Griffith wrote:
>
> Tony Morris-4 wrote:
>
>> No we should flamin' well educate them!
>>
>>
>
> And you believe this educational process is best done by screaming,
> sneering, belittling, ignoring, and obfuscating? Cause there's sure been a
> lot of all of those in this thread.
>
> --Dave Griffith
>
Re: Scaladoc that is actually useful?
So you pandered to ill-education?
Re: Scaladoc that is actually useful?
On Fri, 2009-11-13 at 07:38 +1000, Tony Morris wrote:
> Actually Tony wrote the scaladoc for scala.Either.
Yes, I know that (you also wrote the implementation). I just wanted to
make it clear that your comments in that thread did not represent the
opinion of the SVN gatekeepers before another episode like:
http://james-iry.blogspot.com/2008/07/is-scala-for-academics-and-egomani...
> You'll find it is
> complete and comprehensive. I did this entirely appease people like
> Andrew. I am "giving Scala a chance" so to speak (whatever that means).
:)
Best,
Ismael
Re: Scaladoc that is actually useful?
Hi Randall,
You cannot return a constant, since you have no forall C. C to begin
with. If it were possible, then the statement that it is once-inhabited
would be false! (but of course, it is true)
Randall R Schulz wrote:
> On Thursday November 12 2009, Rex Kerr wrote:
>
>> There are infinitely many possible answers to what can happen with
>> that type signature, given that A and B can be any type.
>>
>
> Nope. The only thing that you can do with these constraints:
>
> Given:
> a) A function from type A to type B (for any types A and B)
> b) A function from type B to type C (for any types B and C)
>
> Yielding:
> c) A function from type A to type C
>
> When the the thing doing the doing is functional (and hence is
> referentially transparent) is to compose those two functions. That is
> uniquely defined. A function—a proper mathematical function, not some
> arbitrary subroutine—say, an arity-two function—when given two
> particular values must always yield the same resulting value. And
> constraining it to be referentially transparent means that it can
> _only_ use its arguments to produce its output.
>
> Hence, the signature fully constrains the function.
>
> If I'm understanding this correctly, there is conceptually one other
> alternative, which is to return a constant function, but I'm not sure
> how to do that generically (i.e., preserving the A => C of the result).
> The only way to do that is to compose the input functions.
>
>
>
>> ...
>>
>> --Rex
>>
>
>
> Randall Schulz
>
>
Fwd: Scaladoc that is actually useful?
---------- Forwarded message ----------
From: Brian Maso <brian [at] blumenfeld-maso [dot] com>
Date: Thu, Nov 12, 2009 at 3:51 PM
Subject: Re: [scala-user] Scaladoc that is actually useful?
To: Randall R Schulz <rschulz [at] sonic [dot] net>
The following two methods have the signature (Int => String) => (String => Long) => Long, but return different values. Doesn't this case demonstrate you're not correct?
def boo(a: Int => String, b: String => Long): Int => Long = {
def ret(i: Int): Long = {
return b(a(i));
}
return ret;
}
def boo2(a: Int => String, b: String => Long): Ing => Long = {
def ret(i: Int): Long = {
return b(a(i-1) + a(i+1))
}
return ret;
}
Best regards,
Brian Maso
(949) 395-8551
brian [at] blumenfeld-maso [dot] com
twitter: @bmaso
skype: brian.maso
LinkedIn: http://www.linkedin.com/in/brianmaso
On Thu, Nov 12, 2009 at 3:32 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
Re: Fwd: Scaladoc that is actually useful?
On Thursday November 12 2009, Brian Maso wrote:
> From: Brian Maso
> Date: Thu, Nov 12, 2009 at 3:51 PM
> Subject: Re: [scala-user] Scaladoc that is actually useful?
> To: Randall R Schulz
>
> The following two methods have the signature (Int => String) =>
> (String => Long) => Long, but return different values. Doesn't this
> case demonstrate you're not correct?
It does not. The type parameters A, B and C are (implicitly) universally
quantified. They range over _all_ types. So you can't just concoct
something and claim it's consistent with the signature of the function
in question.
> ...
>
> Best regards,
> Brian Maso
Randall Schulz
Re: Fwd: Scaladoc that is actually useful?
On Thu, Nov 12, 2009 at 6:54 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
Re: Fwd: Scaladoc that is actually useful?
False dichotomy.
Naftoli Gugenheim wrote:
> In any case, Tony, you seeming to be working with the mathematical
> concept of functions (which I have not studied). I don't think the
> Scaladoc is geared to students of mathematical theory, but to people
> who make a living by getting computers to perform various tasks (or do
> so as a hobby), and who feel that they can do so more productively
> with Scala, with which they are not completely familiar.
>
>
> On Thu, Nov 12, 2009 at 6:54 PM, Randall R Schulz > wrote:
>
> On Thursday November 12 2009, Brian Maso wrote:
> > From: Brian Maso >
> > Date: Thu, Nov 12, 2009 at 3:51 PM
> > Subject: Re: [scala-user] Scaladoc that is actually useful?
> > To: Randall R Schulz >
> >
> > The following two methods have the signature (Int => String) =>
> > (String => Long) => Long, but return different values. Doesn't this
> > case demonstrate you're not correct?
>
> It does not. The type parameters A, B and C are (implicitly)
> universally
> quantified. They range over _all_ types. So you can't just concoct
> something and claim it's consistent with the signature of the function
> in question.
>
>
> > ...
> >
> > Best regards,
> > Brian Maso
>
>
> Randall Schulz
>
>
Re: Fwd: Scaladoc that is actually useful?
On Thu, Nov 12, 2009 at 7:24 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: Scaladoc that is actually useful?
No, this is equivalent to solving the halting problem. I am saying we
should strive for using the types and where we cannot, there is still a
much better solution to English -- unfalsified specifications (see
ScalaCheck).
I'd give you such an example, but I'm butting heads on even a simple
one, so I dare not :)
Naftoli Gugenheim wrote:
> Tony, are you saying that the same can be said for every method in the
> Scala API, that it's self explanatory?
>
> On Thu, Nov 12, 2009 at 6:24 PM, Tony Morris > wrote:
>
> Rex,
> I can read your code just fine. I assure you, the signature given is
> once-inhabited. There is even a proof of this fact. It's a well
> understood basic fact of computational theory.
>
> So, the question arises, where are you wrong? The theorem: forall
> A B. A
> -> B is also known as "the cast operator." Under the Curry-Howard
> Isomorphism, functions are implication -- that is why we denote them
> with -> symbol.
>
> Let's draw the truth table for implication:
> P Q P->Q
> 0 0 1
> 0 1 1
> 1 0 0
> 1 1 1
>
> So we have a premise and a conclusion in one. We see immediately that
> this is not tautological. Therefore, forall A B. A -> B is not a
> theorem. If you'll allow me an indulgence in quoting Erik Meijer at a
> conference in front about ~400 typical programmers, "It is a LIE!"
>
> Scala's type systems has many "let's escape reality and tell
> lies." One
> of them is side-effects, another is casting. Haskell, which also does
> same, calls the former unsafePerformIO and the latter
> unsafeCoerce. The
> "unsafe" prefix is intended to denote "Caution, these functions
> tell lies."
>
> The question can be phrased in English as "tell the truth about this
> signature." This means no lies, no subverting the types. No def
> cast[A,
> B](a: A): B functions allowed. To the extent that you use them is the
> extent that you are telling lies (and so we must not get *all* our
> documentation from types, but we should strive for it as a virtue).
>
> I really hope this helps. This is exhausting.
>
>
> Rex Kerr wrote:
> > Tony,
> >
> > I'm not convinced you're paying attention to my code, and if you
> are,
> > I'm not convinced you're proposing anything sensible.
> >
> > Please explain exactly where the subversion occurs, and please say
> > exactly what the return type should be for the Double square
> > function. If the return type for the Double function is not Double,
> > please explain what the return type is for the F(n) function which
> > computes the n'th Fibonacci number.
> >
> > Or you can come up with some alternate scheme that will demonstrate
> > that you are actually understanding what I am saying and disagreeing
> > on the basis of solid principles.
> >
> > (Or, of course, we can just drop it.)
> >
> > --Rex
> >
> > On Thu, Nov 12, 2009 at 6:10 PM, Tony Morris
>
> > >> wrote:
> >
> > You've subverted the types again. forall A B. A -> B is not
> a theorem.
> >
> > I assure you, there is only one possible solution and I didn't
> > just make
> > it up. I refer back to my lobbying for basic type theory in
> schools. I
> > predict we wouldn't be having this discussion, but a more
> > interesting one.
> >
> > Rex Kerr wrote:
> > > There are infinitely many possible answers to what can
> happen with
> > > that type signature, given that A and B can be any type. What
> > if foo
> > > picks out certain Bs and converts them to different B's, while
> > leaving
> > > everything else alone? The type system *only says that
> boo gives a
> > > function that takes A and returns C*. It doesn't say
> anything about
> > > how. There's an obvious path, and lots of non-obvious
> paths that
> > > might have practical utility.
> > >
> > > For example,
> > >
> > > def boo[A,B,C](f: A => B, g: B => C) : A => C = {
> > > new (a:A) => (c:C) {
> > > val b = f(a)
> > > g(
> > > b match {
> > > case x:Int : -x
> > > case x:Long : -x
> > > case x:Float : -x
> > > case x:Double: -x
> > > case y: y
> > > }
> > > )
> > > }
> > > }
> > >
> > > (I didn't run this, so there may be syntax errors, but you get
> > the idea.)
> > >
> > > This is *entirely fine* by the type system. It takes exactly
> > what is
> > > promised, has no side effects whatsoever, and returns exactly
> > what is
> > > promised.
> > >
> > > Sure, there are now some subset of inputs that may have had
> > one-to-one
> > > mappings that now are not, but that's not the type
> system's job to
> > > handle. (Unless, of course, you think that def
> > > square(x:Double):NonNegativeDouble is the proper type
> signature for
> > > the x*x operation; in that case, I'd just point out that
> such a type
> > > system is impractical.)
> > >
> > > --Rex
> > >
> > > On Thu, Nov 12, 2009 at 5:12 PM, Tony Morris
> >
> >
> > >
> >>> wrote:
> > >
> > > Unfortunately you have subverted the types. There is no
> > ability to
> > > print
> > > a universal type. This is an unfortunate part of the Java
> > legacy.
> > >
> > > There is only *one possible answer*.
> > >
> > >
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
RE: Scaladoc that is actually useful?
>
> I assure you, there is only one possible solution and I didn't just make
> it up. I refer back to my lobbying for basic type theory in schools.
What about those people who didn't do CS in school? And if the school can explain stuff to people, why can't the documentation? Honestly, your opinion is one of the most ridiculous things I've heard in a long while: documentation for stuff like APIs is critical, at least *if you want to end up with users.*
Spring or PicoContainer? Spring won because the documentation was superb. Hibernate? The same. Why don't you put yourself in the position of someone who's working to a tight deadline and is trying to understand something unfamiliar. Documentation should be examples, examples and more examples.
Use Hotmail to send and receive mail from your different email accounts. Find out how.
Re: Scaladoc that is actually useful?
That's the point, they did do CS in school and they still don't
understand some of the basic tenets of computational theory. I find this
lamentable and I am sympathetic toward them for having been robbed by a
self-proclaimed educational institution. I stand firm in my position for
education on this matter, instead of subjects like "Java" or "Web
Programming" as if that is even a subject! It does a disservice to
students, the definition of the term "subject" and results in the
problems that I am observing right now.
I'm not in the business of appeasing ill-education. Documentation for
stuff like APIs is certainly not critical, nor required to have users.
christopher marshall wrote:
> > You've subverted the types again. forall A B. A -> B is not a theorem.
> >
> > I assure you, there is only one possible solution and I didn't just make
> > it up. I refer back to my lobbying for basic type theory in schools.
>
> What about those people who didn't do CS in school? And if the school
> can explain stuff to people, why can't the documentation? Honestly,
> your opinion is one of the most ridiculous things I've heard in a long
> while: documentation for stuff like APIs is critical, at least *if you
> want to end up with users.*
>
> Spring or PicoContainer? Spring won because the documentation was
> superb. Hibernate? The same. Why don't you put yourself in the
> position of someone who's working to a tight deadline and is trying to
> understand something unfamiliar. Documentation should be examples,
> examples and more examples.
>
> ------------------------------------------------------------------------
> Use Hotmail to send and receive mail from your different email
> accounts. Find out how.
Re: Scaladoc that is actually useful?
Yes I do it regularly. This does not mean it is virtuous.
Nils Kilden-Pedersen wrote:
> On Thu, Nov 12, 2009 at 3:38 PM, Tony Morris > wrote:
>
> Actually Tony wrote the scaladoc for scala.Either. You'll find it is
> complete and comprehensive.
>
>
> So you pandered to ill-education?
Re: Scaladoc that is actually useful?
I deliberately left out what I hoped was obvious.
* Side-effects subvert the types. This is invalid. That it is valid in
Scala, does not make it valid in reality. You are not able to compute on
arguments that are not there.
* Assume termination (or solve the halting problem!)
Dave Griffith wrote:
>
> Tony Morris-4 wrote:
>
>> e.g. What would you (could you possibly) write for this function?
>> def boo[A, B, C](f: A => B, g: B => C): A => C
>>
>> Not even tests.
>>
>>
>
> def boo[A, B, C](f: A => B, g: B => C): A => C = {
>
> reformatHardDrive();
>
> emptyBankAccount();
>
> error("gotcha")
> }
>
> Not sure I agree 100% with your QA work there.
>
> --Dave Griffith
>
Re: Scaladoc that is actually useful?
Um, what exactly do you think the correlation is between type theory and
"reality"? That's a
whole lotta philosophy you're just glossing over, and that's without
bringing pragmatics
into it.
Tony Morris-4 wrote:
>
> That it is valid in Scala, does not make it valid in reality.
>
--Dave Griffith