chTxNs5UKr24fraaeP0Qfc 2 2011-10-24T11:25:54-04:00 isFunctionCall operates on the assumption that an id uniquely identifies a function. This is no longer the case in Prexonite 1.2.4 The function should be wrapped in a macro that warns about the deprecation. There is no need to provide an alternative. 1 8743153 99 false 665573 chTxNs5UKr24fraaeP0Qfc 99 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Deprecate isFunctionCall from psr\ast.pxs

2011-10-24T11:25:54-04:00 1.0 1.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch technical debt minor defect None technical debt minor defect None chTxNs5UKr24fraaeP0Qfc 5 2011-04-20T19:55:18-04:00 There still are a number of incorrect uses of ToLower/ToDouble (not supplying culture) in Prexonite. These almost certainly are all bugs. Need to find, and remove them. 0 3671783 17 false 378335 chTxNs5UKr24fraaeP0Qfc 70 2 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Hunt down CA1304/CA1305 ToLower/ToDouble etc.

2011-04-20T19:55:28-04:00 6.0 6.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch defect major defect defect major defect chTxNs5UKr24fraaeP0Qfc 2 2011-03-29T09:21:42-04:00 As a user of Prexonite, I'm able to write an interpreter directive at the top of a Prexonite Script file (#! /usr/bin/env mono Prx.exe). Such a directive is ignored by Prexonite despite the fact that neither # not #! are recognized comment tokens. 0 3488939 14 true 378335 chTxNs5UKr24fraaeP0Qfc 50 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Prexonite Script files can be used as scripts under Linux

2011-09-22T01:53:19-04:00 2.0 2.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion enhancement suggestion chTxNs5UKr24fraaeP0Qfc 2 2011-03-29T09:27:04-04:00 When compiling one (or multiple) script files, if the input files had interpreter directives, the output file should have the same interpreter directive. Not all files compiled agree on an interpreter directive, a warning is output on stderr, informing the user that the interpreter directive of the first file listed on the command line was chosen. The message should include the directive verbatim. 0 3489005 16 false 378335 chTxNs5UKr24fraaeP0Qfc 51 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Copy interpreter directive into compiled files

2011-09-22T01:53:17-04:00 2.0 2.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion enhancement suggestion chTxNs5UKr24fraaeP0Qfc 2 2011-04-08T08:00:51-04:00 Prexonite currently only builds on Windows under VS2010. That is not ideal. There should be a mechanism that allows Prexonite to be built under linux/mono, possibly without support for T4. Ideally the MSBuild file can be used for both platforms. Otherwise a separate mechanism is needed (Makefile, XBuild). 0 3576449 11 true 378335 chTxNs5UKr24fraaeP0Qfc 58 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Add mono/linux compatible build instructions

2011-07-12T18:13:40-04:00 6.0 6.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion enhancement suggestion chTxNs5UKr24fraaeP0Qfc 4 2011-04-08T08:02:30-04:00 Test should not just be run on Windows, but also on mono/linux. It should be possible to run the test suite under mono/linux. One simple command line should be enough (e.g., <code>make test</code>) 0 3576459 12 true 378335 chTxNs5UKr24fraaeP0Qfc 59 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Make automated testing under mono/linux possible

2011-07-12T18:13:50-04:00 3.0 3.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion enhancement suggestion chTxNs5UKr24fraaeP0Qfc 0 2011-06-13T15:19:18-04:00 The following code fails with "System.InvalidProgramException : JIT Compiler encountered an internal limitation." <pre><code>function f() { return 1; } function main() { var zs = []; zs[] = call\sub(f(?)); return zs[0]; } </code></pre> Assigning to "zs[]" is important. Removing the assignment or assigning to a local variable does not trigger the error. 0 4151660 10 false 378335 chTxNs5UKr24fraaeP0Qfc 72 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Non-local jumps in BlockExpressions result in invalid byte code.

2011-09-22T04:51:33-04:00 4.0 4.0 None 0.0 4.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch defect major defect defect major defect chTxNs5UKr24fraaeP0Qfc 5 2011-06-20T21:39:15-04:00 There are a number of goto-constructs in Prexonite that are apparently not understood by the mono C# compiler (not blaming dmcs here, Microsofts csc is probably a bit too liberal). Need to rewrite these sections with structured blocks... (sigh) <pre><code>Compiler/Ast/AstBinaryOperator.cs(286,26): error CS0159: The label `additionRedundancy:' could not be found within the scope of the goto statement Compiler/Ast/AstBinaryOperator.cs(344,26): error CS0159: The label `divisionRedundancy:' could not be found within the scope of the goto statement Compiler/CompilerTarget.cs(1659,30): error CS0159: The label `replaceInt:' could not be found within the scope of the goto statement Compiler/CompilerTarget.cs(1662,30): error CS0159: The label `replaceInt:' could not be found within the scope of the goto statement Compiler/CompilerTarget.cs(1665,30): error CS0159: The label `replaceInt:' could not be found within the scope of the goto statement FunctionContext.cs(658,30): error CS0159: The label `doIncrement:' could not be found within the scope of the goto statement FunctionContext.cs(677,30): error CS0159: The label `doDecrement:' could not be found within the scope of the goto statement FunctionContext.cs(894,30): error CS0159: The label `doIndloc:' could not be found within the scope of the goto statement FunctionContext.cs(910,30): error CS0159: The label `doIndloc:' could not be found within the scope of the goto statement FunctionContext.cs(915,30): error CS0159: The label `doIndloc:' could not be found within the scope of the goto statement Types/StructurePType.cs(345,34): error CS0159: The label `normalString:' could not be found within the scope of the goto statement </code></pre> 0 4211280 15 false 378335 chTxNs5UKr24fraaeP0Qfc 81 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Some Goto's not understood by mono compiler

2011-08-03T09:04:43-04:00 0.0 0.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch defect blocker defect blocker chTxNs5UKr24fraaeP0Qfc 5 2011-06-20T21:42:48-04:00 In several cases, the path on disk does not correspond to the path in the project 1:1 (case sensitive; works on Windows, fails under Linux) * The folder AST must be renamed to Ast * The file Prexonite/Compiler/Ast/AstTypeCast.cs must be renamed to Prexonite/Compiler/Ast/AstTypecast.cs (→ lowercase c) || or the reference in the project must be changed! 0 4211288 6 false 378335 chTxNs5UKr24fraaeP0Qfc 82 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Mismatch between file names/paths on disk versus in project.

2011-06-20T21:44:27-04:00 0.0 0.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch defect blocker defect blocker chTxNs5UKr24fraaeP0Qfc 5 2011-06-20T21:45:32-04:00 0 4211296 13 false 378335 chTxNs5UKr24fraaeP0Qfc 83 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Find a solution for portable `add` and `requires` directives.

2011-08-03T09:04:46-04:00 0.0 0.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch defect major defect defect major defect chTxNs5UKr24fraaeP0Qfc 1 2011-08-09T08:56:39-04:00 Finally blocks (including disposing in using and foreach statements) are not guaranteed to run when exiting the function early (only non-CIL). This makes coroutines that handle resources (such as threads, file handles) impossible. 0 4674880 85 false 378335 chTxNs5UKr24fraaeP0Qfc 85 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Finally blocks not guaranteed to run with early return/coroutines

2011-08-09T08:56:39-04:00 0.0 0.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch defect major defect None defect major defect None chTxNs5UKr24fraaeP0Qfc 5 2011-10-06T12:57:43-04:00 So far Prexonite performance has mostly been tested against micro-benchmarks. There is one important problem with those: They usually don't capture work the GC has to perform. In Prexonite, allocating a new value is relatively cheap (because the GC keeps the heap defragmented which in turn makes allocation fast). And Prexonite allocates a lot of heap objects. But you only pay for these once they're being collected. So: create a benchmark (or find something that can be used as a benchmark) that resembles the sort of tasks that Prexonite is likely to perform "out in the wild". Put that benchmark under version control and use it regularly. 0 7736093 97 false 378335 chTxNs5UKr24fraaeP0Qfc 97 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Create/find non-synthetic benchmark

2011-10-06T12:57:43-04:00 0.0 0.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch task suggestion None task suggestion None chTxNs5UKr24fraaeP0Qfc 0 2011-12-18T06:25:55-05:00 Idea: Take a bunch of modules and repackage its contents into a single new module Purpose: Compile lots of files and/or small modules separately (for performance/stability) and then create a single, unified module for others to link against. Boundaries: * "Binary compatibility" not necessary. It is not necessary (and in general not possible) to support clients, that linked against the fragments, to work with the unified module without re-compilation. * Need to provide updated symbolic information for target module 1 11633963 101 false 378335 chTxNs5UKr24fraaeP0Qfc 101 3 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Repackage Module contents

2011-12-18T06:25:55-05:00 0.0 0.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion module None enhancement suggestion module None chTxNs5UKr24fraaeP0Qfc 0 2010-08-28T06:56:59-04:00 A comment (line or block) as the last non-whitespace element of a script file causes a compiler error. This MUST be legal. The problem seems to be connected with the build commands <code>add</code> and <code>require</code> (or the underlying mechanisms in the loader). Workaround: add an empty initialization block after the comment: <pre><code> //the last comment { }</code></pre> 0 2051805 4 true 378335 chTxNs5UKr24fraaeP0Qfc 26 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Comment at the end of a script file causes compiler error

2011-06-19T13:08:20-04:00 4.0 4.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch defect major defect defect major defect chTxNs5UKr24fraaeP0Qfc 2011-01-11T21:32:42-05:00 A possible enhancement to #37. A macro writer CAN communicate to the compiler, that it wants to take advantage of *automatic compatibility with partial application*. This*does not replace* the ability to communicate (manual) compatibility as per #37. Automatic partial-application-compatibility MIGHT require additional work from the macro writer, but in the average case SHOULD require less effort than (manual) compatibility as per #37. h1. Implementation idea for automatic partial-application-compatibility 1. Create a nested function f_1 for every partial macro invocation. 2. Insert the AST returned by the macro function/command/etc into that function f_1 3. In the invoking function f_0, replace the partial macro invocation with a reference to/or partial application of f_1. Step 1 will require analysis of the AST and possibly additional information returned by the macro to determine things like shared variables (which will also affect f~0~) 0 2920229 8 true 378335 chTxNs5UKr24fraaeP0Qfc 38 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Automatic partial-application-compatibility for macros

2011-09-22T02:17:30-04:00 10.0 10.0 None 0.0 11.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion macro, partial-application enhancement suggestion macro, partial-application chTxNs5UKr24fraaeP0Qfc 2011-04-08T08:07:11-04:00 Extra lining takes an AST subtree, compiles it into a separate function (nested) and replaces the subtree with a call to that function. This functionality should be offered by the compiler as a service (macros should be able to request extra-lining of a AST subtree of their choice) The process should be configurable where needed. 0 3576477 9 false 378335 chTxNs5UKr24fraaeP0Qfc 60 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Implement "extra-lining"

2011-09-21T23:18:14-04:00 10.0 10.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion macro enhancement suggestion macro chTxNs5UKr24fraaeP0Qfc 1 2011-04-17T15:49:29-04:00 The new call\sub capabilities should also be included in list processing commands. Break means to stop processing further elements (discard all unprocessed elements including the current one) Continue means to skip the element currently being processed (like a where) 0 3639539 66 true 378335 chTxNs5UKr24fraaeP0Qfc 66 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Have list commands react to `break`, `continue`

2011-09-11T07:44:25-04:00 3.0 3.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion enhancement suggestion chTxNs5UKr24fraaeP0Qfc 0 2011-06-19T07:59:08-04:00 Add a special meta key that allows a programmer to specify the Prexonite compiler version requirements for a file. There SHOULD be special logic in the compiler that, upon encountering this meta entry, immediately checks whether the compilers version satisfies the requirements of the file. This is done on a file-by-file basis. The compiler MUST issue an ERROR message, it its version doesn't satisfy the compiler version requirements. It MAY attempt to complete the translation, though. Additionally, the compiler MUST embed its version into the compiled application. Suggested keys: * *compiler\version* for the version requirement * *compiler\actual* for the actual version of the translating compiler There should be two ways to specify the version: compiler\version "1.2.2.0"; // compiler version must be *at least* 1.2.2.0 compiler\version "1.2"; // compiler version must be *at least* 1.2.2.0 (missing parts added) compiler\version {"1.2.2","1.2.3"}; // compiler version must be *at least* 1.2.2.0 and *below* 1.2.4.0 compiler\version {"1.2.2.0", "1.2.3.0"}; //compiler version must be *at least* 1.2.2.0 and *below* 1.2.3.1 0 4198894 2 true 378335 chTxNs5UKr24fraaeP0Qfc 73 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Compiler version requirements

2011-06-19T08:13:04-04:00 3.0 3.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion version enhancement suggestion version chTxNs5UKr24fraaeP0Qfc 1 2011-06-19T08:11:31-04:00 A meta entry in the application's meta table specifies the versions of the Prexonite runtime that will be able to execute the application's code. Prior to running any code from an application, the Prexonite runtime MUST check whether its version satisfies the runtime version requirements stored in a meta entry in the applications meta table. If it does not satisfy the runtime version requirements, it MUST throw an IncompatibleVersion exception. The runtime MUST also check the runtime version requirements when running initialization or build code. Suggested meta keys: * *runtime\version* There should be two ways to specify the version: runtime\version "1.2.2.0"; // runtime version must be *at least* 1.2.2.0 runtime\version "1.2"; // runtime version must be *at least* 1.2.2.0 (missing parts added) runtime\version {"1.2.2","1.2.3"}; // runtime must be *at least* 1.2.2.0 and *below* 1.2.4.0 runtime\version {"1.2.2.0", "1.2.3.0"}; //runtime must be *at least* 1.2.2.0 and *below* 1.2.3.1 Other formats might be supported in the future. 0 4198920 1 true 378335 chTxNs5UKr24fraaeP0Qfc 74 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Runtime version requirements

2011-06-19T08:11:31-04:00 4.0 4.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion version enhancement suggestion version chTxNs5UKr24fraaeP0Qfc 1 2011-06-20T15:15:27-04:00 While doing memory profiling, I noticed that there are probably a lot of "duplicate" ObjectPType objects. Since these are immutable and intended to be shared/aliased (the latter is true for all PType objects), there is potentially room for improvement through caching. I'm thinking about something simple, like keeping the last 200 (or so) requested ObjectPTypes around. But as always: Need to measure first... 0 4208774 5 false 378335 chTxNs5UKr24fraaeP0Qfc 80 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Investigate caching ObjectPType instances

2011-06-20T15:15:36-04:00 3.0 3.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion enhancement suggestion chTxNs5UKr24fraaeP0Qfc 1 2011-10-06T12:52:16-04:00 Int, Real, Bool and String literals all cause a stack allocation when they are encountered in the program: The PValue around them needs to be instantiated. What if, instead, the CIL compiler generates a class that provides "singleton" PValues for all literals in an application? Is that more performant? Less performant? Is it feasible in an extensible manner? 0 7735773 96 false 378335 chTxNs5UKr24fraaeP0Qfc 96 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Investigate performance of caching PValues for literals

2011-10-06T12:52:16-04:00 5.0 5.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch enhancement suggestion None enhancement suggestion None chTxNs5UKr24fraaeP0Qfc 3 2012-05-24T08:05:28-04:00 Currently, exception types defined by Prexonite don't handle de-serialization. This is against Microsoft's recommendations regarding Exception types, since it makes it impossible to send these exceptions "over the wire" (Remoting, etc) 1 21970973 102 false 378335 chTxNs5UKr24fraaeP0Qfc 104 4 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Implement serialization for exceptions.

2012-05-24T08:05:28-04:00 0.0 0.0 Medium 3.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch technical debt minor defect exception, serialization None technical debt minor defect exception, serialization None chTxNs5UKr24fraaeP0Qfc 2011-04-19T08:06:47-04:00 The partial application of call\macro should yield a value that is stack aware if the macro is implemented as a function. There is no immediate application for this change. It might be useful for hypothetical Prexonite debuggers (opaque IIndirectCall barriers are an obstacle for debuggers) 0 3654181 7 false 378335 chTxNs5UKr24fraaeP0Qfc 68 5 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

Value returned by call\macro\prepare_macro should be stack aware

2011-08-03T09:04:48-04:00 2.0 2.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch technical debt suggestion technical debt suggestion chTxNs5UKr24fraaeP0Qfc 1 2011-06-19T12:42:35-04:00 call\tail (whether used directly, or via a partial application) doesn't provide a return value. It works as a statement but it will always result in {-NULL-}. Lifting this limitation is currently not very high on my list of priorities. 0 4199418 3 false 378335 chTxNs5UKr24fraaeP0Qfc 79 5 chTxNs5UKr24fraaeP0Qfc d27yQqgRir3iNOabIlDkbG 1 Accepted 0

call\tail does not provide a return value

2011-08-03T09:04:53-04:00 2.0 2.0 None 0.0 0.0 chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch chTxNs5UKr24fraaeP0QfcSealedSunSealedSunSealedSunhttp://www.sealedsun.ch defect minor defect tail call defect minor defect tail call