InfoQ talk about Type Providers in F# 3.0

Speaking of inspiration, yes, type providers have inspired us to
introduce macro types: http://scalamacros.org/ (scroll to the macro
types section). Our first macro SIP will most likely only include
macro defs, but later on (and maybe even before the release of 2.10),
we are thinking about coming up with a prototype of macro types and a
corresponding SIP.

On Jan 27, 11:45 am, Simon Ochsenreither
wrote:
> Hi everyone,
>
> for those who haven't seen it yet, there is a great recording about F# Type
> Providers from Strange Loop up on InfoQ:http://www.infoq.com/presentations/The-Future-of-FSharp-Type-Providers
>
> It's a great source of inspiration for Scala and probably _the_ standard to
> which the future Scala database stuff has to be compared.
>
> Bye,
>
> Simon

Hi Eugene!

Yes, of course I know that! :-)

I would be interested in having some detailed overview about the differences between F#'s approach and Scala's approach.

One thing I see is that all macro stuff will eventually generate some class files while it seems that much of the Type Provider stuff can live without that.

How would you compare the overall situation? Which solution is "superior" in your opinion? Do the F# developers have any benefit from being able to adapt the CLR to their needs?

I just hope that Scala will ship with a real-world library to connect to data stores like databases, odata, wsdl, ... instead of just shipping with a compiler flag and telling people "build your own stuff". Imho there is already enough stuff "magic" stuff nobody uses (think scala.Dynamic, scala.DelayedInit).

I would be very thankful to hear your opinion,

Thanks!

Simon

body p { margin-bottom: 0cm; margin-top: 0pt; }

Eugene Burmako wrote:

03c05699-37bf-4acf-b966-c39777aaec9b [at] w4g2000vbc [dot] googlegroups [dot] com" type="cite">

Speaking of inspiration, yes, type providers have inspired us to
introduce macro types: http://scalamacros.org/ (scroll to the macro
types section). Our first macro SIP will most likely only include

traits can have parameters in 2.10 or is this something special for trait macros?

03c05699-37bf-4acf-b966-c39777aaec9b [at] w4g2000vbc [dot] googlegroups [dot] com" type="cite">

macro defs, but later on (and maybe even before the release of 2.10),
we are thinking about coming up with a prototype of macro types and a
corresponding SIP.

On Jan 27, 11:45 am, Simon Ochsenreither
 wrote:

Hi everyone,

for those who haven't seen it yet, there is a great recording about F# Type
Providers from Strange Loop up on InfoQ:http://www.infoq.com/presentations/The-Future-of-FSharp-Type-Providers

It's a great source of inspiration for Scala and probably _the_ standard to
which the future Scala database stuff has to be compared.

Bye,

Simon

This is a hypothetical syntax solely for macro types. The parameter
"connString" signifies that macro accepts a single parameter and uses
it to generate a type during the compile-time. Thus, the parameter
list is not about parameterizing instances of the trait, but rather
about parameterizing the compilation.

On Jan 27, 4:15 pm, Ittay Dror wrote:
> Eugene Burmako wrote:Speaking of inspiration, yes, type providers have inspired us to introduce macro types:http://scalamacros.org/(scroll to the macro types section). Our first macro SIP will most likely only include
> traits can have parameters in 2.10 or is this something special for trait macros?macro defs, but later on (and maybe even before the release of 2.10), we are thinking about coming up with a prototype of macro types and a corresponding SIP. On Jan 27, 11:45 am, Simon Ochsenreitherwrote:Hi everyone, for those who haven't seen it yet, there is a great recording about F# Type Providers from Strange Loop up on InfoQ:http://www.infoq.com/presentations/The-Future-of-FSharp-Type-ProvidersIt's a great source of inspiration for Scala and probably _the_ standard to which the future Scala database stuff has to be compared. Bye, Simon

body p { margin-bottom: 0cm; margin-top: 0pt; }

Then it breaks the illusion that macros create an abstraction that looks like normal defs/traits to client code. It may be confusing for people that use a macro trait and are surprised to see it accepts parameters.

If creating such an abstraction is not a goal, then I'd like to suggest that parameters to macros def/trait reflect their true type (ASTs), and not their caller's abstraction. Otherwise, it is another surprise factor.

Eugene Burmako wrote:

1a6a8dc0-a830-4b34-9058-ca2be753d055 [at] bs8g2000vbb [dot] googlegroups [dot] com" type="cite">

This is a hypothetical syntax solely for macro types. The parameter
"connString" signifies that macro accepts a single parameter and uses
it to generate a type during the compile-time. Thus, the parameter
list is not about parameterizing instances of the trait, but rather
about parameterizing the compilation.

On Jan 27, 4:15 pm, Ittay Dror  wrote:

Eugene Burmako wrote:Speaking of inspiration, yes, type providers have inspired us to introduce macro types:http://scalamacros.org/(scroll to the macro types section). Our first macro SIP will most likely only include
traits can have parameters in 2.10 or is this something special for trait macros?macro defs, but later on (and maybe even before the release of 2.10), we are thinking about coming up with a prototype of macro types and a corresponding SIP. On Jan 27, 11:45 am, Simon Ochsenreitherwrote:Hi everyone, for those who haven't seen it yet, there is a great recording about F# Type Providers from Strange Loop up on InfoQ:http://www.infoq.com/presentations/The-Future-of-FSharp-Type-ProvidersIt's a great source of inspiration for Scala and probably _the_ standard to which the future Scala database stuff has to be compared. Bye, Simon