I'm attempting to write a Scala function to list all files/subdirectories under a given directory, but I'd like to make it tail recursive. Before I spend any more time on this is it even an attainable goal, or should I stick to regular recursion? I just want to know that it is possible, as I'd like to figure it out for myself. Good learning experience and all that. Thanks!
I seems you need some type of stack for tree traversal, so if you avoid the system stack you have to implement your own (see http://www.scala-lang.org/old/node/7984)
Related
This is really bad if it is what I think it is. I'm still learning Scala so I could be missing something HUGE but if I need constant time access to a specific element in a JObject, wouldn't storing the elements as a List(Tuple2) be REALLY REALLY REALLY bad for runtime?
I'm working on an application which uses Spark... and it looks like Spark is using json4s. I could imagine there's a good reasoning behind this, or maybe I don't know enough about Scala yet to understand why this doesn't matter.
Any thoughts?
Since non-tail recursion calls use stack frames like Java does, I'd think you'd be using it very sparingly, if at all. This seems however severely restrictive given it's one of the most important tools.
When can I use non-tail recursion functions? Also, are there plans to remove the memory restriction in the future?
In the same situations where it would be safe in Java, where the dataset you are working with never grows huge and the performance isn't critical/hot path of your app.
Also, IMHO, there are times when the clarity of non tail recursion version of an algorithm is way better than the tail recursive version.
Since non tail recursive recursion calls use stack frames like Java does, I'd be weary to do any recursion that, let's say goes beyond 1,000 times. I would be thus weary to use it for most of things.
Do people actually use non tail recursive recursion in Scala? If so, what are the criteria I can use to determine if it can be non tail recursive?
Also, are there plans to remove this memory restriction in future versions of Scala?
In the situation where you cannot use single tail recursion, for example because you need to alternative between two functions, a mechanism called trampolining has been described.
A more recent and thorough discussion of this topic can be found in Rúnar Bjarnason's paper Stackless Scala With Free Monads.
Personally, I would go the easy route and revert to imperative style if you really have this situation with >1K depths, e.g. use a mutable collection builder.
I'd really like to use case classes' copy feature in my project, but unfortunately I also need inheritance, which doesn't work well with case classes. So, I'm wondering if it's possible to write a macro which will generate a method for creating copy-with-changes object for an arbitrary class. What stops me there at the moment is the fact that AFAIK macros don't support named parameters. Has anyone found a way around that or, alternatively, can suggest other way for easy creating of copies which use inheritance?
That will be possible with type macros and/or annotation macros. The current macros do not support this.
Do look at lenses work, though. There's quite a few macro-based versions around, such as Shapeless.
You could also take a look at https://github.com/dicarlo2/ScalaEquals
I use a lot of scala maps, occasionally I want to pass them in as a map to a legacy java api which wants a java.util.Map (and I don't care if it throws away any changes).
An excellent library I have found that does a better job of this:
http://github.com/jorgeortiz85/scala-javautils
(bad name, awesome library). You explicitly invoke .asJava or .asScala depending on what direction you want to go. No surprises.
Scala provides wrappers for Java collections so that they can be used as Scala collections but not the other way around. That being said it probably wouldn't be hard to write your own wrapper and I'm sure it would be useful for the community. This question comes up on a regular basis.
This question and answer discuss this exact problem and the possible solutions. It advises against transparent conversions as they can have very strange side-effects. It advocates using scala-javautils instead. I've been using them in a large project for a few months now and have found them to be very reliable and easy to use.