Any interest in developing these SIDs?

Hi Willis,

Thanks for your proposals. here's my initial reaction to them.

XML Enhancements:  

Definitely worth doing. There need to be large stakeholders of existing XML library on board to ensure that breakage is kept to a minimum.

Standard Date Library:  

A SID on that would be really neat to have.

Function Unification:  This is a big subject and has probably been discussed at length by people smarter than I am.  But the basic idea would be to unify FunctionN and PartialFunction into just Function, and to unify the syntax for defining functions, partial functions, and methods.  A function with N arguments where N > 1 would be Function[TupleN[P1, P2, ..., PN], R] rather than FunctionN[P1, ... PN, R], and Function would have an isDefinedAt method.

This is much harder and depends on people intimately knowing the compiler to the degree where they'd take over core compiler development. Some of the proposal
(i.e. treat FunctionN[As, B] as Function1[TupleN[As], B]) is planned but not scheduled yet for a release.

Cheers

 -- Martin

On Wed, Jun 16, 2010 at 12:16 PM, Willis Blackburn wrote:
> I think that we could create an initial implementation either based on Calendar or on Stephen Colebourne's Joda-Time library.

A better bet is probably:

https://jsr-310.dev.java.net/

Best,
Ismael

Actually, I suggest paying close attention to Noda, Jon Skeet's "port" of Joda to .Net. He paid close attention to JSR-310 and some of the problems of the Joda library.
http://noda-time.blogspot.com/ http://code.google.com/p/noda-time/

On Wed, Jun 16, 2010 at 9:36 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Wed, Jun 16, 2010 at 12:16 PM, Willis Blackburn <wboyce@panix.com> wrote:
> I think that we could create an initial implementation either based on Calendar or on Stephen Colebourne's Joda-Time library.

A better bet is probably:

https://jsr-310.dev.java.net/

Best,
Ismael

--
Daniel C. Sobral

I travel to the future all the time.

I'm aware of JSR 310, but it's not clear that it's going to be in JDK 7. I thought it was out, but JDK 7 seems to be infinitely delayed, and JSR 310 is showing new signs of life, so maybe it will wind up getting in. If it's going to be part of JDK 7 then great, we can create some Scala-friendly wrappers around it. Or maybe we just come up with a Scala date API, implement it with Calendar or Joda-Time first, then replace it with a JSR 310-based implementation if that ever shows up.

W

On Jun 16, 2010, at 8:36 AM, Ismael Juma wrote:

> On Wed, Jun 16, 2010 at 12:16 PM, Willis Blackburn wrote:
>> I think that we could create an initial implementation either based on Calendar or on Stephen Colebourne's Joda-Time library.
>
> A better bet is probably:
>
> https://jsr-310.dev.java.net/
>
> Best,
> Ismael
>

On 16/06/2010 13:16, Willis Blackburn wrote:
> XML Enhancements: Being able to enter XML directly into source code
> is very powerful, but the current implementation is rough around the
> edges. I think that the SID would focus on creating a more detailed
> specification, improving support for namespaces and attributes, and
> addressing developer annoyances.

I do believe that you could get much love of Scala (and Lift) user with
takin care of that one...

I know Paul tackled this at some point in the run up to 2.8, but it got shelved due to various issues, hopefully shouldn't be too hard to resurrect for, maybe, 2.8.2 or thereabouts

On 16 June 2010 14:21, Francois <fanf42@gmail.com> wrote:

On 16/06/2010 13:16, Willis Blackburn wrote:
> XML Enhancements:  Being able to enter XML directly into source code
> is very powerful, but the current implementation is rough around the
> edges.  I think that the SID would focus on creating a more detailed
> specification, improving support for namespaces and attributes, and
> addressing developer annoyances.

I do believe that you could get much love of Scala (and Lift) user with takin care of that one...

On Wed, Jun 16, 2010 at 1:57 PM, Willis Blackburn wrote:
> I'm aware of JSR 310, but it's not clear that it's going to be in JDK 7.  I thought it was out, but JDK 7 seems to be infinitely delayed, and JSR 310 is showing new signs of life, so maybe it will wind up getting in.  If it's going to be part of JDK 7 then great, we can create some Scala-friendly wrappers around it.  Or maybe we just come up with a Scala date API, implement it with Calendar or Joda-Time first, then replace it with a JSR 310-based implementation if that ever shows up.

If you're willing to include a third-party library like Joda-Time,
then there's no reason why JSR 310 can't be included as a third-party
library. Assuming they finish it, of course. As you say, things
started moving again and they are past the EDR stage now. If including
a third-party library is undesirable, then using Calendar seems like
the only choice although it's pretty bad.

Best,
Ismael

Do we need to have a backing library at all? It could be designed with JSR 310 in mind, but provide compatility to it through something like JavaConversions, being fully self-contained.

On Wed, Jun 16, 2010 at 10:44 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Wed, Jun 16, 2010 at 1:57 PM, Willis Blackburn <wboyce@panix.com> wrote:
> I'm aware of JSR 310, but it's not clear that it's going to be in JDK 7.  I thought it was out, but JDK 7 seems to be infinitely delayed, and JSR 310 is showing new signs of life, so maybe it will wind up getting in.  If it's going to be part of JDK 7 then great, we can create some Scala-friendly wrappers around it.  Or maybe we just come up with a Scala date API, implement it with Calendar or Joda-Time first, then replace it with a JSR 310-based implementation if that ever shows up.

If you're willing to include a third-party library like Joda-Time,
then there's no reason why JSR 310 can't be included as a third-party
library. Assuming they finish it, of course. As you say, things
started moving again and they are past the EDR stage now. If including
a third-party library is undesirable, then using Calendar seems like
the only choice although it's pretty bad.

Best,
Ismael

--
Daniel C. Sobral

I travel to the future all the time.

On Wed, Jun 16, 2010 at 07:16:40AM -0400, Willis Blackburn wrote:
> Function Unification: This is a big subject and has probably been
> discussed at length by people smarter than I am. But the basic idea
> would be to unify FunctionN and PartialFunction into just Function,
> and to unify the syntax for defining functions, partial functions, and
> methods. A function with N arguments where N > 1 would be
> Function[TupleN[P1, P2, ..., PN], R] rather than FunctionN[P1, ... PN,
> R], and Function would have an isDefinedAt method.

I had an idea here I'd been meaning to bring up, not really about the
tuple unification side (which I am also interested in) but the current
glitches with partialfunctions. If we introduced a new trait
TotalFunction, and had Function1 as parent with Total and Partial as
siblings, then without having thought about it too deeply I think we can
preserve compatibility and see PFs become less unwieldy.

On Wed, Jun 16, 2010 at 4:59 PM, Daniel Sobral wrote:
> Do we need to have a backing library at all? It could be designed with JSR
> 310 in mind, but provide compatility to it through something like
> JavaConversions, being fully self-contained.

It's just much more work to do it that way.

Best,
Ismael

Oh okay. I should have clarified that I meant build a Scala date
implementation using Joda-Time as a starting point. It wouldn't be
implemented in terms of Joda-Time, just borrow heavily from it.
Subject to some license compatibility analysis of course.

W

Sent from my iPhone

On Jun 16, 2010, at 9:44 AM, Ismael Juma wrote:

> On Wed, Jun 16, 2010 at 1:57 PM, Willis Blackburn
> wrote:
>> I'm aware of JSR 310, but it's not clear that it's going to be in
>> JDK 7. I thought it was out, but JDK 7 seems to be infinitely
>> delayed, and JSR 310 is showing new signs of life, so maybe it will
>> wind up getting in. If it's going to be part of JDK 7 then great,
>> we can create some Scala-friendly wrappers around it. Or maybe we
>> just come up with a Scala date API, implement it with Calendar or
>> Joda-Time first, then replace it with a JSR 310-based
>> implementation if that ever shows up.
>
> If you're willing to include a third-party library like Joda-Time,
> then there's no reason why JSR 310 can't be included as a third-party
> library. Assuming they finish it, of course. As you say, things
> started moving again and they are past the EDR stage now. If including
> a third-party library is undesirable, then using Calendar seems like
> the only choice although it's pretty bad.
>
> Best,
> Ismael
>

Indeed - we should definitely wait until JSR-310 is up and being used in the wild and it is a total waste of time developing a SID around JODA as this is now pretty much a legacy API. Pimping JODA is for the scala community, not EPFL in my opinion.
As someone who has written his own Date/Instant API (using java.util.Calendar as the underlying "calculator") and then pimped this library in scala (and some of the java.util.concurrent stuff) so that I can write :
    Schedule(func) startingIn 3.minutes thenEvery 2.hours until MIDNIGHT
...I would ask the scala bods to please, please, PLEASE not "officialize" a hugely bloated Java API which is solving a problem that *almost noone has* (Klingon calendars anyone?)
My pimping code amounts to a few hundred lines of Scala at most. 
Chris

> Subject: Re: [scala-internals] Any interest in developing these SIDs?
> From: wboyce@panix.com
> Date: Wed, 16 Jun 2010 08:57:11 -0400
> CC: scala-internals@listes.epfl.ch
> To: mlists@juma.me.uk
>
> I'm aware of JSR 310, but it's not clear that it's going to be in JDK 7. I thought it was out, but JDK 7 seems to be infinitely delayed, and JSR 310 is showing new signs of life, so maybe it will wind up getting in. If it's going to be part of JDK 7 then great, we can create some Scala-friendly wrappers around it. Or maybe we just come up with a Scala date API, implement it with Calendar or Joda-Time first, then replace it with a JSR 310-based implementation if that ever shows up.


Get a free e-mail account with Hotmail. Sign-up now.

All right so the feedback I'm getting is, function unification is really hard, date library is premature, but XML enhancements would be welcome if it doesn't break too much.
I also think that XML enhancements would provide the best payoff. I'm all about increasing the adoption of Scala, and better date-handling would probably not be a big driver.  Calendar is annoying, but we've been living with it for 15 years. Scala's XML support, on the other hand is a major differentiator and has broad applicability, especially for webapps.
If anyone has thoughts on how to improve Scala's XML features could you please send them to me? I'll figure out what people think is important and propose some goals.
W 
Sent from my iPhone
On Jun 17, 2010, at 3:37 AM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

Indeed - we should definitely wait until JSR-310 is up and being used in the wild and it is a total waste of time developing a SID around JODA as this is now pretty much a legacy API. Pimping JODA is for the scala community, not EPFL in my opinion.
As someone who has written his own Date/Instant API (using java.util.Calendar as the underlying "calculator") and then pimped this library in scala (and some of the java.util.concurrent stuff) so that I can write :
    Schedule(func) startingIn 3.minutes thenEvery 2.hours until MIDNIGHT
...I would ask the scala bods to please, please, PLEASE not "officialize" a hugely bloated Java API which is solving a problem that *almost noone has* (Klingon calendars anyone?)
My pimping code amounts to a few hundred lines of Scala at most. 
Chris

> Subject: Re: [scala-internals] Any interest in developing these SIDs?
> From: (wboyce [at] panix [dot] com
> Date: Wed, 16 Jun 2010 08:57:11 -0400
> CC: (scala-internals [at] listes [dot] epfl [dot] ch
> To: (mlists [at] juma [dot] me [dot] uk
>
> I'm aware of JSR 310, but it's not clear that it's going to be in JDK 7. I thought it was out, but JDK 7 seems to be infinitely delayed, and JSR 310 is showing new signs of life, so maybe it will wind up getting in. If it's going to be part of JDK 7 then great, we can create some Scala-friendly wrappers around it. Or maybe we just come up with a Scala date API, implement it with Calendar or Joda-Time first, then replace it with a JSR 310-based implementation if that ever shows up.


Get a free e-mail account with Hotmail. Sign-up now.

On Thu, Jun 17, 2010 at 12:53:20PM -0400, Willis Blackburn wrote:
> If anyone has thoughts on how to improve Scala's XML features could
> you please send them to me? I'll figure out what people think is
> important and propose some goals.

My opinion is that anyone seriously tackling XML should give a good,
long, serious study to these:

http://xduce.sourceforge.net/
http://www.cduce.org/

Admission: I have not myself given it a good, long, serious study, and
most likely XML will never rise high enough on my list to warrant such.
But I think I have decent instincts about where the payoffs are.

On Thu, Jun 17, 2010 at 6:58 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jun 17, 2010 at 12:53:20PM -0400, Willis Blackburn wrote:
> If anyone has thoughts on how to improve Scala's XML features could
> you please send them to me? I'll figure out what people think is
> important and propose some goals.

My opinion is that anyone seriously tackling XML should give a good,
long, serious study to these:

 http://xduce.sourceforge.net/
 http://www.cduce.org/

Cduce goes much further than what we can reasonably expect for Scala. It's an extremely powerful but also very complicated type system that makes some assumptions that are incompatible with Scala. I know because I have been on the thesis committee of Alain Frisch, who built CDuce.
I would not recommend to go there. On the other hand, and much more modestly, I would hope that any XML enhancement would at least include a zipper.

Cheers

 -- Martin

On Thu, Jun 17, 2010 at 07:11:35PM +0200, martin odersky wrote:
> Cduce goes much further than what we can reasonably expect for Scala.
> It's an extremely powerful but also very complicated type system that
> makes some assumptions that are incompatible with Scala. I know
> because I have been on the thesis committee of Alain Frisch, who built
> CDuce.

That's interesting. I'm going to say we're not disagreeing, because I
wasn't necessarily advocating that we do things like they did, but that
they will have wrestled with similar issues in a sophisticated way.
Even taking as a premise that it's the wrong direction to go, it
warrants study to find out what drove them in that direction and how we
anticipate dealing with the same factors.

> I would not recommend to go there. On the other hand, and much more
> modestly, I would hope that any XML enhancement would at least include
> a zipper.

I was just talking about that with someone at the scala meeting on
tuesday, the same time I discovered that clojure has an xml zipper. I
think we should be encouraging a friendly rivalry with the clojurists
and when they have something we don't, they're TAUNTING us! Are you
going to put up with that, Abstract Scala Community?

On Thu, Jun 17, 2010 at 10:11 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, Jun 17, 2010 at 6:58 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jun 17, 2010 at 12:53:20PM -0400, Willis Blackburn wrote:
> If anyone has thoughts on how to improve Scala's XML features could
> you please send them to me? I'll figure out what people think is
> important and propose some goals.

My opinion is that anyone seriously tackling XML should give a good,
long, serious study to these:

 http://xduce.sourceforge.net/
 http://www.cduce.org/

Cduce goes much further than what we can reasonably expect for Scala. It's an extremely powerful but also very complicated type system that makes some assumptions that are incompatible with Scala. I know because I have been on the thesis committee of Alain Frisch, who built CDuce.
I would not recommend to go there. On the other hand, and much more modestly, I would hope that any XML enhancement would at least include a zipper.

I think there are two separate (but interrelated issues):

• The XML libraries... there's a ton of stuff that can be done with them.
• The XML literals in language.  Less can be done with them.

Personally, I'd love to see a re-imagining and re-write of the XML libraries.  The amount of "stuff" that needs to happen in the literals is much smaller in my opinion (support for CDATA, marginal improvements for namespace support, removal of XML pattern matching, requiring either String or Node or Seq[Node] in variable XML content (stuff inside the { }).)
 

Cheers

 -- Martin

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

>>>>> "Willis" == Willis Blackburn writes:

Willis> If anyone has thoughts on how to improve Scala's XML features
Willis> could you please send them to me? I'll figure out what people
Willis> think is important and propose some goals.

Node shouldn't extend Seq[Node], for starters...!

And there are a ton of open tickets in Trac that (afaik) no one is
working on.

There is some past discussion in the scala-xml archives at
http://dir.gmane.org/gmane.comp.lang.scala.xml

>
> Node shouldn't extend Seq[Node], for starters...!
>
>

I thought that was strange at first, but I suspect that it was done
that way in order to save memory by not creating lots of wrapper
collections around single nodes. After all XML DOM-type structures are
notorious memory hogs and so every bit helps. To me it seems okay for
some type X to also serve as a single-element sequence of itself. Kind
of elegant really.

W

Damn taunters.

I have one. Zipper with nice xml handling with proper qnames and a fairly decent xpath impl. It needs some Extractor and dsl style tlc.

Progress is a little slow though due to time constraints :(

On Jun 17, 2010 7:38 PM, "Paul Phillips" <paulp@improving.org> wrote:

On Thu, Jun 17, 2010 at 07:11:35PM +0200, martin odersky wrote: > Cduce goes much further than what ...

That's interesting.  I'm going to say we're not disagreeing, because I
wasn't necessarily advocating that we do things like they did, but that
they will have wrestled with similar issues in a sophisticated way.
Even taking as a premise that it's the wrong direction to go, it
warrants study to find out what drove them in that direction and how we
anticipate dealing with the same factors.

> I would not recommend to go there. On the other hand, and much more > modestly, I would hope tha...

I was just talking about that with someone at the scala meeting on
tuesday, the same time I discovered that clojure has an xml zipper.  I
think we should be encouraging a friendly rivalry with the clojurists
and when they have something we don't, they're TAUNTING us! Are you
going to put up with that, Abstract Scala Community?

--
Paul Phillips      | We must respect the other fellow's religion, but only
Everyman           | in the sense and to the extent that we respect his
Empiricist         | theory that his wife is beautiful and his children smart.
pp: i haul pills   |     -- H. L. Mencken