gmane.comp.lang.fortress.general

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 ge

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 n

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 writ

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/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

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 wh

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