Re: Scala & browser side scripting

Hi martin:

What is the status of the Java source code backend project? 
GWT 1.5 supporting Java 1.5 is now available (and buildable) via SVN. A
possible interaction between Scala and GWT, would be hooking the GWT
compiler to activate the Scala compiler when a .scala file has to be
compiled. The Scala compiler would generate a Java 1.5 AST to be translated
in to a GWT Java1.5 AST. I know how to  hook the GWT compiler, but don't
know how to do that in the Scala compiler. A plugin for the Scala compiler
is the way?
BTW, GWT performs monolithic compilation, but does not supports reflection,
then things like structural type matching should be implemented without
reflection. But thanks to monolithic compilation, we would solve this
problem in several ways.

-- Andrés

Martin Odersky wrote:
> 
> Tomi Maila wrote:
>> Hi,
>> 
>> Is anyone working on a project that would make Scala usable also for
>> browser side applications. Google Web Toolkits can compile limited set
>> of Java into browser side JavaScript applications. Adobe Flex can
>> generate flash applications from combination of proprietary MXML
>> language and EcmaScript. I wonder if anybody is working on something
>> similar for Scala so that one could write both client and server side of
>> web applications using pure Scala together with some markup language for

request for contributions : code completion

Hi,

I started the ScalaMiniIDE[1] plugin for jEdit[2], but I've not every skill like Sean (Eclipse Plugin) or
Caoyuan (Netbeans Plugin).
I request help, contributions,...
The main area where I need contribution, is for code completion (=> parsing).

Is someone interesting to work on code completion?

* I'll could provide test case
* code will be in scala (or in java)

Thanks

/davidB

[1] http://liftweb.net/index.php/SetUp_jEdit/
[2] http://jedit.org/

Re: request for contributions : code completion

I've had this open in my browser for ages now, with the vague
intention of implementing it for Scala:

http://www.emacswiki.org/cgi-bin/wiki/JavaCompletion

Perhaps you'll get more use/ideas out of it than I have thus far.

On Feb 1, 2008 11:50 AM, David Bernard <david.bernard.31 <at> gmail.com> wrote:
> Hi,
>
> I started the ScalaMiniIDE[1] plugin for jEdit[2], but I've not every skill like Sean (Eclipse Plugin) or
Caoyuan (Netbeans Plugin).
> I request help, contributions,...
> The main area where I need contribution, is for code completion (=> parsing).
>
> Is someone interesting to work on code completion?
>
> * I'll could provide test case
> * code will be in scala (or in java)
>
> Thanks
>
> /davidB
>
> [1] http://liftweb.net/index.php/SetUp_jEdit/
> [2] http://jedit.org/
>

Re: request for contributions : code completion

Thanks for the link, I'll study it.

FYI: jEdit have a plugin to help create completion and outline : SideKick
SideKick have provider for Ctags, ruby, java,...

I thought to integrate one of the existing parser (scalac, scalax,...) to use for completion and also to
display scaladoc, method signature, rename (in scope) ...
I don't know a lot about those technology, so I'm a little naive and underestimate the work.
My point of view, the main part is to be able to define the type of the item under cursor (anywhere in the text).

/davidB

Ricky Clarkson wrote:
> I've had this open in my browser for ages now, with the vague
> intention of implementing it for Scala:
> 
> http://www.emacswiki.org/cgi-bin/wiki/JavaCompletion
> 
> Perhaps you'll get more use/ideas out of it than I have thus far.
> 
> On Feb 1, 2008 11:50 AM, David Bernard <david.bernard.31 <at> gmail.com> wrote:
>> Hi,
>>
>> I started the ScalaMiniIDE[1] plugin for jEdit[2], but I've not every skill like Sean (Eclipse Plugin)
or Caoyuan (Netbeans Plugin).
>> I request help, contributions,...
>> The main area where I need contribution, is for code completion (=> parsing).
>>
>> Is someone interesting to work on code completion?
>>

Metaprogramming..

Re: Re: Scala & browser side scripting

Lex, I'm a GWT entusiast, currently involved with profesional projects
using GWT. I've developed a free JSON serializer for GWT
(http://code.google.com/p/gwt-jsonizer/ ). I'm also the founder of
www.juglar.og, the argentinian Java User Group.
I can take a time to contribute with this project the next month.
As Bruce and Scott suggest in the GWT Contributors Group, generating
JavaScript from bytecode is not a trivial task, since control
structures are very hard to be inferred. And we will lose the Java
source optimizations. My proposal is to simplify the Scala AST, and
then translate it to a GWT-Java AST. When I say "to simplify the Scala
AST", I'm saying:

* Division of implementation from interfaces in traits
* Replacement of structural types by flat traits
* Replacement of patten matching by if/else chains
* Explicitation of implicit parameters: hello[Int](123) -->
hello[Int](123)(ImplicitValue)
* etc.

This reduction is to generate an Scala AST mappeable with the Java
AST. Since GWT Compiler is not pluggable, we should create a GWT fork.

Thanks!

-- Andrés

2008/2/1, Lex Spoon <lex <at> lexspoon.org>:
> On Feb 1, 2008, at 4:48 AM, martin odersky wrote:
> > Hi Andres,
> >> Hi martin:
> >>
> >> What is the status of the Java source code backend project?
> >
> > We have not done any serious work in that yet,
> > but Lex has been looking at the possibility. maybe he can
> > add some perspective.
>
> I have looked at it, but I will not have serious hours to put into it
> for at least a month.  Do you have any time to work on it, Andres, or
> do you know anyone who might?  I do have some planning notes, and it
> looks like maybe 40-80 hours of work.
>
> If you like me are interested in GWT support, then be aware there is
> another strategy around: have GWT read in bytecodes instead of source
> code.  That has been talked about within GWT, but I have not tracked
> down the relevant people and I have not looked into it myself.  I
> don't know where you are coming from, but personally, I want to look
> at that alternative before diving into having Scala emit Java source.
>
>
> -Lex
>
>
>
>

Programming in Scala PrePrint/Backtalk

Hi All,

I wanted to let everyone know we delayed the next PrePrint release of  
Programming In Scala. We were originally shooting for end of next  
week, but are now planning to release it Monday, February 18th. That's  
a pretty firm deadline for us, but just in case, I want to remind you  
that this isn't a promise, just a very serious intention. But we want  
to get it out on that date so we can start a second round of feedback.

Thanks to all who have contributed comments via the backtalk system.  
It has been tremendously helpful. I just deployed a change to the  
backtalk system such that you can see comments made previously on the  
page on which you are about to comment. (This was in fact one of the  
suggestions.)

Thanks.

Bill

On Feb 1, 2008, at 10:20 AM, Amir Michail wrote:

> Hi,
>
> Thanks for the explanation.  This sounds like something that should be
> added to the Scala book.
>
> Amir
>
> On Feb 1, 2008 1:03 AM, Matt Hellige <matt <at> immute.net> wrote:
>> It's not a bug. The meaning of a for comprehension depends on the
>> types of the generators. In this case, the generators are Range
>> objects, which are a kind of Projection. Therefore the result of the
>> for "loop" is also a Projection, which is a kind of lazy sequence.
>> It's no surprise that the call to b hasn't been evaluated yet: that's
>> the whole point! In the second example you pass the projection to
>> println, which forces it to be evaluated by converting it to a  
>> string.
>>
>> In general, this is a good thing. It allows you to use your method
>> even if GRID_SIZE == Int.MAX_VALUE, and only compute as many values  
>> of
>> the resulting sequence as you actually need. This ability to deal  
>> with
>> very large ranges is the reason that Range is implemented this way.  
>> If
>> you really want to produce a strict sequence, you have a few options.
>> The two that seem obvious to me are:
>>  for { i <- (0 until GRID_SIZE).force // you must force the *first*  
>> one
>>    j <- 0 until GRID_SIZE } yield b(i,j)
>> or
>>  val proj = for { i <- 0 until GRID_SIZE)
>>    j <- 0 until GRID_SIZE } yield b(i,j)
>>  proj.force // or you can force the result
>>
>> Hope that helps...
>> Matt
>>
>>
>> On Jan 31, 2008 11:30 PM, Amir Michail <amichail <at> gmail.com> wrote:
>>> Hi,
>>>
>>> b is not executed here:
>>>
>>>  def gridFor[T](b: (Int,Int) => T) = {
>>>    for { i <- 0 until GRID_SIZE
>>>            j <- 0 until GRID_SIZE } yield b(i,j)
>>>  }
>>>
>>> but it is here:
>>>
>>>  def gridFor[T](b: (Int,Int) => T) = {
>>>    println(for { i <- 0 until GRID_SIZE
>>>                  j <- 0 until GRID_SIZE } yield b(i,j))
>>>  }
>>>
>>> Amir
>>>
>>
>>
>>
>> --
>> Matt Hellige / matt <at> immute.net
>> http://matt.immute.net
>>

NW Functional Programming Interest Group

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: A Tour of Scala: Explicitly Typed Self References

If you use "self: Node with NodeIntf =>" then the line "protected def
newNode: Node = new NodeImpl" doesn't compile. Anyway, seems that the
example is fixed now.
What advantages did you saw in using "self: Node with NodeIntf =>" ?

Thanks !!
Gabriel
http://gabrielsw.blogspot.com

Matt Hellige wrote:
> 
> Not quite. Probably it should be:
>   class NodeImpl {
>     self: Node with NodeIntf =>
> (Just change the original "extends" to "with".) Your version might
> also work, in this example (I haven't looked at the sample code in
> detail). In some specific cases, it's possible to write it either way,
> but in many cases, the difference matters.
> 
> Hope that helps...
> Matt
> 
> On Jan 30, 2008 7:01 PM, Gabriel Claramunt <gclaramunt <at> bellsouth.net>
> wrote:
>> Question:
>> In the Scala tour at the website
>> (http://www.scala-lang.org/intro/selfrefs.html).
>> The following code doesn't compile:
>> abstract class DirectedGraph extends Graph {
>>   ...
>>   class NodeImpl {
>>     self: Node extends NodeIntf =>
>>     def connectWith(node: Node): Edge = {
>>       val edge = newEdge(this, node)  // now legal
>>       edges = edge :: edges
>>       edge
>>     }
>>   }
>>   ...
>> }But it compiles if I change it to:
>>   ...
>>   class NodeImpl extends NodeIntf{
>>     self: Node  =>
>>   ...The second form is the right one?Gabriel
>> Claramunthttp://gabrielsw.blogspot.com
>>
>>
> 
> 
> 
> -- 
> Matt Hellige / matt <at> immute.net
> http://matt.immute.net
> 
> 

--

-- 
View this message in context: http://www.nabble.com/-scala--Scala-BoF-at-EclipseCon--tp15195682p15236446.html
Sent from the Scala mailing list archive at Nabble.com.

Re: A Tour of Scala: Explicitly Typed Self References

On Feb 1, 2008 5:52 PM, gclaramunt <gabriel.claramunt <at> gmail.com> wrote:
>
> If you use "self: Node with NodeIntf =>" then the line "protected def
> newNode: Node = new NodeImpl" doesn't compile.

Sorry about that. As I said, I didn't really take time to look at the
original example...

> Anyway, seems that the
> example is fixed now.

Very sneaky of them... ;)

> What advantages did you saw in using "self: Node with NodeIntf =>" ?

I didn't see any particular advantage, only that it was the literal
update of the old code to the new syntax (e.g., just changing
"extends" to "with" in the self-type. At least as the example
currently appears, it's clear that my way won't work, since NodeIntf
is an abstract class rather than a trait, and so no subclass could
ever add it as a mixin. I don't know whether the original example was
the same.

Anyway, sometimes it's possible to use an explicit self-type or an
"extends" clause. But in many cases you must use one or the other. In
this particular example, if NodeIntf were a trait, and if the code in
ConcreteDirectedGraph were changed to:
  type Node = NodeImpl with NodeIntf
  protected def newNode: Node = new NodeImpl with NodeIntf
then both versions of NodeImpl will work.

The difference is subtle, and whether to extend or use a self-type
depends on precisely what you need to accomplish. In this case, I much
prefer the official version (which is also your version). I guess if
there's a rule of thumb, it would be to prefer subclassing to
self-types, whenever possible. On the other hand, I really don't see
why NodeIntf is declared as an abstract class rather than a trait.
That seems unnecessarily restrictive to me...

Sorry again for the poor advice, and not taking the time to be sure.

Matt

--

-- 
Matt Hellige / matt <at> immute.net
http://matt.immute.net