Scala vs Fan

[Christos KK Loverdos]

On Wed, Jul 9, 2008 at 12:02 AM, Adriaan Moors <adriaan.moors@...> wrote:

On 08 Jul 2008, at 22:32, Christos KK Loverdos wrote:

I'm not sure I can conceptualize a language that lets me have my cake and eat it, too.  At one point I want the compiler to stay out of my way, because I know full well I'm wrong about a bunch of details, and on the other side I want the compiler to do all sorts of amazing checking of those details because I want them to all be correct.

So in a nutshell I'm saying that sometimes I want to write incorrect code, and Scala gets in my way of doing that.  But that's OK, because I still have Python for doing that.


Hhhmm... you have just generated the idea of the -loosetypes command-line switch to the scalac executable ;-)

well, many researchers are thinking about this, it just hasn't matured to the point of -- say -- higher-kinded types ;-)

<unstructured braindump, it's scala-debate after all! ;-)>
see Meijer's paper on static typing when possible, dynamic typing when necessary, or Bracha's work on pluggable type systems.

Yep, it is scala-debate!

I had read Bracha's paper, it seemed so obvious...and to be totally honest, I was not impressed much, partly because I had thoughts in the same lines before that...

 I can't say about the other paper, I will have to read (and understand! it).
 

others that spring to mind are Siek, and Flanagan, who call it "hybrid typing" or "gradual typing". Heck, even Wadler (notorious proponent of static typing) is thinking about it (in a way that I still don't fully understand -- as in seeing the bigger picture behind his ideas): see his paper on well typed papers can't be blamed (a pun on Milner's original slogan wrt type soundness)
</braindump -- not even well-formed xml :-p>

Now, Wadler's slides are so much fun! (not "fan")
 
Interesting pointers Andriaan!

Thanx

Christos

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

[Christos KK Loverdos]

No, not Wadler, Pierce's slides are what I meant! (bad memory...) I came across them recently and I  too recommend them...

On Wed, Jul 9, 2008 at 12:15 AM, James Iry <jamesiry@...> wrote:

See also "Types Considered Harmful" (http://www.cis.upenn.edu/~bcpierce/papers/harmful-mfps.pdf) by Benjamin Pierce of "Types and Programming Languages" fame.  The paper is not so much about hybrid or gradual typing.  Instead he talks about using contract systems to supplement type systems at the point where types move beyond your type system's abilities.

On Tue, Jul 8, 2008 at 2:02 PM, Adriaan Moors <adriaan.moors@...> wrote:

<unstructured braindump, it's scala-debate after all! ;-)>
see Meijer's paper on static typing when possible, dynamic typing when necessary, or Bracha's work on pluggable type systems.
others that spring to mind are Siek, and Flanagan, who call it "hybrid typing" or "gradual typing". Heck, even Wadler (notorious proponent of static typing) is thinking about it (in a way that I still don't fully understand -- as in seeing the bigger picture behind his ideas): see his paper on well typed papers can't be blamed (a pun on Milner's original slogan wrt type soundness)
</braindump -- not even well-formed xml :-p>


hth
adriaan

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

[Meredith Gregory]

Christos, et al,

+1 on Ben's slides. i'm totally unconvinced about lenses as a programming paradigm, but as a device to explore language+type theoretic approach to design problems it is about as perfect as you can hope for. And, his slides are masterful.

Best wishes,

--greg

On Tue, Jul 8, 2008 at 2:22 PM, Christos KK Loverdos <loverdos@...> wrote:

No, not Wadler, Pierce's slides are what I meant! (bad memory...) I came across them recently and I  too recommend them...

On Wed, Jul 9, 2008 at 12:15 AM, James Iry <jamesiry@...> wrote:

See also "Types Considered Harmful" (http://www.cis.upenn.edu/~bcpierce/papers/harmful-mfps.pdf) by Benjamin Pierce of "Types and Programming Languages" fame.  The paper is not so much about hybrid or gradual typing.  Instead he talks about using contract systems to supplement type systems at the point where types move beyond your type system's abilities.

On Tue, Jul 8, 2008 at 2:02 PM, Adriaan Moors <adriaan.moors@...> wrote:

<unstructured braindump, it's scala-debate after all! ;-)>
see Meijer's paper on static typing when possible, dynamic typing when necessary, or Bracha's work on pluggable type systems.
others that spring to mind are Siek, and Flanagan, who call it "hybrid typing" or "gradual typing". Heck, even Wadler (notorious proponent of static typing) is thinking about it (in a way that I still don't fully understand -- as in seeing the bigger picture behind his ideas): see his paper on well typed papers can't be blamed (a pun on Milner's original slogan wrt type soundness)
</braindump -- not even well-formed xml :-p>


hth
adriaan

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

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

[Ricky Clarkson]

"What a change of heart from you Ricky!"

I think there's value in dynamic languages.  They seem great for new programmers to learn in, and they let you ride roughshod over quality, which sometimes you're ok with.  For instance, I wrote a little elisp today that lets me hibernate my computer without leaving emacs, and I didn't have to consider what the type of Windows' shutdown /h command is, or what emacs' shell-command procedure returns (or in this case, even whether it runs synchronously or asynchronously).

Also, as Wadler has mentioned, even good typesystems sometimes don't support features that let your known-good code typecheck, so you'd want to step out of them sometimes.

When I started looking at Haskell after learning enough Lisp to be dangerous, I tried porting (lambda (f x) (f f x)), a primitive combinator useful for writing recursive lambdas, to Haskell and found it impossible.  A year on, I still can't understand Cale Gibbard's explanation of the port of that to Haskell, though I can understand why it doesn't type-check.

Dynamic languages are also great breeding grounds for syntax - a good challenge for static languages is to provide as 'natural' syntax as dynamic languages while still promoting correctness.

But on the other hand, a language without static types is only half a language - like how cars tend to go faster on roads than through fields, programmers can work at a higher level of abstraction when programming with types.  The better the typesystem, the faster the cars.  Broken analogy alert.

Ultimately, the syntax for a static language can be better than a dynamic language, because there is more information around.  E.g., consider how QuickCheck in Haskell gets given the Arbitrary instances by the environment, based on the type of the function passed to check.  (my terminology may be askew here)

..Then there's the people who don't know what static typing is.  Groovy's homepage says it supports static typing, yet int i="hello" compiles (and fails at runtime) in Groovy.  [snipped rant about Groovy]

2008/7/8 Tony Morris <tmorris@...>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ricky Clarkson wrote:
> You seem to say "less rigorous typing" as if it might possibly be
> an advantage.
>

That's what I was thinking, if only to myself :) What a change of
heart from you Ricky!

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIc8ldmnpgrYe6r60RAhtIAKDFzN0cz7wZJ/MjqWZa3KM5KTfwqgCgs7nN
LQ4WU00f8WHZ1a6p5oGNPfA=
=jRmX
-----END PGP SIGNATURE-----

[jherber]

Christos KK Loverdos wrote:

Hhhmm... you have just generated the idea of the -loosetypes command-line
switch to the scalac executable ;-)

I would love to see a representation of a loose-typed? or dynamically typed scala-like scripting language.  It should be very similar to Scala, but with no hand-waving for types.  This would be a faster way to create scripts and small prototypes.  The language should be similar enough that it can be refactored into pure Scala for type-safety and speed.

[Andrew.Foggin]

jherber wrote:
> I would love to see a representation of a loose-typed? or dynamically typed
> scala-like scripting language.  It should be very similar to Scala, but with
> no hand-waving for types.  This would be a faster way to create scripts and
> small prototypes.  The language should be similar enough that it can be
> refactored into pure Scala for type-safety and speed.
>
>
>  
True story:

A few years ago (early days of Groovy) during an infatuation with
dynamic languages I became frustrated with Groovy's syntax
inconsistencies and sought to design something better.  Coming across
Scala I decided that its syntax would make a much better basis for a
scripting language - it had already solved many of the issues that
plagued Groovy at the time (and for all I know still do).  I even went
so far as to write a simple interpreter that could script Java objects
using a Scala-like expression syntax that included named and anonymous
functions. (I didn't know about parser combinators then so it was
painfully coded by hand).

Thing is, the more about Scala I learned and the better I understood it,
the less I wanted a dynamic language and the more I wanted Scala
itself.  So I switched my (spare-time) focus from dynamic languages to
Scala and have not looked back.  At least for the sort of programming I
like to do: Scala (including it's type system) is the best available
tool for the job.

--Andrew

P.S. I now realize that what drew me to the dynamic languages I was
learning were features of Functional Programming that were absent from
Java (my day-job language for most of the last decade), not dynamic
languages per se.

[Ingo Maier-2]

Erik Engbrecht wrote:
> I think it does have an advantage in some situations.  One of my
> personal struggling points with Scala (and to a lesser extent Java, C++,
> and pretty much all other statically typed languages) is that expressing
> partially formed ideas is much harder.  The Scala compiler likes to
> point out too many of my errors, when I just want to see if it
> "generally seems to work" before putting all the additional effort in to
> make the code correct.  This is particularly painful when I need to
> abstract over types.

I heard this argument before, but I don't quite understand it. Could you
provide an example that would illustrate your approach? What do you mean
with "generally seems to work" in this context?

Thank you,
Ingo

[Rob Dickens-2]

Thanks for all the responses.

So one differentiator in Scala's favour appears to be its rigorous type-parameterisation (generics) support.

But no comments on Fan's build and deployment-related features (which I thought most interesting).

One feature I didn't mention, which it sounds like many who responded might value, is Fan's 'concession'[1] to those who want the option of doing dynamic programming:

When you access a field or method using the "." dot operator the compiler does type checking. But you can also use the "->" dynamic call operator to skip type checking... The "->" operator is really just syntax sugar for invoking the Obj.trap method which by default uses reflection to call a method or access a field. But you can also override the trap method to handle dynamic calls in imaginative ways.

1 http://www.fandev.org/doc/docIntro/Tour.html#dynamic

On Tue, Jul 8, 2008 at 3:11 PM, Rob Dickens <arctic.bob@...> wrote:

Dear list,

I read a blog entry[1] this morning, about an interesting-sounding[2] new language. Like Scala, it has static typing with type inference, first-class functions, operators as methods, mix-ins and 'Erlang-style concurrency'. Unlike Scala, it 'compiles into fcode - a bytecode representation that can be translated into both Java bytecode and IL easily. This translation is typically done at runtime, which enables you to deploy Fan modules as a single file and have them run on either VM.'

Of particular interest (I thought) is the following combination of features:

* top-level name-space modules (pods) correspond to actual deployment modules (zip files)

* support for declaring instances of classes in serialised form using a subset of the language (rather than XML)

* built-in build engine (rather than using Ant or Maven).

So I was just wondering what anyone thought about this.

Cheers,

Rob

1 http://www.ajaxonomy.com/2008/java/not-a-fan-of-scala-an-evolutionary-approach

2 http://www.fandev.org/doc/docIntro/WhyFan.html

[Viktor Klang]

Greetings Rob,

since I mostly work on web-related software, I already have a "pod", the WAR.

I never was too keen on Java as a platform for standalone apps...

Cheers,
Viktor

On Wed, Jul 9, 2008 at 11:28 AM, Rob Dickens <arctic.bob@...> wrote:

Thanks for all the responses.

So one differentiator in Scala's favour appears to be its rigorous type-parameterisation (generics) support.

But no comments on Fan's build and deployment-related features (which I thought most interesting).

One feature I didn't mention, which it sounds like many who responded might value, is Fan's 'concession'[1] to those who want the option of doing dynamic programming:

When you access a field or method using the "." dot operator the compiler does type checking. But you can also use the "->" dynamic call operator to skip type checking... The "->" operator is really just syntax sugar for invoking the Obj.trap method which by default uses reflection to call a method or access a field. But you can also override the trap method to handle dynamic calls in imaginative ways.

1 http://www.fandev.org/doc/docIntro/Tour.html#dynamic

On Tue, Jul 8, 2008 at 3:11 PM, Rob Dickens <arctic.bob@...> wrote:

Dear list,

I read a blog entry[1] this morning, about an interesting-sounding[2] new language. Like Scala, it has static typing with type inference, first-class functions, operators as methods, mix-ins and 'Erlang-style concurrency'. Unlike Scala, it 'compiles into fcode - a bytecode representation that can be translated into both Java bytecode and IL easily. This translation is typically done at runtime, which enables you to deploy Fan modules as a single file and have them run on either VM.'

Of particular interest (I thought) is the following combination of features:

* top-level name-space modules (pods) correspond to actual deployment modules (zip files)

* support for declaring instances of classes in serialised form using a subset of the language (rather than XML)

* built-in build engine (rather than using Ant or Maven).

So I was just wondering what anyone thought about this.

Cheers,

Rob

1 http://www.ajaxonomy.com/2008/java/not-a-fan-of-scala-an-evolutionary-approach

2 http://www.fandev.org/doc/docIntro/WhyFan.html

--
Viktor Klang
Rogue Software Architect

[pstickne]

>> When you access a field or method using the "." dot operator the compiler
>> does type checking. But you can also use the "->" dynamic call operator to
>> skip type checking... The "->" operator is really just syntax sugar for
>> invoking the Obj.trap method which by default uses reflection to call a
>> method or access a field. But you can also override the trap method to
>> handle dynamic calls in imaginative ways.

Or, one could just use structural typing ... (and still get
contractual type-checking?)

At least, wrt ->.
It would be nice to have [easy] library support to do the latter...
raw Java reflection isn't much fun to play with.

[David Hall-11]

On Sun, Jul 27, 2008 at 12:15 PM, Paul Stickney <pstickne@...> wrote:
>>> When you access a field or method using the "." dot operator the compiler
>>> does type checking. But you can also use the "->" dynamic call operator to
>>> skip type checking... The "->" operator is really just syntax sugar for
>>> invoking the Obj.trap method which by default uses reflection to call a
>>> method or access a field. But you can also override the trap method to
>>> handle dynamic calls in imaginative ways.
>
> Or, one could just use structural typing ... (and still get
> contractual type-checking?)

It would be really nice to have a way to tell Scala to infer the
structural type, as in OCaml, but you'd have to ask for it. If it
didn't look so much like line noise, I'd suggest

def foo( x : { _ }) = {

}

or something?

-- David

[Eric Torreborre]

> P.S. I now realize that what drew me to the dynamic languages I was
> learning were features of Functional Programming that were absent from
> Java (my day-job language for most of the last decade), not dynamic
> languages per se.

Funny, I have had the exact same experience! I wonder how many of us do.

[David Ford]

> Genericity enables two-level type solutions.
What is a "two-level type" solutions

> i've demonstrated repeatedly that
> features like reflection come for free
> from two-level type-based solutions.
Where can i find this?

[Meredith Gregory]

David,

That's ironic. i was just working on a solution to the challenge Martin issued based on a problem given by Corky M. regarding scalable abstractions for a lambda calculus evaluator. i'm using a two-level-type based solution.

One way to approach two-level type analysis is via grammars. If you think of a type specification as essentially analogous to the specification of a grammar then two-level types treat every non-terminal as a type parameter in a parametric specification of a data type. An example might help.

Here's a scala specification for Conway games.

trait Games {
   case class Game( left : List[Game], right : List[Game] )
}

This can be seen as approximately equivalent to

Game ::= ( Game*, Game* )

Now, we using the two-level approach, we can rewrite the above grammar as

ParametricGame[G] ::= ( G*, G* )
RGame ::= ParametricGame[RGame]

or in scala

trait ParametricGames {
   type G
   case class Game( left : List[G], right : List[G] )
}

object Games extends ParametricGames {
   type G = Game

}

Best wishes,

--greg

On Sun, May 3, 2009 at 8:07 PM, David Ford <dford@...> wrote:

> Genericity enables two-level type solutions.

What is a "two-level type" solutions

> i've demonstrated repeatedly that
> features like reflection come for free
> from two-level type-based solutions.

Where can i find this?
--
View this message in context: http://www.nabble.com/Scala-vs-Fan-tp18340193p23362416.html

Sent from the Scala - Debate mailing list archive at Nabble.com.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Meredith Gregory]

David,

gmail misinterpreted my keystrokes and that went out uncompleted. Here's the rest.

object Games extends ParametricGames {
   type G = Game
   val Zero : G = Game( Nil, Nil )
}

This gets more interesting when you have a language that has variables/names as a core component, as you find in the lambda calculus or the π-calculus. Here's a simple variant of the π-calculus.

P[N] ::= 0
             N?(N*)P[N]
             N!(P[N]*)
             *N
             P[N] | P[N]

N[P] ::= @P

In scala we would write

trait Processes {
   type Nominal
   abstract class Process
   case class Termination
   case class Input( subject : Nominal, objekts : List[Nominal], continuation : Process )
   case class Output( subject : Nominal, objekt : List[Process] )
   case class Dereference( subject : Nominal )
   case class ParallelComposition( components : List[Process] ) // n-ary instead of binary version
}

trait Names {
   type Agent
   case class Transcription( agent : Agent )
}

object ReflectiveProcess extends Processes with Names {
    type Nominal = Transcription
    type Agent = Process
    val Zero : Process = Termination
}

To see that this is reflective notice that we have a way to turn code into data (Transcription) and a way to turn such data back into code (Dereference).

In 2005 at ETAPS i described the details of this version of the π-calculus and it's corresponding Hennessey-Milner logic. You can find the details here and here. i have also recently written a blog entry about how this version supports a truly remarkable comm rule.

Please note that -- while this particular variant of the π-calculus is interesting in its own right --

• the method of two-level types completely independent
• the method of using two-level types to introduce a particular kind of reflection is also independent

i discovered both of these techniques on my own (by factoring the ingredients that went into constructing the reflective version of the π-calculus), but later discovered that they had been discovered in the functional community a little prior to when i discovered them. Two-level types also goes under the moniker, tying/untying the recursive knot. You can see here some Haskell code providing a technical exegesis of this discussion of how i use these techniques to inject rich data types (such as Conway Games) with expression languages.

Best wishes,

--greg

On Sun, May 3, 2009 at 10:28 PM, Meredith Gregory <lgreg.meredith@...> wrote:

David,

That's ironic. i was just working on a solution to the challenge Martin issued based on a problem given by Corky M. regarding scalable abstractions for a lambda calculus evaluator. i'm using a two-level-type based solution.

One way to approach two-level type analysis is via grammars. If you think of a type specification as essentially analogous to the specification of a grammar then two-level types treat every non-terminal as a type parameter in a parametric specification of a data type. An example might help.

Here's a scala specification for Conway games.

trait Games {
   case class Game( left : List[Game], right : List[Game] )
}

This can be seen as approximately equivalent to

Game ::= ( Game*, Game* )

Now, we using the two-level approach, we can rewrite the above grammar as

ParametricGame[G] ::= ( G*, G* )
RGame ::= ParametricGame[RGame]

or in scala

trait ParametricGames {
   type G
   case class Game( left : List[G], right : List[G] )
}

object Games extends ParametricGames {
   type G = Game

}

Best wishes,

--greg

On Sun, May 3, 2009 at 8:07 PM, David Ford <dford@...> wrote:

> Genericity enables two-level type solutions.

What is a "two-level type" solutions

> i've demonstrated repeatedly that
> features like reflection come for free
> from two-level type-based solutions.

Where can i find this?
--
View this message in context: http://www.nabble.com/Scala-vs-Fan-tp18340193p23362416.html

Sent from the Scala - Debate mailing list archive at Nabble.com.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC

1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com