Tail Recursion in IBM tutorial

[Arioch]

I read this:  
http://www.ibm.com/developerworks/java/library/j-scala06278.html

I am no one's newb in Scala, i even failed to install Eclipse plugin ;-)

So i sitched onto it and almost forgot of the case.

However open the link above and scroll to Listing 9 (same thing in PDF,  
however PDF's is a previous verson with obvious errors, so HTML is better)

Am i right that this is never a tail-recursion call ?
Am i right that last call would not the .count itself but {result of  
.count}.+(1) or (mathematically the same 1.+( {result of .count}) ?
Am i right that Scala compiler is not yet that advanced to transform this  
unary function into binary with accumulator parameter (that would allow  
make this really tail-recursive and that is quite obvious and easy  
optimisation, effectively transforming count to fold-left) ?

I wanted to use this Lazy Stream example to make infinite .count that  
would either finish by exhausting stack (if i'm right) or would finish  
never (iif article is right).  
http://scala-blogs.org/2007/12/project-euler-fun-in-scala.html

But i did not manage to run Eclipse + Scala and now i more want to get IDE  
than make my test in console, such a roach in my head now :-)

--
Используется революционный почтовый клиент браузера Opera:  
http://www.opera.com/mail/

[Christos KK Loverdos]

<possible-opening-1>
Am I right that the Scala compiler is so advanced, that you can take  
your parse tree (or your ICode) and turn it into apples or whatever  
you like by just hooking a compiler plugin via a well defined and  
public API?
</possible-opening-1>

<possible-opening-2>
Hi, the truth is that the Scala compiler is so advanced, that you can  
take your parse tree (or your ICode) and turn it into apples or  
whatever you like by just hooking a compiler plugin via a well defined  
and public API. Transformations like the one you mention, for example,  
would be possible by a compiler plugin AFAIK.
</possible-opening-2>

Also, don't worry about failures, because...

"Failure is the grandmother of all (usually intentional) success."

Christos.
[Haven't read the examples you mention, your third assertion? caught  
my intention, partly because I have done accumulator-based  
transformations manually a lot of times...]

On Aug 17, 2009, at 8:06 PM, Arioch wrote:

> I read this: http://www.ibm.com/developerworks/java/library/j-scala06278.html
>
> I am no one's newb in Scala, i even failed to install Eclipse  
> plugin ;-)
>
> So i sitched onto it and almost forgot of the case.
>
> However open the link above and scroll to Listing 9 (same thing in  
> PDF, however PDF's is a previous verson with obvious errors, so HTML  
> is better)
>
> Am i right that this is never a tail-recursion call ?
> Am i right that last call would not the .count itself but {result  
> of .count}.+(1) or (mathematically the same 1.+( {result of .count}) ?
> Am i right that Scala compiler is not yet that advanced to transform  
> this unary function into binary with accumulator parameter (that  
> would allow make this really tail-recursive and that is quite  
> obvious and easy optimisation, effectively transforming count to  
> fold-left) ?
>
> I wanted to use this Lazy Stream example to make infinite .count  
> that would either finish by exhausting stack (if i'm right) or would  
> finish never (iif article is right). http://scala-blogs.org/2007/12/project-euler-fun-in-scala.html
>
> But i did not manage to run Eclipse + Scala and now i more want to  
> get IDE than make my test in console, such a roach in my head now :-)
>
> --
> Используется революционный почтовый клиент б
> раузера Opera: http://www.opera.com/mail/
>

--
  __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

[Christos KK Loverdos]

["caught my intention"??? "attention" I believe is better...]

On Aug 17, 2009, at 8:27 PM, Christos KK Loverdos wrote:

> <possible-opening-1>
> Am I right that the Scala compiler is so advanced, that you can take  
> your parse tree (or your ICode) and turn it into apples or whatever  
> you like by just hooking a compiler plugin via a well defined and  
> public API?
> </possible-opening-1>
>
> <possible-opening-2>
> Hi, the truth is that the Scala compiler is so advanced, that you  
> can take your parse tree (or your ICode) and turn it into apples or  
> whatever you like by just hooking a compiler plugin via a well  
> defined and public API. Transformations like the one you mention,  
> for example, would be possible by a compiler plugin AFAIK.
> </possible-opening-2>
>
> Also, don't worry about failures, because...
>
> "Failure is the grandmother of all (usually intentional) success."
>
> Christos.
> [Haven't read the examples you mention, your third assertion? caught  
> my intention, partly because I have done accumulator-based  
> transformations manually a lot of times...]
>
> On Aug 17, 2009, at 8:06 PM, Arioch wrote:
>
>> I read this: http://www.ibm.com/developerworks/java/library/j-scala06278.html
>>
>> I am no one's newb in Scala, i even failed to install Eclipse  
>> plugin ;-)
>>
>> So i sitched onto it and almost forgot of the case.
>>
>> However open the link above and scroll to Listing 9 (same thing in  
>> PDF, however PDF's is a previous verson with obvious errors, so  
>> HTML is better)
>>
>> Am i right that this is never a tail-recursion call ?
>> Am i right that last call would not the .count itself but {result  
>> of .count}.+(1) or (mathematically the same 1.+( {result  
>> of .count}) ?
>> Am i right that Scala compiler is not yet that advanced to  
>> transform this unary function into binary with accumulator  
>> parameter (that would allow make this really tail-recursive and  
>> that is quite obvious and easy optimisation, effectively  
>> transforming count to fold-left) ?
>>
>> I wanted to use this Lazy Stream example to make infinite .count  
>> that would either finish by exhausting stack (if i'm right) or  
>> would finish never (iif article is right). http://scala-blogs.org/2007/12/project-euler-fun-in-scala.html
>>
>> But i did not manage to run Eclipse + Scala and now i more want to  
>> get IDE than make my test in console, such a roach in my head now :-)
>>
>> --
>> Используется революционный почтовый клиент б
>> раузера Opera: http://www.opera.com/mail/
>>
>
> --
> __~O
> -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>
>
>
>
>

--
  __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

[Arioch]

В письме от Mon, 17 Aug 2009 21:30:45 +0400, Christos KK Loverdos  
<loverdos@...> сообщал:

> via a well defined and public API

Oooo... plugins? you mean *install* something ? uit is so complex...
You definitely need Nemerle :-)

As for the rest, i hope to be once adanced enought to have fun of your  
jokes.
Still i would humbly wait for someone to estimate my thoughts about the  
Listing 9 in Link 1 :-)


--
Используется революционный почтовый клиент браузера Opera:  
http://www.opera.com/mail/

[Christos KK Loverdos]

On Aug 17, 2009, at 8:34 PM, Arioch wrote:

> В письме от Mon, 17 Aug 2009 21:30:45 +0400, Christos KK Loverdos <loverdos@
> gmail.com> сообщал:
>
>> via a well defined and public API
>
> Oooo... plugins? you mean *install* something ? uit is so complex...
> You definitely need Nemerle :-)
>
I was emphasizing the point that although the feature is not in  
current Scala, it can be programmed and incorporated seamlessly. This  
is made possible because the compiler is, in certain directions like  
this one, extensible. I perfectly understand this can be a no-answer  
to some people. I have no idea about Nemerle.

--
  __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

[jhonig]

Hi all,

I've been studying Scala for a little more than a week and I am delighted
about most features and utterly disappointed about some others.  I also
have some ideas that might be useful, but I'll come to those in separate
posts.

One thing that annoys me (to use an understatement), is the way the
compiler treats newlines.  I have been using a certain program layout
for years, for very good reasons, and am finding I am not free to layout
my program as I see fit.   I am now faced with less readable code.  A
prime example is the trailing binary operator, which I really dislike.  Is
there a way to escape the newline so the compiler doesn't see it???

Anther thing that is giving me a hard time, is the primary constructor vs
secondary constructor thing.  I would have been very happy if I had been
able to *choose* between *either* a constructor directly in the "class" line
(like the primary constructor) *or* one or more constructors in the class
body (like Java constructors).

I haven't been able to find a way to solve the following issue:  I want
to derive from a java class that has several constructors, with different
signatures.  I want to have new constructors from my Scala class,
calling super on the corresponding Java constructors.  Unfortunately,
there is no way to make everything work thru one superclass construc-
tor invoked from the primary constructor in the Scala class.  

Anybody know how to solve this?

Job Honig
TU Delft
The Netherlands

[Randall Schulz]

On Monday August 17 2009, Job Honig wrote:

> Hi all,
>
> I've been studying Scala for a little more than a week and I am
> delighted about most features and utterly disappointed about some
> others. ...
>
> One thing that annoys me (to use an understatement), is the way the
> compiler treats newlines.  I have been using a certain program layout
> for years, for very good reasons, and am finding I am not free to
> layout my program as I see fit.   I am now faced with less readable
> code.  A prime example is the trailing binary operator, which I
> really dislike.  Is there a way to escape the newline so the compiler
> doesn't see it???

I, too, have minority tastes in coding, though my Scala layout differs
less from that commonly used than does my Java differ from the various
norms. And I share your distaste for operators at the right, where
they're much less noticeable than at the left.

So what I do in these cases it toss parens around the whole thing. The
Scala parser will only infer a semicolon when there are no unbalanced /
unclosed parens at the point it encounters the newline.


> ...
>
> Job Honig


Randall Schulz

[jhonig]

Hi All,

I promised that I also would contribute some ideas, so here goes:

I'm very happy with the private[name] and private[this] visibility.  It
should not be too difficult to add private[object], private[class] and
private[package], wouldn't it?  The meaning would be the same as
when using the corresponding identifiers, but the advantage would
be that the keywords are much more "stable" when refactoring the
code.  private[object] would be an alias for private[this], but more
consistent wrt to the other modifiers...

Job Honig
TU Delft
The Netherlands

[Andrew Gaydenko]

On Monday 17 August 2009 22:22:00 Job Honig wrote:

> Anther thing that is giving me a hard time, is the primary constructor vs
> secondary constructor thing.  I would have been very happy if I had been
> able to *choose* between *either* a constructor directly in the "class"
> line (like the primary constructor) *or* one or more constructors in the
> class body (like Java constructors).
>
> I haven't been able to find a way to solve the following issue:  I want
> to derive from a java class that has several constructors, with different
> signatures.  I want to have new constructors from my Scala class,
> calling super on the corresponding Java constructors.  Unfortunately,
> there is no way to make everything work thru one superclass construc-
> tor invoked from the primary constructor in the Scala class.
>
> Anybody know how to solve this?

Use factory object.

[David Hall-15]

On Mon, Aug 17, 2009 at 11:22 AM, Job Honig<joho@...> wrote:

>
> Hi all,
>
> I've been studying Scala for a little more than a week and I am delighted
> about most features and utterly disappointed about some others.  I also
> have some ideas that might be useful, but I'll come to those in separate
> posts.
>
> One thing that annoys me (to use an understatement), is the way the
> compiler treats newlines.  I have been using a certain program layout
> for years, for very good reasons, and am finding I am not free to layout
> my program as I see fit.   I am now faced with less readable code.  A
> prime example is the trailing binary operator, which I really dislike.  Is
> there a way to escape the newline so the compiler doesn't see it???

This got me for a while too, but the solution is clean enough that I
don't mind anymore. Semicolon inference isn't performed inside of
parentheses, so you can just do:

val bigSum = ( Math.PI
                    + exp(1)
                    + 42 );

>
> Anther thing that is giving me a hard time, is the primary constructor vs
> secondary constructor thing.  I would have been very happy if I had been
> able to *choose* between *either* a constructor directly in the "class" line
> (like the primary constructor) *or* one or more constructors in the class
> body (like Java constructors).
>
> I haven't been able to find a way to solve the following issue:  I want
> to derive from a java class that has several constructors, with different
> signatures.  I want to have new constructors from my Scala class,
> calling super on the corresponding Java constructors.  Unfortunately,
> there is no way to make everything work thru one superclass construc-
> tor invoked from the primary constructor in the Scala class.
>
> Anybody know how to solve this?
>
> Job Honig
> TU Delft
> The Netherlands
>

[jhonig]

Hi Randall,

> So what I do in these cases it toss parens around the whole thing. The
> Scala parser will only infer a semicolon when there are no unbalanced /
> unclosed parens at the point it encounters the newline.

Yes, that's what I've been doing.  But that doesn't always work as in

// class scaladoc comment

class classname

  // This would be the proper place for a constructor scaladoc comment

  [private] (constructor arguments)

  extends ... {

}

But a way to escape the newline would not break any code and solve the
problem!

Job Honig
TU Delft
The Netherlands

[jhonig]

> This got me for a while too, but the solution is clean enough that I
> don't mind anymore. Semicolon inference isn't performed inside of
> parentheses, so you can just do:
>
> val bigSum = ( Math.PI
>                     + exp(1)
>                     + 42 );

But it's not only there, see my second post about this issue.  But
I guess the answer to my question was NO?  Meaning: there is
NO way to escape newlines?

Job H.

[Ricky Clarkson]

I find it more readable to write long lines.  And where that is no
longer readable (usually when the line gets wider than my monitor),
the introduction of 'explaining' variables often helps.  Even if they
have dumb names like 'x'.

As to your other point in an email not included in this top-post, I
suggest merging the primary constructor documentation with the class
documentation.  If they really need to be separately documented,
perhaps the constructor should be auxiliary, not primary.

If you really want to escape newlines, maybe look into a preprocessor.

2009/8/17 David Hall <dlwh@...>:

> On Mon, Aug 17, 2009 at 11:22 AM, Job Honig<joho@...> wrote:
>>
>> Hi all,
>>
>> I've been studying Scala for a little more than a week and I am delighted
>> about most features and utterly disappointed about some others.  I also
>> have some ideas that might be useful, but I'll come to those in separate
>> posts.
>>
>> One thing that annoys me (to use an understatement), is the way the
>> compiler treats newlines.  I have been using a certain program layout
>> for years, for very good reasons, and am finding I am not free to layout
>> my program as I see fit.   I am now faced with less readable code.  A
>> prime example is the trailing binary operator, which I really dislike.  Is
>> there a way to escape the newline so the compiler doesn't see it???
>
> This got me for a while too, but the solution is clean enough that I
> don't mind anymore. Semicolon inference isn't performed inside of
> parentheses, so you can just do:
>
> val bigSum = ( Math.PI
>                    + exp(1)
>                    + 42 );
>
>
>
>
>>
>> Anther thing that is giving me a hard time, is the primary constructor vs
>> secondary constructor thing.  I would have been very happy if I had been
>> able to *choose* between *either* a constructor directly in the "class" line
>> (like the primary constructor) *or* one or more constructors in the class
>> body (like Java constructors).
>>
>> I haven't been able to find a way to solve the following issue:  I want
>> to derive from a java class that has several constructors, with different
>> signatures.  I want to have new constructors from my Scala class,
>> calling super on the corresponding Java constructors.  Unfortunately,
>> there is no way to make everything work thru one superclass construc-
>> tor invoked from the primary constructor in the Scala class.
>>
>> Anybody know how to solve this?
>>
>> Job Honig
>> TU Delft
>> The Netherlands
>>
>

--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...

[strattonbrazil]

> On Monday 17 August 2009 22:22:00 Job Honig wrote:
>> Anther thing that is giving me a hard time, is the primary constructor vs
>> secondary constructor thing.  I would have been very happy if I had been
>> able to *choose* between *either* a constructor directly in the "class"
>> line (like the primary constructor) *or* one or more constructors in the
>> class body (like Java constructors).
>>
>> I haven't been able to find a way to solve the following issue:  I want
>> to derive from a java class that has several constructors, with different
>> signatures.  I want to have new constructors from my Scala class,
>> calling super on the corresponding Java constructors.  Unfortunately,
>> there is no way to make everything work thru one superclass construc-
>> tor invoked from the primary constructor in the Scala class.
>>
>> Anybody know how to solve this?
>
> Use factory object.

I was showing my Java-savvy friend Scala last night and he thought it
was strange as I initially did that Scala treats 'class' and 'object'
docs differently as to put them into separate documents even if they
have the same name.  At first I thought this was annoying, but I've
now found it helps separate the factory methods from the instances
themselves.

When I first read about the way Scala handled constructors, I thought
it too would require me to jump through hoops to handle the different
signatures, but using factory methods in the objects has actually made
my code easier to read like a way to separate creation and use of
those classes.

Josh

[Naftoli Gugenheim]

---------- Forwarded message ----------
From: Naftoli Gugenheim <naftoligug@...>
Date: Mon, Aug 17, 2009 at 2:38 PM
Subject: Re: [scala-user] Question about constructors
To: Job Honig <joho@...>

 // This would be the proper place for a constructor scaladoc comment

Not necessarily. I think Scala's idea of primary constructor is that its arguments are the class's arguments.

This explains why the class body can contain statements accessing its arguments, and the other constructors must call the primary constuctor.

Scala has a different way of looking at classes. Classes take type arguments and value arguments.

[jhonig]

> > Use factory object.

> When I first read about the way Scala handled constructors, I thought
> it too would require me to jump through hoops to handle the different
> signatures, but using factory methods in the objects has actually made
> my code easier to read like a way to separate creation and use of
> those classes.

Maybe I missed something, there was a lot to read :-)

How can I invoke the superclass constructors from those factory
methods? The point is that I can't change the Java code that has
a different way of thinking about the constructors.  I like the Scala
way, but have to deal with Java superclasses.

Job Honig

[jhonig]

> As to your other point in an email not included in this top-post, I
> suggest merging the primary constructor documentation with the class
> documentation.  If they really need to be separately documented,
> perhaps the constructor should be auxiliary, not primary.

That's what I'm doing, but I'm not satisfied with it.  

> If you really want to escape newlines, maybe look into a preprocessor.

Yes, would be the easiest workaround.   Somebody said: use long lines,
but the fact is that I have been using CheckStyle for 10 years and am used
to keeping everything within 80 chars. :-)

Job H.

[Naftoli Gugenheim]

A factory will not be a derived class.

The only thing I can think of is to write a teeny layer in Java, a class that derives from the other class and exposes a different set of constructors; and then to extends that class.

On Mon, Aug 17, 2009 at 2:44 PM, Job Honig <joho@...> wrote:

> > Use factory object.

> When I first read about the way Scala handled constructors, I thought
> it too would require me to jump through hoops to handle the different
> signatures, but using factory methods in the objects has actually made
> my code easier to read like a way to separate creation and use of
> those classes.

Maybe I missed something, there was a lot to read :-)

How can I invoke the superclass constructors from those factory
methods? The point is that I can't change the Java code that has
a different way of thinking about the constructors.  I like the Scala
way, but have to deal with Java superclasses.

Job Honig

[Josh Suereth]

Create a Java class that inherits from the one you want and provide *one constructor*.   (Having more than one path through construction of an object can be considered a code smell, and has often bitten me in projects).   Then have Scala extends this Java Class.

Remember that Scala is a different language from Java and deserveds different coding styles.  I try to use coding styles appropriate to the language I'm using.  JavaScript and Java have different styles, so why not Scala + Java? 

- Josh

On Mon, Aug 17, 2009 at 2:47 PM, Job Honig <joho@...> wrote:

> As to your other point in an email not included in this top-post, I
> suggest merging the primary constructor documentation with the class
> documentation.  If they really need to be separately documented,
> perhaps the constructor should be auxiliary, not primary.

That's what I'm doing, but I'm not satisfied with it.

> If you really want to escape newlines, maybe look into a preprocessor.

Yes, would be the easiest workaround.   Somebody said: use long lines,
but the fact is that I have been using CheckStyle for 10 years and am used
to keeping everything within 80 chars. :-)

Job H.

[Ricky Clarkson]

80 chars?  80?  Really eighty?

I'm typing this on an Asus EEE with a 7" screen.  Let me just maximise
a terminal window and see how many characters I can fit on it
horizontally.

130.  With default settings.  What are you aiming to program on, a
mobile phone?  A postage stamp?

More seriously, I used to stick to those settings, until I realised
that I was in fact hampering readability, rather than helping it.

A spell of Lisp should help you to recover.

2009/8/17 Job Honig <joho@...>:

>
>> As to your other point in an email not included in this top-post, I
>> suggest merging the primary constructor documentation with the class
>> documentation.  If they really need to be separately documented,
>> perhaps the constructor should be auxiliary, not primary.
>
> That's what I'm doing, but I'm not satisfied with it.
>
>> If you really want to escape newlines, maybe look into a preprocessor.
>
> Yes, would be the easiest workaround.   Somebody said: use long lines,
> but the fact is that I have been using CheckStyle for 10 years and am used
> to keeping everything within 80 chars. :-)
>
> Job H.
>

--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...