Subject: Scala metaprogramming? - msg#00038

Previous Message by Date:

Re: Misc Perl 6 features

Raoul Duke wrote: Dunno to what extent Scala is looking for useful ways to do things - e.g. Perl 6's trinary comparison stuff that lets you do "if( 1 < x < 10)" How about, just for fun: implicit def richInt(x : Int) = new RichInt(x) class RichInt(x : Int) { def ~<(y : Int) = new Ternary(x, y) } class Ternary(x : Int, y : Int) { def ~<(z : Int) = x < y && y < z } We can then write 1 ~< 2 ~< 3 => true 2 ~< 3 ~< 0 => false etc. I don't think a more elegant solution (i.e. overloading the "<" operator) is possible without modifying the Scala source. Regards, Jon -- Jon Pretty | Sygneca Ltd.

Next Message by Date:

Re: Scala metaprogramming?

Hello!On 10/11/06, Imam Tashdid ul Alam <uchchwhash@xxxxxxxxx> wrote: well I'm not really sure if this is calledmetaprogramming or not...some of what you describe qualifies as metaprogramming to me. my understading of ClassLoaders is rather trivial. Iwas just wondering if the following is possible todo...Yes it's possible. However, IMHO you really talk about different things here: * having "by-need" tuple and function classesThis is something that could be solved by meta-programming in the compiler, in the way you describe. Whether it is class-loader or reflection that is used is a separate issue. However, it does not necessarily mean a metaprogramming facility is available to all scala programmers (see below) can even make tuples an intrinsic feature of thelanguage. [a little digression on why tuples should not be in the language]As always, every design decision has its pros and cons. I like that the Scala design knows of no tuples. It is the "You have objects, what more do you want?" attitude. A long time ago, we had syntactic support for tuples (one just writes parentheses and commas) and then we dropped it. And that's a good thing: somebody might want to write 'class Person { val name:String, height: Int }' and somebody else use 'Tuple2[String,Int]' and yet somebody else prefers 'case class Person(name:String,height:Int)'. Why should one approach be blessed with being supported in syntax and spec, while the others are not? One might argue that case classes are another feature, but we are actually working on making them less magic (such as to do pattern matching with arbitrary objects in the same way you work on case classes today). but the actual metaprogramming facility should havesomething greater to offer. [general thoughts on metaprogramming facility]Today, we have many ways to do metaprogramming on the JVM, all somehow tedious but they work and many researchers and practitioners are fascinated by it. Look at the techniques used by object-relational mappings, and the possibilities offered by the Reflection API. Making consistent use of the JVMs metaprogramming facilities and providing a 'framework' (I hate this word) or 'method' for doing metaprogramming conveniently and consistently are two very different things. how about *pretending* an XML schema *defines* a typestructure? or a given SQL table structure? the compiler can have autogenerated classes that mimic(very very closely) the actual structure (completelyno boilerplate).Yes this is called "data binding" and people are using metaprogramming to do it (at least for SQL) this should be a great language feature (if you thinkabout it). after all, in a loose sense, isn't that what types are meant to do in general?Types are there to avoid a certain class of easily detectable programming errors, and in the case of class-based object-oriented languages also to provide a way of structuring (and even documenting) programs. I do agree with the following (if that is what you meant): if we can use some method X in order to remve redundant structure (my class type in the program versus the XML type versus the SQL type), that's a Good Thing. The trouble is, we might have to add additional structure to the *programs* ( i.e. by depending on Hibernate).Type-theory has produced many ways to use types for programming (F-omega is my favourite) and for logic, and it is hard to define what types are meant to do in general. this hypothetical *meta*programming facility canprocess the source and produce Scala source output.but I think it makes a lot more sense to just pass theAST to the compiler.Now here you are just listing some options, but a source-to-source transformation is not really metaprogramming, if you can't compile and link those sources at runtime. Or interpret them. is the community interested in doing something likethis? in a way, the LINQ project is way too limited, Scala has the whole thing for free!Maybe read Gilles's mail http://article.gmane.org/gmane.comp.lang.scala/2148/match=staging are there severe limitations that I cannot see? Ireally appreciate implicit defitions these days. when I started I couldn't see the point.by the way, one question of mine remains unanswered.why doesn't Scala compiler infer the type of recursivefunctions? why is it troublesome?I'll let somebody else answer that, probably you should ask this question separately :-) The new version will at least for overriding methods use the return type of the overridee as a prototype so inference will be a bit cleverer. thanks.hail Scala. :)...What can one say to this?Seek ye first the good things of the mind, and the rest will either be supplied or its loss will not be felt. Francis Baconcheers,Burak

Previous Message by Thread:

Misc Perl 6 features

Dunno to what extent Scala is looking for useful ways to do things - e.g. Perl 6's trinary comparison stuff that lets you do "if( 1 < x < 10)" - nor do I know enough about all the corners of Scala to know what it already can do, but reading about Perl 6's features is... interesting, if nothing else. http://www.ddj.com/dept/lightlang/184416233 sincerely.

Next Message by Thread:

Re: Scala metaprogramming?

Hello!On 10/11/06, Imam Tashdid ul Alam <uchchwhash@xxxxxxxxx> wrote: well I'm not really sure if this is calledmetaprogramming or not...some of what you describe qualifies as metaprogramming to me. my understading of ClassLoaders is rather trivial. Iwas just wondering if the following is possible todo...Yes it's possible. However, IMHO you really talk about different things here: * having "by-need" tuple and function classesThis is something that could be solved by meta-programming in the compiler, in the way you describe. Whether it is class-loader or reflection that is used is a separate issue. However, it does not necessarily mean a metaprogramming facility is available to all scala programmers (see below) can even make tuples an intrinsic feature of thelanguage. [a little digression on why tuples should not be in the language]As always, every design decision has its pros and cons. I like that the Scala design knows of no tuples. It is the "You have objects, what more do you want?" attitude. A long time ago, we had syntactic support for tuples (one just writes parentheses and commas) and then we dropped it. And that's a good thing: somebody might want to write 'class Person { val name:String, height: Int }' and somebody else use 'Tuple2[String,Int]' and yet somebody else prefers 'case class Person(name:String,height:Int)'. Why should one approach be blessed with being supported in syntax and spec, while the others are not? One might argue that case classes are another feature, but we are actually working on making them less magic (such as to do pattern matching with arbitrary objects in the same way you work on case classes today). but the actual metaprogramming facility should havesomething greater to offer. [general thoughts on metaprogramming facility]Today, we have many ways to do metaprogramming on the JVM, all somehow tedious but they work and many researchers and practitioners are fascinated by it. Look at the techniques used by object-relational mappings, and the possibilities offered by the Reflection API. Making consistent use of the JVMs metaprogramming facilities and providing a 'framework' (I hate this word) or 'method' for doing metaprogramming conveniently and consistently are two very different things. how about *pretending* an XML schema *defines* a typestructure? or a given SQL table structure? the compiler can have autogenerated classes that mimic(very very closely) the actual structure (completelyno boilerplate).Yes this is called "data binding" and people are using metaprogramming to do it (at least for SQL) this should be a great language feature (if you thinkabout it). after all, in a loose sense, isn't that what types are meant to do in general?Types are there to avoid a certain class of easily detectable programming errors, and in the case of class-based object-oriented languages also to provide a way of structuring (and even documenting) programs. I do agree with the following (if that is what you meant): if we can use some method X in order to remve redundant structure (my class type in the program versus the XML type versus the SQL type), that's a Good Thing. The trouble is, we might have to add additional structure to the *programs* ( i.e. by depending on Hibernate).Type-theory has produced many ways to use types for programming (F-omega is my favourite) and for logic, and it is hard to define what types are meant to do in general. this hypothetical *meta*programming facility canprocess the source and produce Scala source output.but I think it makes a lot more sense to just pass theAST to the compiler.Now here you are just listing some options, but a source-to-source transformation is not really metaprogramming, if you can't compile and link those sources at runtime. Or interpret them. is the community interested in doing something likethis? in a way, the LINQ project is way too limited, Scala has the whole thing for free!Maybe read Gilles's mail http://article.gmane.org/gmane.comp.lang.scala/2148/match=staging are there severe limitations that I cannot see? Ireally appreciate implicit defitions these days. when I started I couldn't see the point.by the way, one question of mine remains unanswered.why doesn't Scala compiler infer the type of recursivefunctions? why is it troublesome?I'll let somebody else answer that, probably you should ask this question separately :-) The new version will at least for overriding methods use the return type of the overridee as a prototype so inference will be a bit cleverer. thanks.hail Scala. :)...What can one say to this?Seek ye first the good things of the mind, and the rest will either be supplied or its loss will not be felt. Francis Baconcheers,Burak