gmane.comp.lang.fortress.general

Professional Grant Proposal Writing Workshop (August 2008: Philadelphia, Pennsylvania - University of Phoenix Campus)

Anthony Jones — 2008-08-06T05:50:10

Static parameters for functional methods

Sorin Miklós Zsejki — 2008-07-23T22:58:36

Is this a bug? This code: component Sample export Executable trait X m[\T extends X\](self): T end run(args) = () end gives a "Missing type T" error. In fact, wherever I use T, for example as the type of a parameter, I get the same error, but it works if it's a regular method. I am almost sure I could do this some time ago.

Re: Is "typecase self of" a syntax error?

Sorin Miklós Zsejki — 2008-07-21T17:48:34

Thank you for the explanation. This was my initial understanding. So this was the intended behavior, but only for the current interpreter. On Mon, Jul 21, 2008 at 8:17 PM, Victor Luchangco public.gmane.org> wrote:

Re: Is "typecase self of" a syntax error?

Victor Luchangco — 2008-07-21T17:17:10

Athough you can achieve this in the current implementation, which dynamically infers elided static arguments, this will *not* work when static type inference is implemented. (See note at the beginning of F1.0, Chapter 18.) To understand what will happen under static type inference, I think it's helpful to imagine the code with the elided types written explicitly. In that case, the declarations for f would be: f(p: P): O[\P\] = O[\P\](p) f(p: SubP): SubO[\SubP\] = SubO[\SubP\](p) Thus, the calls to f(Po()) and f(SubPo()) evaluate to values with dynamic types O[\P\] and SubO[\SubP\] respectively. Since O[\P\] is not a subtype of O[\Po\] and SubO[\SubP\] is not a subtype of SubO [\SubPo\], the program under static type inference will print "something else" twice. To get what you want, I think you need the static parameters for f, as in your earlier thread ("How to overload a function with static parameters", from May 30). You can use Jan's suggestion from then: f[\T extends P\

Re: Is "typecase self of" a syntax error?

Sorin Miklós Zsejki — 2008-07-18T21:25:16

This is great. Some threads ago (the subject was: "How to "overload a function with static parameters"?") I wanted to achieve something, and I've realized from this response that I can: component Sample.Main export Executable trait P end trait R[\T extends P\] end f(p: P) = O(p) trait SubP extends P end trait SubR[\T extends SubP\] extends R[\T\] end f(p: SubP) = SubO(p) object O[\T extends P\](p: T) extends R[\T\] end object SubO[\T extends SubP\](p: T) extends SubR[\T\] end object Po() extends P end object SubPo() extends SubP end run(args): () = do typecase _ = f(Po()) of (* I now use the right syntax here ;) *) O[\Po\] => println "O[\\Po\\]" else => println "something else" end typecase _ = f(SubPo()) of SubO[\SubPo\] => println "O[\\SubPo\\]" else => println "something else" end end end which prints: [java] O[\Po\] [java] O[\SubPo\] This code is probably more complicated than needed, but the idea is simple. Basically, I don't need stat

Re: Is "typecase self of" a syntax error?

Guy Steele — 2008-07-18T18:35:30

On Jul 18, 2008, at 1:23 PM, Sorin Miklós Zsejki wrote: This is the intended behavior, but remember that Fortress, unlike Java, does //dynamic// dispatch on all arguments. The static type of "self" is relevant to deciding which method signatures are applicable, but then at run time a dynamic dispatch is performed to select the most specific applicable overloading. So you get "f(O)". --Guy Steele

Re: Is "typecase self of" a syntax error?

Sorin Miklós Zsejki — 2008-07-18T17:23:59

With all this discussion, I realize I don't understand what the static type of self is. So I tried this: trait T m() = f(self) end object O extends T end f(t: T) = println "f(T)" f(o: O) = println "f(O)" run(args): () = O.m() and it prints "f(O)". Is this the intended behavior? That is, self has static type O, not T, in this case?

Re: Is "typecase self of" a syntax error?

Victor Luchangco — 2008-07-18T16:07:13

Yup. I've never yet been so tempted. :-) The only reason I can think that you might want to do this to if the typecase is a (small) part of a larger body, and doesn't correspond to another method (especially if the subtraits may be defined in different components). Something like: trait T m() = do (* lots of stuff here *) typecase self of U => u() V => v() else => () (* do nothing *) end (* more stuff *) end trait U extends T u() = ... end trait V extends T v() = ... end - Victor

Re: Is "typecase self of" a syntax error?

Sorin Miklós Zsejki — 2008-07-18T15:38:25

Good point. But as I said in a previous message, I was thinking what if T had many such methods and it would become practical to give a default implementation to most of them, so that creating a U or a V would not require very much boilerplate. On Fri, Jul 18, 2008 at 6:07 PM, Eric Allen public.gmane.org> wrote:

Re: Is "typecase self of" a syntax error?

Eric Allen — 2008-07-18T15:07:05

On Jul 17, 2008, at 9:57 PM, Victor Luchangco wrote: Good point. Of course, in many cases this approach won't apply, because we are often interested in treating self with a more precise static type in subtraits. Note that the particular toy example: can be simply replaced with the expression "T". BTW, whenever tempted to do a typecase on self, consider using an abstract helper method that is overridden in subtraits. For example, instead of writing this: trait T m() = typecase myself = self of U => "U" V => "V" end end trait U extends T end trait V extends T end consider writing this: trait T m() = typeTag() typeTag(): String end trait U extends T typeTag() = "U" end trait V extends T typeTag() = "V" end This approach has the advantage that you can add new subtraits to T without having to modify the definition of T. I agree.

Re: Is "typecase self of" a syntax error?

Sorin Miklós Zsejki — 2008-07-18T11:11:45

On Fri, Jul 18, 2008 at 5:27 AM, Jan-Willem Maessen public.gmane.org> wrote: I agree. I stumbled upon this because I tried to imagine how it would look like to have a trait like this: trait HasSelf[\Self extends HasSelf[\Self\]\] myself(): Self = typecase s = self of Self => s else => throw SomeException() end end and then myself() could be used for default implementations of some methods in some traits that extend HasSelf, are extended themselves and have a Self parameter passed to them. But so far I didn't find a use for this and frankly I hate this pattern (passing subtypes as static parameters) because it makes the code look messy.

Re: Is "typecase self of" a syntax error?

Victor Luchangco — 2008-07-18T02:57:17

On Jul 17, 2008, at 9:27 PM, Sukyoung Ryu wrote: In case you don't want to bind a new variable, you could always write typecase _ = self of ... We don't allow arbitrary expressions in place of a binding because we can't guarantee that a reevaluation of the expression will produce something of the same type. That said, perhaps we should allow "typecase self of ..." since self is like an immutable variable, except that it is implicitly bound by every method declaration. - Victor

Re: Is "typecase self of" a syntax error?

Sorin Miklós Zsejki — 2008-07-18T02:32:48

Hi Sukyoung, thanks for the answers. I now realize I've read that part of the spec only superficially. On Fri, Jul 18, 2008 at 4:27 AM, Sukyoung Ryu public.gmane.org> wrote:

Re: Is "typecase self of" a syntax error?

Jan-Willem Maessen — 2008-07-18T02:27:49

On Jul 17, 2008, at 9:27 PM, Sukyoung Ryu wrote: To bring things up to the meta-level for a moment, is there any reason that "self" should not be considered just another immutable variable in scope for this purpose? Admittedly, I would tend to solve problems that want "typecase self" using overriding instead. Speaking of which, give a shout when the error messages are bad. We'll see what we can do. A bunch of new static checks are being added and the error messages aren't necessarily friendly yet (for that matter, the checks we *were* doing weren't always friendly either). -Jan

Re: Is "typecase self of" a syntax error?

Sukyoung Ryu — 2008-07-18T01:27:58

Hi Sorin, On Jul 16, 2008, at 1:50 PM, Sorin Miklós Zsejki wrote: It is indeed a syntax error. A typecase expression is expected to have a binding such as "x = self" or "(x, y, z) = triple". In addition, Fortress provides a syntactic sugar "typecase x of ..." for "typecase x = x of ..." when the identifier "x" is an immutable variable in scope. Revision 2301 added a slightly friendlier syntax error message for this case. It is an obsolete option used in the fortress script. Revision 2300 deleted it. Thanks, -- Sukyoung

Is "typecase self of" a syntax error?

Sorin Miklós Zsejki — 2008-07-16T17:50:14

If I have: component Main export Executable trait T m() = typecase self of T => "T" else => "else" end end run(args) = () end I get "/path.../Main.fss:5:24: Syntax Error". Is it an error? If I have "typecase s = self of" instead, I don't get the error message. Unrelated to this, I've seen I pass "-Dfortress.static.analysis=1" when I call fortress. Probably this was documented sometime somewhere. Does this still have an effect? If so, does it have the same effect as running typecheck before?

Re: Implementation of Red-Black Trees

Damon McCormick — 2008-07-08T08:48:22

If you are not already familiar with it, you might want to look at Sedgewick's recent work on Left-Leaning Red Black Trees. http://www.cs.princeton.edu/~rs/talks/LLRB/RedBlack.pdf -Damon On Sat, Jul 5, 2008 at 1:16 AM, Michael Lesniak public.gmane.org> wrote:

Re: Parallel vs. sequential loops

Doug Lea — 2008-07-08T00:30:10

There are several pitfalls to avoid in generating parallel computation, and this is certainly one of them, but as one of the people working in the basement (the underlying fork/join engine) I think the effects are short of "catastrophic", and are likely to be manageable. For example, here's a table of run times for the standard parallel recursive Fibonacci program under different sequential thresholds. The threshold is the fib argument value at which point you choose sequential over parallel computation. This table is for fib(42) running on a T2 Niagara with 64 threads. ST=42 runs purely sequentially. ST=2 is the smallest possible value (0 and 1 are base cases). ST time (sec) 42 14.770 40: 5.644 38: 2.160 36: 0.912 34: 0.516 32: 0.507 30: 0.440 28: 0.420 26: 0.410 24: 0.408 22: 0.407 20: 0.407 18: 0.410 16: 0.412 14: 0.417 12: 0.435 10: 0.466 8: 0.593 6: 0.834 4: 1.479 2: 3.366 The U-shaped curve with a wide shallow middle and ste

Re: Parallel vs. sequential loops

Sorin Miklós Zsejki — 2008-07-07T17:26:45

I am definitely not the best person to answer this and I have little experience here, but I think that if you read the documentation about Generator, you can understand that this is exactly what Fortress does: they have a different implementation for sparse data structures, a different one for "regular" arrays, and anyone can implement their own, no matter how specific it is. Each implementation can choose exactly how it wants to split to threads or be completely serial, and seq(generator) should always be serial, when you need it. This seems an interesting proposal: as far as I can tell, generators optimize based on the data structure that gets iterated over; why not also optimize based on the body of the "for"? So F# doesn't have such optimizations already built into the language/libraries.

Re: Parallel vs. sequential loops

Jon Harrop — 2008-07-07T16:36:19

I don't understand what you mean by this. Are you saying that the subdivision tries to improve locality of reference to the elements of "a" in order to optimize cache coherence? So you are assuming that the element type of the array is a value type? What happens if the element type is a reference type (e.g. an array of big ints) or if the array "a" is sparse? The catastrophic performance loss I was referring to occurs when the spawning of parallel computations becomes the bottleneck. This is "catastrophic" because the cost of queuing a work item is orders of magnitude larger than the cost of a primitive operation (e.g. int addition). This pitfall must be avoided at all costs. The naive parallel "for" loop we are discussing has no idea what the complexity of the body of the loop is, so its options are very limited. It might spawn a parallel computation for every iteration of the loop, in which case a trivial loop body (e.g. vector dot product) will certainly suffer the catastrophic performanc

Re: Parallel vs. sequential loops

Jon Harrop — 2008-07-07T01:04:44

I don't believe so. For example, this is an issue we fixed in our products some time ago.