gmane.comp.lang.fortress.general

Are strided for-loops implemented?

Tom Trauth — 2008-09-07T19:59:36

To all: Section 13.16 of the v.10 spec (which defines a range to be "Expr?:Expr(:?Expr)?") and Ticket #200 (which is about how to handle a range defined as a:b:c where c = 0) imply that one can do a strided (stepped) for-loop as follows: for <- 0:10:2 do . But the following program fails with a message that "Failed to find any matching overload, args = (ParRange[\ZZ32,true\],2: ZZ32)": component tom export Executable run(args:String...):() = do for i <- 0:10:2 do println(i) end end end If I change the range to "0:10", it works fine, so I know that the ":2" is the culprit. Did I make a subtle mistake or is this feature not yet implemented? And if it's not yet implemented, is the planned future implementation a multifix colon range operator that takes 3 parameters (a:b:c), or an infix colon stride operator that takes a range as its first parameter and a stride as its second (r:c, where r = a:b)? And sorry if the above is a stupid question, but I am relatively new to this language and just downloaded it recently. Regards, -Tom

Re: Typing [\ and \] [was: Re: Testing for specific thrown exceptions]

Eric Allen — 2008-09-04T20:31:27

On Sep 4, 2008, at 2:55 PM, Guy Steele wrote: One thing I'd like to add: Given that the back end of our implementation is currently an interpreter, supporting an interactive command line should be a very doable task that could be taken on by the open source community. Is anyone on this list interested in working on this? The implementation work on Fortress within Sun is currently focused on getting the type checker online and improving performance, so the task of putting together an interactive command line is wide open.

Re: Typing [\ and \] [was: Re: Testing for specific thrown exceptions]

Guy Steele — 2008-09-04T19:55:39

Sorry to hear that you're having so much trouble with various tools and plugins. We have studied seriously the idea of using [ ] instead of [\ \] for type parameters. However, there would be some serious parsing difficulties and we think we cannot make it work in general in a readable way, given that we are also using [ ] for subscripts and for array constructors. Here is a sample of our discussions: If we use [ ] for static type argument, then does the expression f[3](a+b) mean that f has the nat 3 as a static type argument, or that f is an array whose third element is being invoked as a function (or possibly multiplied by a+b)? We cannot tell without type analysis of f; now, we do indeed use type analysis to perform final parsing of tight juxtapositions, but this would require even more complicated rules. Moreover, the type analysis would have to be extended beyond tight juxtapositions to loose juxtapositions. Consider: f[3] (a+b) Figuring out whether 3 is a nat type argument or a subscript gets a lot trickier. Also, we have in mind the possibility of allowing operators to take static type arguments. In fact, I've been thinking about a specific use case: parallel prefix. In the past I've suggested notations such as PREFIX_SUM, but in fact the "prefix" concept is a meta-operator, and it occurs to me that maybe what we want is opr PREFIX[\opr OPLUS\](...) = ... to be invoked with something like PREFIX[\+\] myarray or even PREFIX[\+\] [i <- 1:n] x^i White brackets leave this possibility open, but it would be close to impossible if we overload ordinary square brackets in this way (unless we add rules about whitespace having to precede square brackets even after an operator in order to be array/matrix notation). As for an interactive command line, yes, we are thinking about that and it would be a very good idea. We need to find the time to work out the semantics of how an interactive command workspace would interact with the type system and the component system, but I think we really need to create an interactive facility. --Guy Steele On Sep 4, 2008, at 4:00 AM, dmitrey wrote:

Re: Typing [\ and \] [was: Re: Testing for specific thrown exceptions]

David Chase — 2008-09-04T19:51:51

The StiX fonts will be done in two months (this has been true for the last twelve months, it seems to be a constant). Till then, you can use the cheap shareware ($5) Code2000 fonts from James Kass. I'd like to be somewhat forward-looking in the language design; if you get the fonts right, the output is much more readable, and for overall productivity, that matters. David On 2008-09-04, at 10:49 AM, Sebastian Fernandez wrote:

vmkit: JVM for LLVM

Michael Spiegel — 2008-09-04T18:14:58

Some food for thought on future Fortress compiler targets. Unfortunately, LLVM currently has no concurrent garbage collector. That's the biggest loss. And a whole host of other features would need to be implemented in order for LLVM to be a viable target. But some of the performance metrics in this presentation are quite interesting: http://llvm.org/devmtg/2008-08/ (Check under "The VMKit Project" and watch the video). --Michael

Re: Typing [\ and \] [was: Re: Testing for specific thrown exceptions]

Sebastian Fernandez — 2008-09-04T14:49:42

A bit off-topic, but I would also really like to see this. I think having a Matlab-like read-eval-print loop would be an excellent way to get users started with Fortress even if the performance story isn't quite there yet. Many times during the day I have to do some quick one-time operation (e.g. invert a matrix, sort a file) and I care more that I can write the code quickly than that it runs quickly. On the [\, \] issue: it is nice that Emacs does the auto-conversion, but many times we look at code outside of an editor (e.g browser, e-mail). It is nice that there's a tool to convert Fortress to Latex and then to PDF, but I doubt I'd use that if I wanted to send a quick e-mail with some snippet of code. One solution is to use Unicode, but how likely is it that people will have the right font set? -- Sebastian Fernandez

Re: Typing [\ and \] [was: Re: Testing for specific thrown exceptions]

dmitrey — 2008-09-04T08:00:31

Sorry, it's certainly my terrible fault, I forgot of the issue Guy Steele wrote: I had tried to install Emacs plugin but failed, and noone responded in mail lists (I had proposed to provide instructions from online installation of the plugin from a Emacs web server, like ). So currently I'm using Eclipse, however, only to type and save Fortress code, I run it from my OS (KUBUNTU) terminal, because I failed to turn Eclipse to run fortress programs. Also, I had contacted developer of my favorite Eric IDE to provide support for Fortress, but he had answered it's up to QScintilla developers (QScintilla is a dependence, required package for Eric), and I haven't contacted them yet. I have common 104 (or 105?) key keyboard, made by Genius, as almost everyone here in Ukraine. However, I can't say I type fortress code too often, I see the language specification still changes too often, and speed of the one is too far even from Python + numpy(compiled C/Fortran matrix operations code). Also, there are not lots of fortress users yet. It's hard for me to explain my institute numerical optimization dept even why Python should be used (they use Fortran and sometimes C/C++), so convincing them to use Fortress (or at least allow me to use the language) that is much slower now (and taking into account all written above) is just impossible. As for the characters, 2-symbol keystrokes pollute code, it's less readable for humans - both ASCII version (very often for to make insufficient changes small ASCII editors are used (like kwrite, kate, kedit, mcedit, MS notepad) instead of running heavy IDEs like Eclipse) and all those UNICODE characters [[ ]] proposed in mail list earlier. Ok, could you answer another one question - is fortress intended to ever have dynamic (interactive) version? I.e. currently it's only static language - type a file and run it, while Python or MATLAB code can be typed from language command prompt. AFAIK Jython is Python interpreter written in Java (as well as Fortress for now) and it has command prompt. Regards, D.

Typing [\ and \] [was: Re: Testing for specific thrown exceptions]

Guy Steele — 2008-09-03T21:51:09

On Sep 3, 2008, at 3:37 PM, dmitrey wrote: It's not off-topic, just a change of topic. (I have changed the subject line for this message.) We take ease of typing very seriously, and I don't want you to think we are just ignoring the issue. However, our assumption is that we will have good editing environments. I am using Emacs, for example, and in the Fortress mode I have coded extra key bindings so that (on my Macintosh keyboard) Command-[ and Command-] insert mathematical white brackets (actually, for now they insert [\ and \] sequence, and the Fortress mode then displays them as white brackets). On a Windows box, the corresponding keystrokes would me Alt-[ and Alt-]. May I ask what editing environment you are using, and what kind of keyboard? I agree that ideally [\ and \] would be single keystrokes and would display as single symbols---I just don't think that choosing the ASCII characters such as [ ] or { } is necessarily the best solution to this problem. --Guy Steele

Re: Testing for specific thrown exceptions

Jan-Willem Maessen — 2008-09-03T20:33:22

On Sep 3, 2008, at 3:37 PM, dmitrey wrote: Actually, T[n] declares an n-element array of type T, so it's quite ambiguous. More generally, the easy-to-type brackets really are taken; in order to change type brackets we need to change some other kind of brackets as well. That said, we chose a character pair that could be typed without shifting (on the US keyboards I've seen, in any case; placement of characters like [ and ] seems to vary on international keyboards). Once I've typed it, it displays as the corresponding unicode on my development machine (courtesy the emacs mode contributed by Yuto Hayamizu). In general, we wanted to make it the case that: * Simple parens always mean grouping, and nothing else particularly special. * Array indexing to be easy to do (thus [ and ] ) * Type brackets less easy than array indexing. In part we're suffering because the type checker isn't quite complete yet (though it is nearly so). At that point I expect to spend much less time writing type parameters in my code (though top-level declarations in the library will continue to include explicit type information). I understand that the parser has been modified (as of the last week or two) to accept the corresponding unicode character as well. I haven't yet done the experiment myself, due to lack of time. -Jan-Willem Maessen

Re: Testing for specific thrown exceptions

dmitrey — 2008-09-03T19:37:07

I'm sorry about off-topic but could fortress developers explain why they can't change the highly inconvenient [\...\] syntax to something easier (first of all I mean 1-symbol type) - what are the difficulties here? For example, if there are no space between func(args), instead of func[\static args\](args) it could be used mere as func[static args](args) (w/o separating space as well) . Will it yield any problems for parser? It seems to me no, since it's definitely not array, because there are no space character between "func" and square brackets "[static args]". Also, {} could be used as well, since no space is present hence it's not a set. Regards, D. Sorin Miklós Zsejki wrote:

Testing for specific thrown exceptions

Sorin Miklós Zsejki — 2008-09-03T19:13:44

Some time ago I searched in the FortressLibrary for a way to unit test that my fortress code throws a specific error and I didn't find something like that (is there?). So I have written such a function that I find quite useful and probably others might find it useful too. I am attaching my version of it for the curious and for the willing to comment and give me advice on my current fortress coding style (or lack of it). The code is very simple, and the most common use is something like this: expect[\ExpectedExceptionType\](f) where ExpectedExceptionType is the type of exception that should be thrown by f(). There are 2 alternative forms for more specific testing: expect[\E\](f, expectedException) that checks that the exception that is thrown is equal to expectedException and: expect[\E\](f, fn(e: Exception) => (* check that the thrown exception satisfies any other condition *) ) Please tell me what you think.

Re: Is there a problem?

Russel Winder — 2008-08-30T09:29:08

The same revision, r2778. I think though I have found the issue. I am using Ubuntu 8.04 Hardy Heron. If JAVA_HOME points to the Sun Java 6 installation everything is fine. If JAVA_HOME points to the OpenJDK then I get the errors pointed out in my earlier message. The question is then is this an OpenJDK problem or a Fortress problem -- just because the error only arises with OpenJDK doesn't necessarily mean that the problem is in OpenJDK, but in this case it probably is.

Re: Is there a problem?

Jon Rafkind — 2008-08-30T07:28:48

It compiles fine for me at r2778. What svn revision are you using? Russel Winder wrote: ators, set_intersection, curly_or, circled_multiplication_and_division, curly_and, tri_addition_and_subtraction, greater_than_operators, relational_misc, misc_set, tri_misc, circled_additio! n_and_subtraction, enclosing, addition_and_subtraction, enclosing_left, tri_multiplication_and_division, boolean_conjunction, double_colon]

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/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser_util/precedence_resolver/Operators.java [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/Library/FortressAst.fsi [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/Library/FortressAst.fss compile: init: [echo] basedir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress [mkdir] Created dir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build [mkdir] Created dir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/junit-results compileCommon: [javac] Compiling 103 source files to /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. checkAstgen: astGenerators: [javac] Compiling 14 source files to /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build checkNodesUptodate: [echo] Nodes up to date? ${nodes.uptodate} makeAST: [echo] Processing /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/astgen/Fortress.ast [move] Moving 1357 files to /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/nodes [move] Moving 2 files to /home/Checkouts/Subversion/Fortress_Trunk/Library checkParserUptodate: [echo] Parser up to date? ${parser.uptodate} checkOperatorsUptodate: [echo] Operators up to date? ${operators.uptodate} operatorsGen: [echo] Regenerating operators [java] Groups: [tri_contains, multiplication_and_division, square_union, superset_comparison_operators, curly_succeeds, curly_precedes, equivalence_operators, number_sign, c_2_1_division, single_colon, square_intersection, set_union, less_than_operators, square_image_of, dot_above_multiplication_and_division, misc_set_comparison, square_original_of, square_misc, boolean_disjunction, squared_addition_and_subtraction, c_2_1_multiplication, dot_above_addition_and_subtraction, chickenfoot_smaller, enclosing_right, plain_comparison, tri_subgroup, boolean_misc_nonAssociative, squared_multiplication_and_division, misc_addition, inequivalence_operators, curly_misc, dot_below_addition_and_subtraction, boolean_misc_leftAssociative, subset_comparison_operators, chickenfoot_greater, other_operators, set_intersection, curly_or, circled_multiplication_and_division, curly_and, tri_addition_and_subtraction, greater_than_operators, relational_misc, misc_set, tri_misc, circled_addition_and_subtraction, enclosing, addition_and_subtraction, enclosing_left, tri_multiplication_and_division, boolean_conjunction, double_colon] parser: Trying to override old definition of task astgen init: [echo] basedir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress checkFortressParserUptodate: [echo] Fortress parser up to date? ${parser.uptodate} fortressparser: [echo] Rebuilding Fortress... [java] Rats! Parser Generator, v. 1.14.1, (C) 2004-2008 Robert Grimm [java] Processing Fortress.rats ... Trying to override old definition of task astgen init: [echo] basedir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress checkPreparserUptodate: [echo] Preparser up to date? ${preparser.uptodate} preparser: [echo] Rebuilding preparser... [java] Rats! Parser Generator, v. 1.14.1, (C) 2004-2008 Robert Grimm [java] Processing PreFortress.rats ... Trying to override old definition of task astgen init: [echo] basedir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress checkTemplateparserUptodate: [echo] Templateparser up to date? ${templateparser.uptodate} templateparser: [echo] Rebuilding template parser... [java] Rats! Parser Generator, v. 1.14.1, (C) 2004-2008 Robert Grimm [java] Processing TemplateParser.rats ... compile: [javac] Compiling 1920 source files to /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/preparser/PreFortress.java:1311: cannot find symbol [javac] symbol : constructor ImportNames(com.sun.fortress.nodes_util.Span,com.sun.fortress.nodes.APIName,java.util.List) [javac] location: class com.sun.fortress.nodes.ImportNames [javac] Import imp = new ImportNames(createSpan(yyStart,yyCount), api, [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:2289: cannot find symbol [javac] symbol : constructor ImportNames(com.sun.fortress.nodes_util.Span,com.sun.fortress.nodes.APIName,java.util.List) [javac] location: class com.sun.fortress.nodes.ImportNames [javac] Import imp = new ImportNames(createSpan(yyStart,yyCount), api, [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:4348: cannot find symbol [javac] symbol : method makeVarargsParam(com.sun.fortress.nodes.VarargsParam,java.util.List) [javac] location: class com.sun.fortress.nodes_util.NodeFactory [javac] yyValue = NodeFactory.makeVarargsParam(a1, FortressUtil.mkList( [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:16246: cannot find symbol [javac] symbol : constructor AbsVarDecl(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.AbsVarDecl [javac] yyValue = new AbsVarDecl(createSpan(yyStart,yyCount), [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:28313: cannot find symbol [javac] symbol : constructor GroupSymbol(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.GroupSymbol [javac] yyValue = new NoWhitespaceSymbol(createSpan(yyStart,yyCount), new GroupSymbol(createSpan(yyStart, yyCount), FortressUtil.mkList(((NoWhitespaceSymbol) s).getSymbol())) ); [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:28315: cannot find symbol [javac] symbol : constructor GroupSymbol(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.GroupSymbol [javac] yyValue = new GroupSymbol(createSpan(yyStart, yyCount), FortressUtil.mkList(s)); } [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:2309: cannot find symbol [javac] symbol : constructor ImportNames(com.sun.fortress.nodes_util.Span,com.sun.fortress.nodes.APIName,java.util.List) [javac] location: class com.sun.fortress.nodes.ImportNames [javac] Import imp = new ImportNames(createSpan(yyStart,yyCount), api, [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:4380: cannot find symbol [javac] symbol : method makeVarargsParam(com.sun.fortress.nodes.VarargsParam,java.util.List) [javac] location: class com.sun.fortress.nodes_util.NodeFactory [javac] yyValue = NodeFactory.makeVarargsParam(a1, FortressUtil.mkList( [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:16298: cannot find symbol [javac] symbol : constructor AbsVarDecl(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.AbsVarDecl [javac] yyValue = new AbsVarDecl(createSpan(yyStart,yyCount), [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:28369: cannot find symbol [javac] symbol : constructor GroupSymbol(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.GroupSymbol [javac] yyValue = new NoWhitespaceSymbol(createSpan(yyStart,yyCount), new GroupSymbol(createSpan(yyStart, yyCount), FortressUtil.mkList(((NoWhitespaceSymbol) s).getSymbol())) ); [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:28371: cannot find symbol [javac] symbol : constructor GroupSymbol(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.GroupSymbol [javac] yyValue = new GroupSymbol(createSpan(yyStart, yyCount), FortressUtil.mkList(s)); } [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/tests/unit_tests/ConstructorsJUTest.java:130: cannot find symbol [javac] symbol : constructor Export(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.Export [javac] Export e1 = new Export(span1, FortressUtil.mkList(newAPIName("some", "exported", "apiname"))); [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/tests/unit_tests/ConstructorsJUTest.java:131: cannot find symbol [javac] symbol : constructor Export(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.Export [javac] Export e2 = new Export(span1, FortressUtil.mkList(newAPIName("some", "exported", "apiname"))); [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/tests/unit_tests/ConstructorsJUTest.java:132: cannot find symbol [javac] symbol : constructor Export(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.Export [javac] Export e3 = new Export(span1, FortressUtil.mkList(newAPIName("an", "exported", "apiname"))); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 14 errors BUILD FAILED /home/Checkouts/Subversion/Fortress_Trunk/build.xml:8: The following error occurred while executing this line: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build.xml:400: Compile failed; see the compiler error output for details. Total time: 2 minutes 31 seconds

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. This is an incompatible change, but I doubt it will affect any existing code. The second set of changes is upward compatible, because they merely provide valid interpretations for situations that were formerly static errors: primary |, OPERATOR | OPERATOR OPERATOR | , OPERATOR |, OPERATOR| , OPERATOR|, OPERATOR | linebreak OPERATOR |linebreak OPERATOR| linebreak OPERATOR|linebreak The third set of changes deals with situations formerly unaddressed by the table which should have been: what happens right after a line break. With these changes, the following expressions would become valid: |a|:|a|+3 |a|#|b| |a|#|b|+|c| |a|+|b|+|c| | |a| - |b| | when it occurs within enclosers or between commas "The length " || |a| || " is just right." I think this change would make |...| notation (and ||...|| notation) much more convenient to use. --Guy

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

Sorin Miklós Zsejki — 2008-08-27T18:32:12

Speaking of speed, I think there must be something wrong with caching (or with my understanding of it). From what I know, if I write new code or modify my code, Fortress is supposed to parse, verify, desugar, etc. my code for the first run and store a representation of the resulting AST in the cache, so that at the next run it will realize that the source files haven't been modified and just parse the processed AST from the cache. But in my experience on both linux and windows, there is very little difference, if at all, between the time of a newly modified component and one that has already run. So either the parsing of the AST takes a time comparable to the parsing, checking, etc., or there is no caching the way I would think, or I'm doing something totally wrong.

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

Sorin Miklós Zsejki — 2008-08-27T01:36:18

Thanks for your answer. I had suspected that HasAt is used only for the error messages, but I was curious enough to throw an error in the called function, and to my surprise it reported correctly the calling site with the correct line and position. Anyway, I will leave it like this for now and will try to follow the changes. On Wed, Aug 27, 2008 at 3:16 AM, David Chase public.gmane.org> wrote:

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

David Chase — 2008-08-27T00:16:41

The answers are a little delicate, because we are right in the middle of moving to compiled top-level environments (which, sadly, don't yet seem to yield an enormous speedup, but maybe we're doing something else wrong). A HasAt is supposed to be the call site for the function, so it can better diagnose errors. (It might be better for the caller to take care of this, now that we are doing a better job of reporting stack traces, but never mind that just yet.) So if there are never any errors, no problem. A "function value" is really a closure, meaning code+environment, and the environment parameter is intended to allow type inference to proceed if you call a generic. For non-generic functions, it is discarded. Careful work on environments for the move to compiled environments suggests that it may not be necessary; I think the proper environment for inference is the function definition site, not the call site, but I am not 100% sure of this. But, this may be another reason why null succeeded -- in just the last few days, that parameter may have gone dead. All the dirty work is actually done in applyInner; if you search for declarations of that you can find out what happened to your parameters. Here's a typical Fcn invocation from EvaluatorBase: protected FValue functionInvocation(List args, Fcn foo, AbstractNode loc) { try { // We used to do redundant checks for genericity here, but // now we reply on foo.apply to do type inference if necessary. return foo.apply(args, loc, foo.getWithin()); } catch (FortressException ex) { throw ex.setContext(loc,e); } catch (StackOverflowError soe) { return error(loc,e,errorMsg("Stack overflow on ",foo)); } } which in turn calls: final public FValue apply(List args, HasAt loc, Environment envForInference) { List unwrapped = conditionallyUnwrapTupledArgs(args); try { return check(applyInner(unwrapped, loc, envForInference)); } catch (UnificationError u) { if (unwrapped != args) { try { return check(applyInner(args, loc, envForInference)); } catch (UnificationError u1) { throw u; } } throw u; } } On 2008-08-26, at 5:48 PM, Sorin Miklós Zsejki wrote:

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 พล http://rejuvenate.blog.mthai.com/2008/08/21/public-1 ขออภัยที่เมล์นี้รบกวนท่าน