- 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?
Actually Tony wrote the scaladoc for scala.Either. 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).
Ismael Juma wrote:
> On Thu, 2009-11-12 at 18:26 -0300, andrew cooke wrote:
>
>> look, take haskell. go educate people with that. let scala have a
>> chance to be successful.
>>
>
> You realise that Tony doesn't influence what goes into the scaladoc for
> the standard library, right?
>
> As far as I know, Martin and others are not against fleshing out the
> scaladoc, they just haven't had the time and no-one else has done it
> either.
>
> Best,
> Ismael
>
>
>
Re: Scaladoc that is actually useful?
Quite a lot, but that's beside the point. A side-effecting function
accepts the world and returns a pair containing the world.
Do you know what function means?
Dave Griffith wrote:
> 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
>
>
Re: Scaladoc that is actually useful?
Tony Morris-4 wrote:
>
> Do you know what function means?
>
In type theory? In intuitionistic (a.k.a constructive) type theory? In
recursive function theory? In Haskell? In Scala? In C?
Yes, I know what 'function' means, in all of the above. Even though the
definitions there have almost as many differences as similarities.
In "reality"? Oh, hell no! I certainly don't know what a function is in
"reality", but based on the disagreement on this point among philosophers of
mathematics I'm pretty sure I'm not alone. The one thing I am sure of is
that it's not the sort of naive Platonism you seem to be espousing. If I
take a rock and sift it down to constituent quarks I'm pretty certain I
won't see any functions.
How exactly is this helpful to someone who is trying to get some work done
and complaining that someone else didn't write good doc?
--Dave Griffith
Re: Scaladoc that is actually useful?
So er, back to reality.
Can you provide two inhabitants for:
forall A B C. (A => B) => (B => C) => A => C
Assume termination and no lies.
(Hint: the answer begins with 'n' and ends with 'o').
Dave Griffith wrote:
>
>
> Tony Morris-4 wrote:
>
>> Do you know what function means?
>>
>>
>
> In type theory? In intuitionistic (a.k.a constructive) type theory? In
> recursive function theory? In Haskell? In Scala? In C?
>
> Yes, I know what 'function' means, in all of the above. Even though the
> definitions there have almost as many differences as similarities.
>
> In "reality"? Oh, hell no! I certainly don't know what a function is in
> "reality", but based on the disagreement on this point among philosophers of
> mathematics I'm pretty sure I'm not alone. The one thing I am sure of is
> that it's not the sort of naive Platonism you seem to be espousing. If I
> take a rock and sift it down to constituent quarks I'm pretty certain I
> won't see any functions.
>
> How exactly is this helpful to someone who is trying to get some work done
> and complaining that someone else didn't write good doc?
>
> --Dave Griffith
>
>
Re: Scaladoc that is actually useful?
// keeping it simple
return f2(f1(a));
// bwahahaha
val x = true;
return if(x) { f2(f1(a)) } else { null }
or some other such nonsense reducible to the simple implementation a by sequence of refactorings.
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 7:22 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: Scaladoc that is actually useful?
No, null represents a logical absurdity (non-termination). I think you
mean the body of the function may look syntactically different. This may
well be.
Brian Maso wrote:
> I think you meant two different inhabitants that are not reducible to
> each other, don't you? I mean, the following are equivalent, but
> different "functions" (your meaning) of the signature "def func[A, B,
> C](f1: A => B, f2: B => C): A => C"
>
> // keeping it simple
> return f2(f1(a));
>
> // bwahahaha
> val x = true;
> return if(x) { f2(f1(a)) } else { null }
>
> or some other such nonsense reducible to the simple implementation a
> by sequence of refactorings.
>
> 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 7:22 PM, Tony Morris > wrote:
>
> So er, back to reality.
>
> Can you provide two inhabitants for:
> forall A B C. (A => B) => (B => C) => A => C
>
> Assume termination and no lies.
>
> (Hint: the answer begins with 'n' and ends with 'o').
>
> Dave Griffith wrote:
> >
> >
> > Tony Morris-4 wrote:
> >
> >> Do you know what function means?
> >>
> >>
> >
> > In type theory? In intuitionistic (a.k.a constructive) type
> theory? In
> > recursive function theory? In Haskell? In Scala? In C?
> >
> > Yes, I know what 'function' means, in all of the above. Even
> though the
> > definitions there have almost as many differences as similarities.
> >
> > In "reality"? Oh, hell no! I certainly don't know what a
> function is in
> > "reality", but based on the disagreement on this point among
> philosophers of
> > mathematics I'm pretty sure I'm not alone. The one thing I am
> sure of is
> > that it's not the sort of naive Platonism you seem to be
> espousing. If I
> > take a rock and sift it down to constituent quarks I'm pretty
> certain I
> > won't see any functions.
> >
> > How exactly is this helpful to someone who is trying to get some
> work done
> > and complaining that someone else didn't write good doc?
> >
> > --Dave Griffith
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
Re: Scaladoc that is actually useful?
Earlier today I agreed with the original poster that there is a
problem with Scaladoc, in that it makes seemingly simple tasks
excessively complex for the programmer who has to get work done. That
discussion went off on some odd tangent about type systems that I will
ignore.
Back to the original complaint...suppose I want to use an ArrayBuffer
in 2.8. The scaladoc sends me to
ResizableArray
Builder
IndexedSeqLike
IndexedSeqLike (again, but this time not mutable)
BufferLike
Shrinkable
Growable
SeqLike
PartialFunction
Function1
iterableLike
GenericTraversableTemplate
TraversableLike
AnyRef
Any
Ok, maybe it's the Scala way to pick up lots of fragmentary traits.
But then the Scaladoc could have a friendlier way of helping the new
user, such as inline expanding the docs for the traits, or at least,
copying out the summary method statements.
This really needs some fresh thinking without detours into "my mother
knows more type theory than your mother".
Re: Scaladoc that is actually useful?
On Fri, Nov 13, 2009 at 2:36 AM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com> wrote:
--
Daniel C. Sobral
Veni, vidi, veterni.
Re: Scaladoc that is actually useful?
On Fri, Nov 13, 2009 at 3:04 PM, Daniel Sobral wrote:
> As a side note, I'd love if ScalaDoc provided a search function. I open up a
> class, type up a method name on the search field, and it either shows me the
> method definition (in another trait/class, if needed), or tells me it isn't
> defined for that class.
Very helpful: http://www.teria.com/~koseki/tools/gm/javadoc_isearch/index.html
Re: Scaladoc that is actually useful?
Whilst discussing Scaladoc...
What I'd love is a way too see what methods are in scope via
self-typing, and where they originate.
On Fri, Nov 13, 2009 at 2:04 PM, Daniel Sobral wrote:
> As a side note, I'd love if ScalaDoc provided a search function. I open up a
> class, type up a method name on the search field, and it either shows me the
> method definition (in another trait/class, if needed), or tells me it isn't
> defined for that class.
>
> On Fri, Nov 13, 2009 at 2:36 AM, Cay Horstmann
> wrote:
>>
>> Earlier today I agreed with the original poster that there is a
>> problem with Scaladoc, in that it makes seemingly simple tasks
>> excessively complex for the programmer who has to get work done. That
>> discussion went off on some odd tangent about type systems that I will
>> ignore.
>>
>> Back to the original complaint...suppose I want to use an ArrayBuffer
>> in 2.8. The scaladoc sends me to
>>
>> ResizableArray
>> Builder
>> IndexedSeqLike
>> IndexedSeqLike (again, but this time not mutable)
>> BufferLike
>> Shrinkable
>> Growable
>> SeqLike
>> PartialFunction
>> Function1
>> iterableLike
>> GenericTraversableTemplate
>> TraversableLike
>> AnyRef
>> Any
>>
>> Ok, maybe it's the Scala way to pick up lots of fragmentary traits.
>> But then the Scaladoc could have a friendlier way of helping the new
>> user, such as inline expanding the docs for the traits, or at least,
>> copying out the summary method statements.
>>
>> This really needs some fresh thinking without detours into "my mother
>> knows more type theory than your mother".
>
>
>
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.
>
Re: Scaladoc that is actually useful?
Builder
IndexedSeqLike
IndexedSeqLike (again, but this time not mutable)
BufferLike
Shrinkable
Growable
This is a huge decrease in the number of methods I have to look up. Furthermore, I know a lot of methods I'm used to are present as well. The alternative, of course, is not having most of these methods and having to reinvent the wheel each time I need something like them.
On Fri, Nov 13, 2009 at 2:36 AM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com> wrote:
--
Daniel C. Sobral
Veni, vidi, veterni.
Re: Scaladoc that is actually useful?
I understand the value of having the traits, but that doesn't mean
they need to be the only navigation path. I'd like the option of an
alpha listing of all methods. I'd like the option of a listing by
trait, with a comment next to the method, to help me decide whether it
is worth drilling down. Maybe the trait docs could be inline expanded
rather than replacing the current page.
Javadoc worked fine for Java--single inheritance, a few small
interfaces here and there. For Scala, let's think out of the box and
come up with a doc system that plays to the strengths of Scala.
Cheers,
Cay
On Fri, Nov 13, 2009 at 5:54 AM, Daniel Sobral wrote:
> It seems I only reply to you on this thread. :-)
>
> Ok, without dismissing the problems with Scala API docs, which I do think it
> is an important topic, I think the problem here is not quite what you
> perceive it to be.
>
> Java has relatively small (poor) interfaces, because the language makes it
> hard to have rich interfaces. Scala, on the other hand, enables very rich
> interfaces with a low implementation cost.
>
> So, I ask you to consider this... how would you feel if all the methods for
> all these traits were simply listed one after the other, with their type
> signatures and descriptions? I don't know about you, but I'd feel tired just
> by looking at it, before even trying to read it.
>
> When the class makes such extensive use of traits, however, I make use of
> previous knowledge. It won't help absolute beginners at first, but, at
> least, you get to reuse the knowledge you have previously acquired.
>
> For instance, I have a fair knowledge of what I can do with an Iterable, so,
> knowing this class is IterableLike and TraversableLike already tells me a
> lot of things, without having to look up anything else. The same goes for
> PartialFunction and Function1.
>
> And that means that, very much contrary to what you have stated, I *only*
> have to concentrate on:
>
> ResizableArray
> Builder
> IndexedSeqLike
> IndexedSeqLike (again, but this time not mutable)
> BufferLike
> Shrinkable
> Growable
> This is a huge decrease in the number of methods I have to look up.
> Furthermore, I know a lot of methods I'm used to are present as well.
>
> The alternative, of course, is not having most of these methods and having
> to reinvent the wheel each time I need something like them.
> On Fri, Nov 13, 2009 at 2:36 AM, Cay Horstmann
> wrote:
>>
>> Earlier today I agreed with the original poster that there is a
>> problem with Scaladoc, in that it makes seemingly simple tasks
>> excessively complex for the programmer who has to get work done. That
>> discussion went off on some odd tangent about type systems that I will
>> ignore.
>>
>> Back to the original complaint...suppose I want to use an ArrayBuffer
>> in 2.8. The scaladoc sends me to
>>
>> ResizableArray
>> Builder
>> IndexedSeqLike
>> IndexedSeqLike (again, but this time not mutable)
>> BufferLike
>> Shrinkable
>> Growable
>> SeqLike
>> PartialFunction
>> Function1
>> iterableLike
>> GenericTraversableTemplate
>> TraversableLike
>> AnyRef
>> Any
>>
>> Ok, maybe it's the Scala way to pick up lots of fragmentary traits.
>> But then the Scaladoc could have a friendlier way of helping the new
>> user, such as inline expanding the docs for the traits, or at least,
>> copying out the summary method statements.
>>
>> This really needs some fresh thinking without detours into "my mother
>> knows more type theory than your mother".
>
>
>
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.
>
Re: Scaladoc that is actually useful?
I also think when you start placing implicits into the mix, you need new ways of documenting things. Example usage becomes *very* important, especially when every example would show: import foo.myawesomedsl._ or class SomeClass extends MyAwesomeDSLTrait
When I first went to learn a few of these DSL-y libraries via scaladoc, it becomes interesting trying to hold all the classes in your head while you drill around looking for methods and types that do nothing but provide handy operators.
- Josh
On Thu, Nov 12, 2009 at 11:36 PM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com> wrote:
Re: Scaladoc that is actually useful?
Note though that DSLy things are not bad just in scaladocs - in
javadocs they are a nightmare too.
For example, here is a basic acknowledgement of the fact, in google
guice javadocs:
http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/B...
"Guice uses an embedded domain-specific language, or EDSL, to help you
create bindings simply and readably. This approach is great for
overall usability, but it does come with a small cost: it is difficult
to learn how to use the Binding EDSL by reading method-level javadocs.
"
I think we do need better ways. The various combinations that small
functions can create to yield interesting behavior is lost by just
looking only one by one, in some order, the function definitions
themselves. A graph notation of an api should be promising, but how
would one create an understandable graph of higher-order functions? A
good answer to the latter would immediately open the prospect of a
very interesting project.
Dimitris
2009/11/13 Josh Suereth :
> I agree 100%!
>
> I also think when you start placing implicits into the mix, you need new
> ways of documenting things. Example usage becomes *very* important,
> especially when every example would show: import foo.myawesomedsl._ or
> class SomeClass extends MyAwesomeDSLTrait
>
> When I first went to learn a few of these DSL-y libraries via scaladoc, it
> becomes interesting trying to hold all the classes in your head while you
> drill around looking for methods and types that do nothing but provide handy
> operators.
>
> - Josh
>
> On Thu, Nov 12, 2009 at 11:36 PM, Cay Horstmann
> wrote:
>>
>> Earlier today I agreed with the original poster that there is a
>> problem with Scaladoc, in that it makes seemingly simple tasks
>> excessively complex for the programmer who has to get work done. That
>> discussion went off on some odd tangent about type systems that I will
>> ignore.
>>
>> Back to the original complaint...suppose I want to use an ArrayBuffer
>> in 2.8. The scaladoc sends me to
>>
>> ResizableArray
>> Builder
>> IndexedSeqLike
>> IndexedSeqLike (again, but this time not mutable)
>> BufferLike
>> Shrinkable
>> Growable
>> SeqLike
>> PartialFunction
>> Function1
>> iterableLike
>> GenericTraversableTemplate
>> TraversableLike
>> AnyRef
>> Any
>>
>> Ok, maybe it's the Scala way to pick up lots of fragmentary traits.
>> But then the Scaladoc could have a friendlier way of helping the new
>> user, such as inline expanding the docs for the traits, or at least,
>> copying out the summary method statements.
>>
>> This really needs some fresh thinking without detours into "my mother
>> knows more type theory than your mother".
>
>
RE: Scaladoc that is actually useful?
/** Return true iff the given predicate `p` yields true for all elements
* of this traversable.
*
* @note May not terminate for infinite-sized collections.
* @param p the predicate
*/
Speaking from the perspective of someone who has been bitten *in the real world* by ambiguous or incomplete documentation (String.substring anyone?), extensive documentation of both what the function does and how it does it (or what it may leave undefined) is critical in the long run, although it's understandable that it is something left to last (it's neither a glamorous or interesting thing to do).
I'll say it again: comprehensive documentation creates wider adoption - it's as simple as that.
I am happy to offer my own time to help document scala - how should I go about it?
Use Hotmail to send and receive mail from your different email accounts. Find out how.
Re: Scaladoc that is actually useful?
On Friday November 13 2009, christopher marshall wrote:
> Note that things like the scaladoc for things like the forall
> function is *ambiguous*:
>
> /** Return true iff the given predicate `p` yields true for all
> elements * of this traversable.
> *
> * @note May not terminate for infinite-sized collections.
> * @param p the predicate
> */
>
> Does this return true for an empty collection? (I don't think the
> "average" developer is likely to definitively know the answer to this
> as it's a subtle point of logic.)
It can be rephrased to remove the ambiguity:
"Forall returns false if at least one application of the predicate
returns false."
"Exists returns true if at least one application of the predicate
returns true."
> ...
>
> Speaking from the perspective of someone who has been bitten *in the
> real world* by ambiguous or incomplete documentation
Getting bitten in virtual worlds wouldn't really count, anyway.
And we've all had this experience.
> ...
Randall Schulz
RE: Scaladoc that is actually useful?
>
> "Forall returns false if at least one application of the predicate
> returns false."
This is still ambiguous as you've used if instead of iff (which, again, the "average" developer may not be familiar with)! And you still haven't told me whether the implementation will continue to evaluate the predicate after the result of the function is effectively decided (although the original doc about infinite collections gives a hint as to whether this is the case).
Use Hotmail to send and receive mail from your different email accounts. Find out how.
Re: Scaladoc that is actually useful?
I was. If you really don't want to you how your behaviour in this thread
has been perceived, that's your prerogative, of course.
--Dave Griffith
Tony Morris-4 wrote:
>
> 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?
Email me in private and let me know.
As far as I see, I have certainly not been "sneering" unless that is
synonymous with "repeating yourself in a different manner for those who
have failed to comprehend." I have not "belittled" anyone, though I have
pointed out that we are dealing with a provable and proven fact. It's
also falsifiable -- simply provide a counter-example; observe how this
has not occurred (despite failed attempts). Ignoring! Haha! I think
you're on your own in believing that one -- 150-email thread and I have
been "ignoring." Uh huh. Obfuscating? I stated a very simple exercise in
a very small paragraph. It truly doesn't get any easier.
So Dave, if you think this is all or partly untrue, email me in private.
I'm keen to hear where you think I am wrong. Be honest and don't make
shit up.
Dave Griffith wrote:
> I was. If you really don't want to you how your behaviour in this thread
> has been perceived, that's your prerogative, of course.
>
> --Dave Griffith
>
>
> Tony Morris-4 wrote:
>
>> 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?
I thought about this for a bit, and honestly have neither the time nor the
energy to do so.
You can claim internet victory because of that if you wish, and I'd bet good
money that you will. Alternatively, you could read back through the rather
thuggishly hijacked thread and try
to imagine how you must sound to others. In particular, how you must sound
others
who don't share your priors about what the appropriate domain of
discourse of a Scala
mailing list should be. For extra points, imagine it from the point of
view of someone
outside the community, trying to decide whether to use Scala or not. How
effective do you
really think you've been at "educating" them?
--Dave Griffith
Re: Scaladoc that is actually useful?
Your motives are exposed. There is no "internet victory." I stated my
motives up front. I wish to educate. I succeeded. I have personal
testimonies to that effect. I even have people that got off first base
and explored interesting questions down the path! Yes this excites me,
"internet victory" (whatever that means) doesn't. I'll hand that over to
you for whatever purpose it serves.
I'll read back through it some day, but it is rather uninteresting.
Consider my possible motivations for reading myself repeating a well
established fact, to appease what I can only consider is a lack of
comprehension. There is nothing for me to gain here, neither to learn
nor for teaching.
You are right that the thread may have turned people off. I know 2
people who have thought, to paraphrase, "how can programmers be that
stupid!?" I discourage that type of discourse and I think it is unfair,
but they think it nonetheless. I'm sure it affected their prejudices of
using Scala. I also think it is unfair that while stating highly
relevant, proven, educational facts may or may not be contrary to
"appeasing the point of view of someone outside the community" (is it
really?), then there should be any apprehension of doing exactly that.
Do you find it offensive that there are people who learned by thinking
about it?
Dave Griffith wrote:
> I thought about this for a bit, and honestly have neither the time nor the
> energy to do so.
> You can claim internet victory because of that if you wish, and I'd bet good
> money that you will. Alternatively, you could read back through the rather
> thuggishly hijacked thread and try
> to imagine how you must sound to others. In particular, how you must sound
> others
> who don't share your priors about what the appropriate domain of
> discourse of a Scala
> mailing list should be. For extra points, imagine it from the point of
> view of someone
> outside the community, trying to decide whether to use Scala or not. How
> effective do you
> really think you've been at "educating" them?
>
> --Dave Griffith
>
>
>
Re: Scaladoc that is actually useful?
Sorry Dave and list, I meant to reply off list. If you could that I Dave
I'd appreciate it.
Tony Morris wrote:
> Your motives are exposed. There is no "internet victory." I stated my
> motives up front. I wish to educate. I succeeded. I have personal
> testimonies to that effect. I even have people that got off first base
> and explored interesting questions down the path! Yes this excites me,
> "internet victory" (whatever that means) doesn't. I'll hand that over to
> you for whatever purpose it serves.
>
> I'll read back through it some day, but it is rather uninteresting.
> Consider my possible motivations for reading myself repeating a well
> established fact, to appease what I can only consider is a lack of
> comprehension. There is nothing for me to gain here, neither to learn
> nor for teaching.
>
> You are right that the thread may have turned people off. I know 2
> people who have thought, to paraphrase, "how can programmers be that
> stupid!?" I discourage that type of discourse and I think it is unfair,
> but they think it nonetheless. I'm sure it affected their prejudices of
> using Scala. I also think it is unfair that while stating highly
> relevant, proven, educational facts may or may not be contrary to
> "appeasing the point of view of someone outside the community" (is it
> really?), then there should be any apprehension of doing exactly that.
>
> Do you find it offensive that there are people who learned by thinking
> about it?
>
> Dave Griffith wrote:
>
>> I thought about this for a bit, and honestly have neither the time nor the
>> energy to do so.
>> You can claim internet victory because of that if you wish, and I'd bet good
>> money that you will. Alternatively, you could read back through the rather
>> thuggishly hijacked thread and try
>> to imagine how you must sound to others. In particular, how you must sound
>> others
>> who don't share your priors about what the appropriate domain of
>> discourse of a Scala
>> mailing list should be. For extra points, imagine it from the point of
>> view of someone
>> outside the community, trying to decide whether to use Scala or not. How
>> effective do you
>> really think you've been at "educating" them?
>>
>> --Dave Griffith
>>
>>
>>
>>
>
>
Re: Scaladoc that is actually useful?
One might not appreciate the tone of Tony in this series of e-mails, but he's kept it balanced throughout his correspondence.
On Sun, Nov 15, 2009 at 10:24 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall
Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang
Re: Scaladoc that is actually useful?
I think Tony has kept it civil and provided genuine insight.
On Sun, Nov 15, 2009 at 5:47 PM, Viktor Klang <viktor [dot] klang [at] gmail [dot] com> wrote:
--
http://erikengbrecht.blogspot.com/
Re: Scaladoc that is actually useful?
After you've heard the ex-chief of a very large software company located in the pacific northwest use the word f#@&%k in every part of speech Tony's tone at it's worst is meek and mild-mannered. i have never been offended by his tone and appreciate his willingness to share his perspective. However, his point is false. i have demonstrated this repeatedly.
There are countably infinitely many inhabitants of the type (A => B) => (B => C) => A => C. They are observably distinguished by running time and space consumption. Here is one infinite subset of that set: for each k in the natural numbers we have
Compose_k( f, g ) = { ( x ) => { var d = computeKthDigitOfPi( k ); g( f( x ) ) } : (A => B) => (B => C) => A => C
There are lots more infinite subsets where that one came from. The differences in complexity are not just manifest by silliness of the kind above. There are materially relevant differences that have to do with the internal representation of function and evaluation.
Beyond that, consider the following function
// provided A, B, C <: T with T supporting a certain algebraic structure
Convolution_tau( f, g ) = { ( t ) => { integrate( f( t ) * g( tau - t ), posInf, negInf ) } } : (A => B) => (B => C) => A => C
For the subset of types supporting a certain algebraic structure -- i.e. we restrict the universe of quantification in the original theorem
Re: Scaladoc that is actually useful?
On Mon, Nov 16, 2009 at 5:59 PM, Meredith Gregory
wrote:
> Compose_k( f, g ) = { ( x ) => { var d = computeKthDigitOfPi( k ); g( f( x )
> ) } : (A => B) => (B => C) => A => C
I'm not sure if that's a particular good example, because it computes
d just for the explicit side-effect which (as Tony would say) belongs
very clearly into the subversive type-lies milieu. You are, of course,
right about the implicit side-effects of time and space.
Re: Scaladoc that is actually useful?
Victor,
Haven typed all this below, I am concerned that you might feel attacked by me since I started this in respond to you. This is not my intent. But in order not to type this once more, I leave it as it is, but want to emphasize that I respond to you, just because the sentence below made me start to type in the first place.
2009/11/15 Viktor Klang <viktor [dot] klang [at] gmail [dot] com>
I cannot really agree to this. When I try do describe why I must recap the approximate course of this thread.
- Occasional attempts of posters to come back to the topic of improving the API-documentation where washed away by the "traffic" on function types.
If I analyze this, I see that this is based on a double hijack and a well know rhetoric technique, namely hide your premises and thus make people accept them unknowingly.- The remaining plot was based of the unspoken premises of Mr. Morris and what a programmer should do and not do. The explanations where centered about the term "subvert". That translates to: what is admissible and what proves you to be uneducated and.
I consider this as the opposite of a decent discussion culture. I know that there is always the temptation to go off-topic, and there is no obligation to post with a pair of gold scales at hand, but one should preferably strive for a sense of good taste.All the arguments are heavily geared to the fact that scala allows object oriented programming, even encourages it. Well yes. I thought this was the language designers' original intent, namely to develop a language which scales across many styles and levels of programming. Is this a legacy to feel bad about?
And as far as "tone" is concerned: Tone is important, "the tone makes the music" (This is a german proverb and my grandmothers used it to true me). In the tone presented here I recognize a practice of making people feel insulted without actually insulting them. That is an art.
Finally, In order not to conclude with a negative statement, I go once more off-topic:
Recently I learned good arguments against programming with state and object oriented program design and, nameley a video by Rich Hickey (I lost the URI, the aruments are to be found on [www.clojure.org], e.g. his notion of indentity) and Tryggve Reenskaug on the DCI_Architcture [http://www.artima.com/articles/dci_vision.html]. Both critiques run on totally different tracks. I did feel educated.
Sincerely Yours
Burkhard.
RE: Scaladoc that is actually useful?
"I think you should seriously consider your position, since your apathy and indirect advocacy for poor education is part of the problem, not the solution"
I'm sorry, but I happen to find this sort of language and approach unwarranted, unnecessary and does not belong on a professional mailing list. It has all the hallmarks of a troll: i.e. it falls short of direct personal abuse but can largely be read/interpreted as such.
I think it was this initial attitude that largely set the combative and confrontational tone for the rest of the discussion.
Chris
Date: Sun, 15 Nov 2009 23:47:19 +0100
Subject: Re: [scala-user] Scaladoc that is actually useful?
From: viktor [dot] klang [at] gmail [dot] com
To: tonymorris [at] gmail [dot] com
CC: dave [dot] l [dot] griffith [at] gmail [dot] com; scala-user [at] listes [dot] epfl [dot] ch
It a rare occurrence, but I have to say that I'm with Tony on this one.
One might not appreciate the tone of Tony in this series of e-mails, but he's kept it balanced throughout his correspondence.
On Sun, Nov 15, 2009 at 10:24 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall
Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang
New! Receive and respond to mail from other email accounts from within Hotmail Find out how.
Re: Scaladoc that is actually useful?
It's certainly not a friendly statement, but professionalism is not the same as being friendly.
On Mon, Nov 16, 2009 at 3:48 AM, christopher marshall <oxbow_lakes [at] hotmail [dot] com> wrote:
--
http://erikengbrecht.blogspot.com/
Re: Scaladoc that is actually useful?
I think you represent the very-large-majority position. But please, don't poke the dogmatic bears -- they are apparently hibernating in this thread. Its best to let them lie; you won't convince them to change their position!
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 Mon, Nov 16, 2009 at 12:48 AM, christopher marshall <oxbow_lakes [at] hotmail [dot] com> wrote:
Re: Scaladoc that is actually useful?
It's actually a parody of precisely what you wrote after you denied a fact.
christopher marshall wrote:
> This is what Tony said to the *first* person who said that he
> disagreed that Tony's boo function should be commented as it would not
> be clear to all (which he had written quite "passively"):
>
> "I think you should seriously consider your position, since your
> apathy and indirect advocacy for poor education is part of the
> problem, not the solution"
>
> I'm sorry, but I happen to find this sort of language and approach
> unwarranted, unnecessary and does not belong on a professional mailing
> list. It has all the hallmarks of a troll: i.e. it falls short of
> direct personal abuse but can largely be read/interpreted as such.
>
> I think it was this initial attitude that largely set the combative
> and confrontational tone for the rest of the discussion.
>
> Chris
>
> ------------------------------------------------------------------------
> Date: Sun, 15 Nov 2009 23:47:19 +0100
> Subject: Re: [scala-user] Scaladoc that is actually useful?
> From: viktor [dot] klang [at] gmail [dot] com
> To: tonymorris [at] gmail [dot] com
> CC: dave [dot] l [dot] griffith [at] gmail [dot] com; scala-user [at] listes [dot] epfl [dot] ch
>
> It a rare occurrence, but I have to say that I'm with Tony on this one.
>
> One might not appreciate the tone of Tony in this series of e-mails,
> but he's kept it balanced throughout his correspondence.
>
> On Sun, Nov 15, 2009 at 10:24 PM, Tony Morris > wrote:
>
> Sorry Dave and list, I meant to reply off list. If you could that
> I Dave
> I'd appreciate it.
>
> Tony Morris wrote:
> > Your motives are exposed. There is no "internet victory." I
> stated my
> > motives up front. I wish to educate. I succeeded. I have personal
> > testimonies to that effect. I even have people that got off
> first base
> > and explored interesting questions down the path! Yes this
> excites me,
> > "internet victory" (whatever that means) doesn't. I'll hand that
> over to
> > you for whatever purpose it serves.
> >
> > I'll read back through it some day, but it is rather uninteresting.
> > Consider my possible motivations for reading myself repeating a well
> > established fact, to appease what I can only consider is a lack of
> > comprehension. There is nothing for me to gain here, neither to
> learn
> > nor for teaching.
> >
> > You are right that the thread may have turned people off. I know 2
> > people who have thought, to paraphrase, "how can programmers be that
> > stupid!?" I discourage that type of discourse and I think it is
> unfair,
> > but they think it nonetheless. I'm sure it affected their
> prejudices of
> > using Scala. I also think it is unfair that while stating highly
> > relevant, proven, educational facts may or may not be contrary to
> > "appeasing the point of view of someone outside the community"
> (is it
> > really?), then there should be any apprehension of doing exactly
> that.
> >
> > Do you find it offensive that there are people who learned by
> thinking
> > about it?
> >
> > Dave Griffith wrote:
> >
> >> I thought about this for a bit, and honestly have neither the
> time nor the
> >> energy to do so.
> >> You can claim internet victory because of that if you wish, and
> I'd bet good
> >> money that you will. Alternatively, you could read back
> through the rather
> >> thuggishly hijacked thread and try
> >> to imagine how you must sound to others. In particular, how
> you must sound
> >> others
> >> who don't share your priors about what the appropriate domain of
> >> discourse of a Scala
> >> mailing list should be. For extra points, imagine it from the
> point of
> >> view of someone
> >> outside the community, trying to decide whether to use Scala or
> not. How
> >> effective do you
> >> really think you've been at "educating" them?
> >>
> >> --Dave Griffith
> >>
> >>
> >>
> >>
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
Re: Scaladoc that is actually useful?
Gah, sorry again list. Can we take this offline please?
By "you" I mean whoever it was I was parodying.
Tony Morris wrote:
> It's actually a parody of precisely what you wrote after you denied a fact.
>
> christopher marshall wrote:
>
>> This is what Tony said to the *first* person who said that he
>> disagreed that Tony's boo function should be commented as it would not
>> be clear to all (which he had written quite "passively"):
>>
>> "I think you should seriously consider your position, since your
>> apathy and indirect advocacy for poor education is part of the
>> problem, not the solution"
>>
>> I'm sorry, but I happen to find this sort of language and approach
>> unwarranted, unnecessary and does not belong on a professional mailing
>> list. It has all the hallmarks of a troll: i.e. it falls short of
>> direct personal abuse but can largely be read/interpreted as such.
>>
>> I think it was this initial attitude that largely set the combative
>> and confrontational tone for the rest of the discussion.
>>
>> Chris
>>
>> ------------------------------------------------------------------------
>> Date: Sun, 15 Nov 2009 23:47:19 +0100
>> Subject: Re: [scala-user] Scaladoc that is actually useful?
>> From: viktor [dot] klang [at] gmail [dot] com
>> To: tonymorris [at] gmail [dot] com
>> CC: dave [dot] l [dot] griffith [at] gmail [dot] com; scala-user [at] listes [dot] epfl [dot] ch
>>
>> It a rare occurrence, but I have to say that I'm with Tony on this one.
>>
>> One might not appreciate the tone of Tony in this series of e-mails,
>> but he's kept it balanced throughout his correspondence.
>>
>> On Sun, Nov 15, 2009 at 10:24 PM, Tony Morris > > wrote:
>>
>> Sorry Dave and list, I meant to reply off list. If you could that
>> I Dave
>> I'd appreciate it.
>>
>> Tony Morris wrote:
>> > Your motives are exposed. There is no "internet victory." I
>> stated my
>> > motives up front. I wish to educate. I succeeded. I have personal
>> > testimonies to that effect. I even have people that got off
>> first base
>> > and explored interesting questions down the path! Yes this
>> excites me,
>> > "internet victory" (whatever that means) doesn't. I'll hand that
>> over to
>> > you for whatever purpose it serves.
>> >
>> > I'll read back through it some day, but it is rather uninteresting.
>> > Consider my possible motivations for reading myself repeating a well
>> > established fact, to appease what I can only consider is a lack of
>> > comprehension. There is nothing for me to gain here, neither to
>> learn
>> > nor for teaching.
>> >
>> > You are right that the thread may have turned people off. I know 2
>> > people who have thought, to paraphrase, "how can programmers be that
>> > stupid!?" I discourage that type of discourse and I think it is
>> unfair,
>> > but they think it nonetheless. I'm sure it affected their
>> prejudices of
>> > using Scala. I also think it is unfair that while stating highly
>> > relevant, proven, educational facts may or may not be contrary to
>> > "appeasing the point of view of someone outside the community"
>> (is it
>> > really?), then there should be any apprehension of doing exactly
>> that.
>> >
>> > Do you find it offensive that there are people who learned by
>> thinking
>> > about it?
>> >
>> > Dave Griffith wrote:
>> >
>> >> I thought about this for a bit, and honestly have neither the
>> time nor the
>> >> energy to do so.
>> >> You can claim internet victory because of that if you wish, and
>> I'd bet good
>> >> money that you will. Alternatively, you could read back
>> through the rather
>> >> thuggishly hijacked thread and try
>> >> to imagine how you must sound to others. In particular, how
>> you must sound
>> >> others
>> >> who don't share your priors about what the appropriate domain of
>> >> discourse of a Scala
>> >> mailing list should be. For extra points, imagine it from the
>> point of
>> >> view of someone
>> >> outside the community, trying to decide whether to use Scala or
>> not. How
>> >> effective do you
>> >> really think you've been at "educating" them?
>> >>
>> >> --Dave Griffith
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>>
RE: Scaladoc that is actually useful?
Hmmm, I don't quite see it. Perhaps there is a proof?
> Date: Mon, 16 Nov 2009 19:07:20 +1000
> From: tonymorris [at] gmail [dot] com
> To: oxbow_lakes [at] hotmail [dot] com
> CC: viktor [dot] klang [at] gmail [dot] com; dave [dot] l [dot] griffith [at] gmail [dot] com; scala-user [at] listes [dot] epfl [dot] ch
> Subject: Re: [scala-user] Scaladoc that is actually useful?
>
> Gah, sorry again list. Can we take this offline please?
>
> By "you" I mean whoever it was I was parodying.
>
> Tony Morris wrote:
> > It's actually a parody of precisely what you wrote after you denied a fact.
> >
> > christopher marshall wrote:
> >
> >> This is what Tony said to the *first* person who said that he
> >> disagreed that Tony's boo function should be commented as it would not
> >> be clear to all (which he had written quite "passively"):
> >>
> >> "I think you should seriously consider your position, since your
> >> apathy and indirect advocacy for poor education is part of the
> >> problem, not the solution"
> >>
> >> I'm sorry, but I happen to find this sort of language and approach
> >> unwarranted, unnecessary and does not belong on a professional mailing
> >> list. It has all the hallmarks of a troll: i.e. it falls short of
> >> direct personal abuse but can largely be read/interpreted as such.
> >>
> >> I think it was this initial attitude that largely set the combative
> >> and confrontational tone for the rest of the discussion.
> >>
> >> Chris
> >>
> >> ------------------------------------------------------------------------
> >> Date: Sun, 15 Nov 2009 23:47:19 +0100
> >> Subject: Re: [scala-user] Scaladoc that is actually useful?
> >> From: viktor [dot] klang [at] gmail [dot] com
> >> To: tonymorris [at] gmail [dot] com
> >> CC: dave [dot] l [dot] griffith [at] gmail [dot] com; scala-user [at] listes [dot] epfl [dot] ch
> >>
> >> It a rare occurrence, but I have to say that I'm with Tony on this one.
> >>
> >> One might not appreciate the tone of Tony in this series of e-mails,
> >> but he's kept it balanced throughout his correspondence.
> >>
> >> On Sun, Nov 15, 2009 at 10:24 PM, Tony Morris <tonymorris [at] gmail [dot] com
> >> <mailto:tonymorris [at] gmail [dot] com>> wrote:
> >>
> >> Sorry Dave and list, I meant to reply off list. If you could that
> >> I Dave
> >> I'd appreciate it.
> >>
> >> Tony Morris wrote:
> >> > Your motives are exposed. There is no "internet victory." I
> >> stated my
> >> > motives up front. I wish to educate. I succeeded. I have personal
> >> > testimonies to that effect. I even have people that got off
> >> first base
> >> > and explored interesting questions down the path! Yes this
> >> excites me,
> >> > "internet victory" (whatever that means) doesn't. I'll hand that
> >> over to
> >> > you for whatever purpose it serves.
> >> >
> >> > I'll read back through it some day, but it is rather uninteresting.
> >> > Consider my possible motivations for reading myself repeating a well
> >> > established fact, to appease what I can only consider is a lack of
> >> > comprehension. There is nothing for me to gain here, neither to
> >> learn
> >> > nor for teaching.
> >> >
> >> > You are right that the thread may have turned people off. I know 2
> >> > people who have thought, to paraphrase, "how can programmers be that
> >> > stupid!?" I discourage that type of discourse and I think it is
> >> unfair,
> >> > but they think it nonetheless. I'm sure it affected their
> >> prejudices of
> >> > using Scala. I also think it is unfair that while stating highly
> >> > relevant, proven, educational facts may or may not be contrary to
> >> > "appeasing the point of view of someone outside the community"
> >> (is it
> >> > really?), then there should be any apprehension of doing exactly
> >> that.
> >> >
> >> > Do you find it offensive that there are people who learned by
> >> thinking
> >> > about it?
> >> >
> >> > Dave Griffith wrote:
> >> >
> >> >> I thought about this for a bit, and honestly have neither the
> >> time nor the
> >> >> energy to do so.
> >> >> You can claim internet victory because of that if you wish, and
> >> I'd bet good
> >> >> money that you will. Alternatively, you could read back
> >> through the rather
> >> >> thuggishly hijacked thread and try
> >> >> to imagine how you must sound to others. In particular, how
> >> you must sound
> >> >> others
> >> >> who don't share your priors about what the appropriate domain of
> >> >> discourse of a Scala
> >> >> mailing list should be. For extra points, imagine it from the
> >> point of
> >> >> view of someone
> >> >> outside the community, trying to decide whether to use Scala or
> >> not. How
> >> >> effective do you
> >> >> really think you've been at "educating" them?
> >> >>
> >> >> --Dave Griffith
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> Tony Morris
> >> http://tmorris.net/
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Viktor Klang
> >> | "A complex system that works is invariably
> >> | found to have evolved from a simple system
> >> | that worked." - John Gall
> >>
> >> Blog: klangism.blogspot.com <http://klangism.blogspot.com>
> >> Twttr: twitter.com/viktorklang <http://twitter.com/viktorklang>
> >> Code: github.com/viktorklang <http://github.com/viktorklang>
> >>
> >> ------------------------------------------------------------------------
> >> New! Receive and respond to mail from other email accounts from within
> >> Hotmail Find out how.
> >> <http://clk.atdmt.com/UKM/go/186394593/direct/01/%20>
> >>
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
Add other email accounts to Hotmail in 3 easy steps. Find out how.
Re: Scaladoc that is actually useful?
On Nov 16, 2009, at 24:47, Viktor Klang wrote:
Count me in on this one. My thoughts exactly.
I believe the crucial observation is "one might not appreciate the tone of Tony". A failure to see the big picture behind one's wording is a micro-social phenomenon. If, instead of getting ready to go to war, we could all just get better prepared to listen (and provided the one that speaks has good motives), then the outcome would be much more productive.
Thank you Viktor. I thought I should not go public, but your phrase that I quoted resonated with my thoughts on the matter [stated in private elsewhere].
Christos
--
__~O
-\ <, Christos KK Loverdos
(*)/ (*) http://ckkloverdos.com
Re: Scaladoc that is actually useful?
On Friday November 13 2009, christopher marshall wrote:
> > It can be rephrased to remove the ambiguity:
> >
> > "Forall returns false if at least one application of the predicate
> > returns false."
>
> This is still ambiguous as you've used if instead of iff (which,
> again, the "average" developer may not be familiar with)! And you
> still haven't told me whether the implementation will continue to
> evaluate the predicate after the result of the function is
> effectively decided (although the original doc about infinite
> collections gives a hint as to whether this is the case).
I didn't intend to rewrite the documentation, just show how that one
ambiguity might be expunged.
Randall Schulz
Re: Scaladoc that is actually useful?
I think to assist in this we need:
- the concept of a doclet (this solves the "show all methods vs. traits" debate, as well as many, many others)
- an easy to follow means of submitting patches to the docs
I know there was talk of moving the codebase to github. Is that going to happen? That would make submitting changes and managing them very easy.
Dave
---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com
On Fri, Nov 13, 2009 at 9:19 AM, christopher marshall <oxbow_lakes [at] hotmail [dot] com> wrote:
Re: Scaladoc that is actually useful?
When I first consulted the 2.8 docs I didn't like it, I thought there was a bug.
I got used to it, and now actually prefer it, the boxes (tables) for "methode inherited from"
actually give a more "zoomed out" overall view of what's
available, it's more dense, more info per square centimeter.
But if there's a way to get the best of both worlds, like a
button that woould toggle between an expanded and compressed view
it would certainly be ideal.
... I admit to everyone here : My mother is clueless about type theory !!!
Max
On Thu, Nov 12, 2009 at 11:36 PM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com> wrote:
Re: Scaladoc that is actually useful?
On Thursday November 12 2009, Cay Horstmann wrote:
> Earlier today I agreed with the original poster that there is a
> problem with Scaladoc, in that it makes seemingly simple tasks
> excessively complex for the programmer who has to get work done. ...
>
> suppose I want to use an ArrayBuffer in 2.8. The scaladoc sends me to
>
> ResizableArray
> Builder
> ...
> AnyRef
> Any
>
> Ok, maybe it's the Scala way to pick up lots of fragmentary traits.
> But then the Scaladoc could have a friendlier way of helping the new
> user, such as inline expanding the docs for the traits, or at least,
> copying out the summary method statements.
The Scaladoc HTML is an API reference, not a tutorial. Answers to "how
do I accomplish X" questions don't really belong there, I don't think.
> This really needs some fresh thinking without detours into "my mother
> knows more type theory than your mother".
A comprehensive tutorial introduction to its collection classes, e.g.,
is surely called for. I'm not sure to what extent that qualifies as
fresh thinking, though.
Scala is underdocumented, to be sure. Scarcely any open-source or
academic project at a comparable stage of evolution is.
Randall Schulz
Re: Scaladoc that is actually useful?
(A => B) => (B => C) => A => C
has only one truthful inhabitant and should quite legitimately be left undocumented. It could be argued that it is the onus of a programmer who writes an untruthful implementation of that function to document it instead of asking that the truthful one be documented.
Yet, I think this function has been raised as a straw-man. A large percentage of function signatures don't have the luxury of having only one inhabitant. I haven't really sat down and counted the number of such functions in the scala library that have not been documented. Nor have I counted the number side-affecting *methods* (as opposed to real functions) in the scala library that are undocumented, but my conjecture (happy for it to be proved wrong) is that those numbers are large enough to be concerned about. Which is what, IMO, the OP was concerned about.
Surely, you're not claiming that the latter two cases should not be documented?
Ishaaq
2009/11/13 Tony Morris <tonymorris [at] gmail [dot] com>
Re: Scaladoc that is actually useful?
Hello Ishaaq,
If I have adequately conveyed a point that is provable, has been proven
(by parametricity) and is easily falsifiable, then you'd think I'd hit
less resistance., but alas, it appears not.
I think I have adequately answered your concluding question too, don't
you? For those signatures that are inhabited more than once (and yes,
there are a lot), what should we do? The rash conclusion of "write
English" is just that, rash and has about as much thought put into it as
many of the respondents have put into my original question (hence, the
laborious repetition). My answer has thus far been, "No I am not (yet)
claiming anything about function signatures with multiple inhabitants."
I haven't even got to the point of being able to examine your question
further -- instead, we are going over and over on a matter of fact as if
it is even debatable! I was hoping that once this observation was made
(that there exists a signature for which documentation/tests are
redundant), then we could raise further questions. Ah, the Scala
community :)
It has been suggested to me by two peers that I should "bash them over
the head" but I still hold hope for a productive outcome!
Ishaaq Chandy wrote:
> Tony, I think you've quite adequately put the point across that
>
> (A => B) => (B => C) => A => C
>
> has only one truthful inhabitant and should quite legitimately be left
> undocumented. It could be argued that it is the onus of a programmer
> who writes an untruthful implementation of that function to document
> it instead of asking that the truthful one be documented.
>
> Yet, I think this function has been raised as a straw-man. A large
> percentage of function signatures don't have the luxury of having only
> one inhabitant. I haven't really sat down and counted the number of
> such functions in the scala library that have not been documented. Nor
> have I counted the number side-affecting *methods* (as opposed to real
> functions) in the scala library that are undocumented, but my
> conjecture (happy for it to be proved wrong) is that those numbers are
> large enough to be concerned about. Which is what, IMO, the OP was
> concerned about.
>
> Surely, you're not claiming that the latter two cases should not be
> documented?
>
> Ishaaq
>
> 2009/11/13 Tony Morris >
>
> So er, back to reality.
>
> Can you provide two inhabitants for:
> forall A B C. (A => B) => (B => C) => A => C
>
> Assume termination and no lies.
>
> (Hint: the answer begins with 'n' and ends with 'o').
>
> Dave Griffith wrote:
> >
> >
> > Tony Morris-4 wrote:
> >
> >> Do you know what function means?
> >>
> >>
> >
> > In type theory? In intuitionistic (a.k.a constructive) type
> theory? In
> > recursive function theory? In Haskell? In Scala? In C?
> >
> > Yes, I know what 'function' means, in all of the above. Even
> though the
> > definitions there have almost as many differences as similarities.
> >
> > In "reality"? Oh, hell no! I certainly don't know what a
> function is in
> > "reality", but based on the disagreement on this point among
> philosophers of
> > mathematics I'm pretty sure I'm not alone. The one thing I am
> sure of is
> > that it's not the sort of naive Platonism you seem to be
> espousing. If I
> > take a rock and sift it down to constituent quarks I'm pretty
> certain I
> > won't see any functions.
> >
> > How exactly is this helpful to someone who is trying to get some
> work done
> > and complaining that someone else didn't write good doc?
> >
> > --Dave Griffith
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
Re: Scaladoc that is actually useful?
You would have had a much easier time if you had stated up-front that you were assuming constructive type theory (or whatever it is that you're actually assuming--you never quite made that clear, though I believe constructive type theory fits), and that you assume that the basic terminology and results of type theory should be a prerequisite for anyone using Scala, and that one should only use Scala in ways consistent with type theory (even though it admits other patterns).
Actually, I don't know if you would have had an easier time, but with that as an assumption about what you meant, yes, what you're saying appears to be proven true--not much room for argument there.
Except I don't think that a signature that is proof of its function _by constructive type theory_ should necessarily be undocumented in Scala. If you write a library consisting entirely of stuff useful only to people working on constructive type theory, then I absolutely agree that the signature is plenty.
Otherwise, you might want to explain what you're doing in a comment on the method. At least something like "Obeys all assumptions of constructive type theory."
--Rex
Re: Scaladoc that is actually useful?
I stated my assumptions at least four times, perhaps more.
I was not assuming anything more than what I stated. Please (at least)
read Theorems for Free, Wadler. Or, if you like take the issue up with
the author of the @free plugin, which, knowingly or not, *proved*
(that's proved) the point way back.
Rex Kerr wrote:
> On Thu, Nov 12, 2009 at 10:52 PM, Tony Morris > wrote:
>
> Hello Ishaaq,
> If I have adequately conveyed a point that is provable, has been
> proven
> (by parametricity) and is easily falsifiable, then you'd think I'd hit
> less resistance., but alas, it appears not.
>
>
> You would have had a much easier time if you had stated up-front that
> you were assuming constructive type theory (or whatever it is that
> you're actually assuming--you never quite made that clear, though I
> believe constructive type theory fits), and that you assume that the
> basic terminology and results of type theory should be a prerequisite
> for anyone using Scala, and that one should only use Scala in ways
> consistent with type theory (even though it admits other patterns).
>
> Actually, I don't know if you would have had an easier time, but with
> that as an assumption about what you meant, yes, what you're saying
> appears to be proven true--not much room for argument there.
>
> Except I don't think that a signature that is proof of its function
> _by constructive type theory_ should necessarily be undocumented in
> Scala. If you write a library consisting entirely of stuff useful
> only to people working on constructive type theory, then I absolutely
> agree that the signature is plenty.
>
> Otherwise, you might want to explain what you're doing in a comment on
> the method. At least something like "Obeys all assumptions of
> constructive type theory."
>
> --Rex
>
Re: Scaladoc that is actually useful?
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 <tonymorris [at] gmail [dot] com> wrote:
Re: Scaladoc that is actually useful?
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/
>
>
>
Re: Scaladoc that is actually useful?
2009/11/13 Tony Morris :
> 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.
The problem is that a signature never captures the implicit "world"
argument that all functions have (otherwise, please show me your
functions having the "world" argument from which you access all of
scala libraries) . So the signature definitely has *not* just one
instance, but infinitely many.
If you don't assume that a function is able to compute other
functions, just because it didn't have them as arguments, you talk
about something else but definitely not about scala programming. May I
remind that the discussion is about _scala_ docs.
This point has already been made by Rex but lets try it again :)
Regards,
Dimitris
>
> 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?
It's entirely possible to construct a de-facto world state. The
signature definitely does have just one instance. It definitely does.
There is a proof. The strongest possible claim about reality exists.
There's not much I can do about the fact that you are refuting a proof
by simply asserting the contrary. I'd move this to scala-debate but it's
not even a debate.
I talk about *functions* and definitely Scala programming. I'm well
aware that Scala does not have an effect system. The question arises,
what shall we do about it? The answer is not English. Rex hasn't already
made this point -- *I* have already made this point.
I will repeat myself:
(A => B) => (B => C) => A => C
No subverting the types, assume termination --> once-inhabited!
I am exhausted, you win.
Dimitris Andreou wrote:
> 2009/11/13 Tony Morris :
>
>> 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.
>>
>
> The problem is that a signature never captures the implicit "world"
> argument that all functions have (otherwise, please show me your
> functions having the "world" argument from which you access all of
> scala libraries) . So the signature definitely has *not* just one
> instance, but infinitely many.
>
> If you don't assume that a function is able to compute other
> functions, just because it didn't have them as arguments, you talk
> about something else but definitely not about scala programming. May I
> remind that the discussion is about _scala_ docs.
>
> This point has already been made by Rex but lets try it again :)
>
> Regards,
> Dimitris
>
>
>> 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?
> Date: Fri, 13 Nov 2009 10:19:27 +1000
> From: tonymorris [at] gmail [dot] com
> To: jim [dot] andreou [at] gmail [dot] com
> CC: ichoran [at] gmail [dot] com; scala-user [at] listes [dot] epfl [dot] ch
> Subject: Re: [scala-user] Scaladoc that is actually useful?
>
> It's entirely possible to construct a de-facto world state. The
> signature definitely does have just one instance. It definitely does.
> There is a proof. The strongest possible claim about reality exists.
> There's not much I can do about the fact that you are refuting a proof
> by simply asserting the contrary. I'd move this to scala-debate but it's
> not even a debate.
>
> I talk about *functions* and definitely Scala programming. I'm well
> aware that Scala does not have an effect system. The question arises,
> what shall we do about it? The answer is not English. Rex hasn't already
> made this point -- *I* have already made this point.
>
> I will repeat myself:
> (A => B) => (B => C) => A => C
>
> No subverting the types, assume termination --> once-inhabited!
>
> I am exhausted, you win.
>
> Dimitris Andreou wrote:
> > 2009/11/13 Tony Morris <tonymorris [at] gmail [dot] com>:
> >
> >> 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.
> >>
> >
> > The problem is that a signature never captures the implicit "world"
> > argument that all functions have (otherwise, please show me your
> > functions having the "world" argument from which you access all of
> > scala libraries) . So the signature definitely has *not* just one
> > instance, but infinitely many.
> >
> > If you don't assume that a function is able to compute other
> > functions, just because it didn't have them as arguments, you talk
> > about something else but definitely not about scala programming. May I
> > remind that the discussion is about _scala_ docs.
> >
> > This point has already been made by Rex but lets try it again :)
> >
> > Regards,
> > Dimitris
> >
> >
> >> 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 <tonymorris [at] gmail [dot] com
> >>> <mailto:tonymorris [at] gmail [dot] com>> 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
> >>> <tonymorris [at] gmail [dot] com <mailto:tonymorris [at] gmail [dot] com>
> >>> > <mailto:tonymorris [at] gmail [dot] com <mailto:tonymorris [at] gmail [dot] com>>> 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/
> >>
> >>
> >>
> >>
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
New! Receive and respond to mail from other email accounts from within Hotmail Find out how.
Re: Scaladoc that is actually useful?
As I said, please give us a scala signature that constrains its body
from not using the world. Otherwise, I would be very happy to see how
exactly you encode the mathematical signature into a scala signature
which also has just one implementation. Thank you.
2009/11/13 Tony Morris :
> It's entirely possible to construct a de-facto world state. The
> signature definitely does have just one instance. It definitely does.
> There is a proof. The strongest possible claim about reality exists.
> There's not much I can do about the fact that you are refuting a proof
> by simply asserting the contrary. I'd move this to scala-debate but it's
> not even a debate.
>
> I talk about *functions* and definitely Scala programming. I'm well
> aware that Scala does not have an effect system. The question arises,
> what shall we do about it? The answer is not English. Rex hasn't already
> made this point -- *I* have already made this point.
>
> I will repeat myself:
> (A => B) => (B => C) => A => C
>
> No subverting the types, assume termination --> once-inhabited!
>
> I am exhausted, you win.
>
> Dimitris Andreou wrote:
>> 2009/11/13 Tony Morris :
>>
>>> 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.
>>>
>>
>> The problem is that a signature never captures the implicit "world"
>> argument that all functions have (otherwise, please show me your
>> functions having the "world" argument from which you access all of
>> scala libraries) . So the signature definitely has *not* just one
>> instance, but infinitely many.
>>
>> If you don't assume that a function is able to compute other
>> functions, just because it didn't have them as arguments, you talk
>> about something else but definitely not about scala programming. May I
>> remind that the discussion is about _scala_ docs.
>>
>> This point has already been made by Rex but lets try it again :)
>>
>> Regards,
>> Dimitris
>>
>>
>>> 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/
>>>
>>>
>>>
>>>
>>
>>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
Re: Scaladoc that is actually useful?
I did. I'm not sure what to do about the fact that you have failed to
see that.
Dimitris Andreou wrote:
> As I said, please give us a scala signature that constrains its body
> from not using the world. Otherwise, I would be very happy to see how
> exactly you encode the mathematical signature into a scala signature
> which also has just one implementation. Thank you.
>
> 2009/11/13 Tony Morris :
>
>> It's entirely possible to construct a de-facto world state. The
>> signature definitely does have just one instance. It definitely does.
>> There is a proof. The strongest possible claim about reality exists.
>> There's not much I can do about the fact that you are refuting a proof
>> by simply asserting the contrary. I'd move this to scala-debate but it's
>> not even a debate.
>>
>> I talk about *functions* and definitely Scala programming. I'm well
>> aware that Scala does not have an effect system. The question arises,
>> what shall we do about it? The answer is not English. Rex hasn't already
>> made this point -- *I* have already made this point.
>>
>> I will repeat myself:
>> (A => B) => (B => C) => A => C
>>
>> No subverting the types, assume termination --> once-inhabited!
>>
>> I am exhausted, you win.
>>
>> Dimitris Andreou wrote:
>>
>>> 2009/11/13 Tony Morris :
>>>
>>>
>>>> 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.
>>>>
>>>>
>>> The problem is that a signature never captures the implicit "world"
>>> argument that all functions have (otherwise, please show me your
>>> functions having the "world" argument from which you access all of
>>> scala libraries) . So the signature definitely has *not* just one
>>> instance, but infinitely many.
>>>
>>> If you don't assume that a function is able to compute other
>>> functions, just because it didn't have them as arguments, you talk
>>> about something else but definitely not about scala programming. May I
>>> remind that the discussion is about _scala_ docs.
>>>
>>> This point has already been made by Rex but lets try it again :)
>>>
>>> Regards,
>>> Dimitris
>>>
>>>
>>>
>>>> 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/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>
Re: Scaladoc that is actually useful?
2009/11/13 Tony Morris :
> I did. I'm not sure what to do about the fact that you have failed to
> see that.
I hope that was *not* your favourite line as a lecturer :)
This is the signature I see you gave:
def boo[A, B, C](f: A => B, g: B => C): A => C
It does not constrain "boo" (scala) implementations from using the
implicit world. So you did not address my request. If you gave another
signature I missed, please repeat.
Dimitris
>
> Dimitris Andreou wrote:
>> As I said, please give us a scala signature that constrains its body
>> from not using the world. Otherwise, I would be very happy to see how
>> exactly you encode the mathematical signature into a scala signature
>> which also has just one implementation. Thank you.
>>
>> 2009/11/13 Tony Morris :
>>
>>> It's entirely possible to construct a de-facto world state. The
>>> signature definitely does have just one instance. It definitely does.
>>> There is a proof. The strongest possible claim about reality exists.
>>> There's not much I can do about the fact that you are refuting a proof
>>> by simply asserting the contrary. I'd move this to scala-debate but it's
>>> not even a debate.
>>>
>>> I talk about *functions* and definitely Scala programming. I'm well
>>> aware that Scala does not have an effect system. The question arises,
>>> what shall we do about it? The answer is not English. Rex hasn't already
>>> made this point -- *I* have already made this point.
>>>
>>> I will repeat myself:
>>> (A => B) => (B => C) => A => C
>>>
>>> No subverting the types, assume termination --> once-inhabited!
>>>
>>> I am exhausted, you win.
>>>
>>> Dimitris Andreou wrote:
>>>
>>>> 2009/11/13 Tony Morris :
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>> The problem is that a signature never captures the implicit "world"
>>>> argument that all functions have (otherwise, please show me your
>>>> functions having the "world" argument from which you access all of
>>>> scala libraries) . So the signature definitely has *not* just one
>>>> instance, but infinitely many.
>>>>
>>>> If you don't assume that a function is able to compute other
>>>> functions, just because it didn't have them as arguments, you talk
>>>> about something else but definitely not about scala programming. May I
>>>> remind that the discussion is about _scala_ docs.
>>>>
>>>> This point has already been made by Rex but lets try it again :)
>>>>
>>>> Regards,
>>>> Dimitris
>>>>
>>>>
>>>>
>>>>> 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/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Tony Morris
>>> http://tmorris.net/
>>>
>>>
>>>
>>>
>>
>>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>