gmane.comp.lang.fortress.general

Is there a problem?

Russel Winder — 2008-08-30T06:56:04

For the last few days I have been unable to build Fortress. Has there been a change to the way things have to be built or is it just that there is an error in the source? BTW is there a CI server? |> ( cd Subversion/Fortress_Trunk/ && ./ant clean compile ) Buildfile: build.xml clean: cleanCache: [delete] Deleting directory /home/Checkouts/Subversion/Fortress_Trunk/default_repository/caches clean: [delete] Deleting directory /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build [delete] Deleting directory /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/nodes [delete] Deleting directory /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/junit-results [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/preparser/PreFortress.java [delete] Deleting: /home/Checkouts/Subve

Abwesenheitsnachricht

2008-08-29T02:00:46

Ich werde ab 28.08.2008 nicht im Büro sein. Ich kehre zurück am 08.09.2008. In dringende Fällen senden Sie Ihre Nachricht an iuk-K6Ck2cH0joNmeKtsT5rLx1NpE/a5I+DW< at >public.gmane.org oder wenden Sie sich an den Helpdesk, Tel. 07461/926-3000

Proposal to tweak | | syntax

Guy Steele — 2008-08-28T20:36:25

In observing how the "absolute-value" notation is used in practice to refer to the size of a string or a list (thank you, Andrew Black and Steve Heller for walking me through some of your code), I have noticed that certain very plausible expressions are awkward to write in Fortress because of our current rules for deciding whether any given occurrence of "|" is a left encloser, a right encloser, or an infix operator. For example, 0#|a| works but |a|#|b| does not. It is also awkward to make | |a| - |b| | work; one must use parentheses inside the outer absolute value brackets: |(|a| - |b|)| which looks terrible. I propose to tweak the rules given in Fortress spec Figure 16.2 Operator Fixity (II) as follows. Here is the existing table: and here is the proposed modification: The asterisks indicate places that have changed. The first and most important change is to the case "primary|OPERATOR" with no whitespace, to make it interpret the "|" as a right encloser rather than an infix operator

What should the arguments to Fcn.apply() be?

Sorin Miklós Zsejki — 2008-08-26T21:48:53

I am calling a Fortress function from a NativeMeth1.act(), but I don't know what HasAt and Environment to pass to Fcn.apply(). Now I just put nulls and it works, which I doubted before I just tried (especially about Environment). I would be grateful if anyone has a little time to discuss this a little bit. By the way, getters/setters rock!

ไม่ต้องประชุมไม่ต้องขายให้คอมพิวเตอร์หาเงินให้ท่านเดือนละครึ่งแสน

pornphol — 2008-08-22T10:18:02

ถูกที่ถูกเวลาถูกระบบถูกทีมงานสำเร็จแน่ออนไลน์100% “ คนที่ร่ำรวยที่สุดในโลก แสวงหาการสร้างเครือข่าย” งานประจำ ไม่ทำให้ร่ำรวย มีแต่หนี้ ถ้าต้องการความสำเร็จ ต้องเป็นเจ้าของธุรกิจ ลงทุนน้อย สร้างรายได้มหาศาล ไม่ต้องประชุมไม่ต้องขายต่อสายงานให้อัตโนมัติ มีเวปไซด์ภาษาไทยให้ฟรี มีโปรแกรมที่ทำให้คอมพิวเตอร์โปรโมทงานให้ท่านโดยที่ไม่ต้องเฝ้าหน้าจอ ฟรี 087-8054646 พ

Miễn phí tặng bạn 7 website!

WebHosting — 2008-08-21T09:51:08

Conflicting overloadings in an evolving trait hierarchy

Andrew P. Black — 2008-08-15T20:59:29

I'm trying to get to grips with the consequences of the "overloading rules" as Fortress uses them to implement multiple dispatch. Here is a concrete example to explain the problem. I'm re-jigging the String hierarchy to allow multiple implementations of String. String is, in effect, and abstract supertype. The idea is that it should be possible to add new implementations for specific purposes. The first three are EmptyString, CatString, which is a concatenation of two other strings, and JavaString, which is the flat sequence of characters that you know from Java. Let's look at how we define the concatenation operation || trait String opr ||(String, String): String end object EmptyString extends String opr || (self, other:String): String = other opr || (other: String, self): String = other(* This is an optimization --- Originally CordedString line 72 *) opr || (self, _: EmptyString): String = self(* this is required to disambiguate the previous two *) end

un-concreting a method

Michael Spiegel — 2008-08-14T20:34:40

Is this the intended behavior of the language? We are un-concreting a method and get an error message in the interpreter. component UnConcreteMethodTest export Executable trait A foo():ZZ32 = 5 end A trait B extends {A} foo():ZZ32 end B object C extends {B} end C run(args:String...) = do println C.foo() end end UnConcreteMethodTest

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.

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?

Implementation of Red-Black Trees

Michael Lesniak — 2008-07-05T08:16:42

Hello, First, sorry, if it is the wrong mailing list, I wasn't sure which to choose, since my question is neither language nor implementation specific and there's no library mailing list. My name is Michael Lesniak and I'm working at the parallel programming research group of the university of Kassel. I'm interested in writing an implementation of Red-Black Trees (and maybe other collections) in Fortress and evaluating my observations. But there are still some questions: - Is there any prior work? - (more general) do I have to consider anything special? - Is it advisable to get full repository access, i.e. sign the Sun Contributor Agreement? (This won't be a problem) Fortress seems to grow into a really exciting language and I'd like to help it grow :) Best regards, Michael

Mixing # and : in strided ranges

Jan-Willem Maessen — 2008-07-02T15:51:21

Folks who have been tinkering with Fortress may have noticed that strided ranges of the form lower:upper:stride haven't yet been implemented. I'm in the process of thinking about how this might best be done. The big question in my mind is how the # and : notations interact with a stride. My ideal semantics look something like the following: l:u:s yields l, l+s, l+2s, ... <= u (so u is a rigid upper bound on the enumeration). l#n:s yields l, l+s, l+2s, ... l+(n-1)s (so that n exactly dictates the number of items enumerated). I raise this issue in part to get people's opinions, but also because I'll be implementing this by simply overloading the : operator, so that it should be possible to write something like: myArray.indices():2 And stride through the indices of myArray by 2. But this will require some major revisions to the internals of the types involved; at present we do not distinguish l#s from l:(l+s-1) and we would need to make that distinction in order for this code

Hello ProjectFortress! Questions and discussion on scripting, pattern matching, goal-directed programming, and other nondeterministic idioms.

Danielle Fong — 2008-06-29T13:01:06

Hello Project Fortress! I've been lurking around the project for a while now. As someone who's done a lot of scientific programming, I was routinely dismayed by the linguistic support for what I wanted to do, and set to work learning language design, sometime around last summer. I made a list of things I wanted to try, things I thought I'd really want when I got back to scientific programming. Happily, once I discovered Fortress, I found it had most of them, and many more times good ideas that I hadn't expected -- especially in parallelism. And so I am very excited. I'm especially glad that you're using mathematical notation. There just weren't enough operators in other languages for everyone to do what they wanted. But the improvements in readability are enormous. And, we can't forget Kernighan's law: "Debugging is twice as hard as writing the program, so if you write the program as cleverly as you can, by definition, you won't be clever enough to debug it." That's a big problem people encounter in scie

Comments and end annotations

Victor Luchangco — 2008-06-17T10:45:22

In reading some library code recently, I got confused because I didn't realize that some code was commented out, and that some other code was part of an object declaration. So I wonder if what others think about the following: 1. When code within comments is rendered as ordinary Fortress code, it is slightly indented with a continuous vertical line at the left margin. If there are multiple levels of nesting such commented-out code, then there should be one such line for each level of nesting. (Basically mimicking quoting in many mail handlers.) This affects only the rendering of Fortress comments, not the syntax or semantics of Fortress code. 2. After the closing "end" of a multiline trait or object declaration, or a component or api declaration, it is permissible (but not required) to write the name of the trait/object/api/ component being declared. Such a name must appear on the same line as the end, and it is a static error if it does not match the name declared. (The st

2008 Concertant Multicore Processor Survey

Russel Winder — 2008-06-10T06:56:10

Although not directly relevant to Fortress per se, I hope I am not out of order putting this email on this list. Just over a year ago, I undertook a small survey about multicore processors (MCPs) and the market. The answers I got contributed to an analysis of the market. A lot of people were very interested in the results of the analysis, even though it was relatively informal. This has led to undertaking a more structured survey, which will probably become an annual thing so we can get longitudinal data. The survey covers the whole gamut of those involved with MCPs including, but by no means limited to, end-users, specifiers, hardware and software engineers, programmers, applications developers, consultants and those responsible for strategic programmes. We are as ever interested in both embedded and general-purpose systems and their application in everything from control and signal analysis, to weather forecasting and sub-nuclear physics via databases, medical imaging, financial modelling and real-

Thought on typecase

Sorin Miklós Zsejki — 2008-06-06T20:21:43

I find it uncomfortable that it is not easy to select a parameterized type with a typecase. Suppose: trait X[\T extends Y\] end then I can't specify a clause that matches any instantiation of X. It is possible to create an additional nonparametric trait that X extends, but it isn't practical nor nice to do so just to be able to use typecase. I could do trait X[\T extends Y\] extends X[\Y\] end but leads to a stack overflow if I then use X[\Y\] (just as trait Z extends Z end does). I can create a ticket for this if it's appropriate, but the question could be whether it is legal to declare that a trait extends itself (doesn't it always?).

Functional method in object expression throws an error

Sorin Miklós Zsejki — 2008-06-06T01:01:55

Defining a functional method in an object expression gives a "Missing value: f in environment:" message. component Main export Executable run(args) = do o = object f(self) = () end end end

How to "overload a function with static parameters"?

Sorin Miklós Zsejki — 2008-05-30T17:29:57

Let's say I have: trait P end trait R[\T extends P\] end f[\T extends P\](p: T): R[\T\] Now I add this: trait SubP extends P end trait SubR[\T extends SubP\] extends R[\T\] end and I want an overloading of f like this: f[\T extends SubP\](p: T): SubR[\T\] This is not possible because the static parameters of f must exclude each other. So my question is how to do this _without giving up the static parameters_. I know I could do something like: trait R1 extends R end trait R2 extends R excludes R1 end and declaring f for R1 and R2, but what I want is a general declaration of f and an overloading for the more specific cases like SubP. I don't want the general case (the first 3 lines of code) to make any reference to SubP or SubR. I think with where clauses I could do something like: trait OverloadsF extends P end f[\T extends P\](p: T): SubR[\T\] where {T excludes OverloadsF} and then SubP would also extend OverloadsF. Is that right? Another question is why the static parameters must exclude each o

Proposal to expand set of operator words

2008-05-30T05:31:04

Background: (1) A basic principle of operator words in Fortress, as far as we are able to support it, has been that if you know the LaTeX name for an operator symbol, then if you leave off the backslash and write it using uppercase letters, then that is a name for that symbol in Fortress and "ASCII conversion" will replace that name with the character itself. (2) The AMS has been working with other scientific and mathematical publishing societies and corporations to produce a comprehensive set of freely available fonts that will cover all mathematical operatiors in Unicode version 5. They also plan to provide LaTeX support for these fonts, and as part of that process will provide a LaTeX macro to name each operator symbol for use in "math mode". See http://www.stixfonts.org . (3) Our plan for the last two years has been that when the AMS eventually releases its STIX fonts (later this year, we hope), we will adopt their names for the Unicode mathematical operators in accordance with principle (1). (4) A

Source files organized "Java-style"

Sorin Miklós Zsejki — 2008-05-29T04:32:46

I've noticed that if I organize source files for components/APIs in folders based on their names, i.e. the component Com.Example.Something in ./Com/Example/Something.fss instead of ./Com.Example.Something.fss, the file is found but I get a "Component/API names must match their enclosing file names" message. I can easily circumvent this error by a quick&dirty trick in Compilation.rats like in the attached patch. I now this is far from perfect (mainly because I can't tell how much of the path comes from the component name), but it allows me to organize files in folders, which would be a big deal. If this won't be implemented properly in the near future, could you consider doing something similar? Please...? Index: com/sun/fortress/parser/Compilation.rats =================================================================== --- com/sun/fortress/parser/Compilation.rats(revision 1745) +++ com/sun/fortress/parser/Compilation.rats(working copy) < at >< at > -38,9 +38,14 < at >< at > { Span span = createSpan(yyStart,yyCount