srikumarks / muse Goto Github PK

Though I don't think full R5RS compliance is expected or needed in muSE,
some compatibility is definitely possible without compromising the more
useful and general feature of muSE. 

1. (define ...) currently supports only (define f (fn (y) ..)) to define
functions. Supporting (define (f y) ..) as is done in standard scheme is
useful and nicer for creating nested and curried definitions such as
(define ((f x) y) ...) 

2. The scope of define should be restricted to the local lexical scopre of
fn, let and case. Currently define really can only be used to define global
entities. Introducing local variables using define is useful when
programming in the large.

What steps will reproduce the problem?
Sending a series of messages to another process will result in that process
receiving only the first message.
{{{
(define p (spawn (fn () (case (receive) (msg (write msg) ())))))
(p 'ping 0)
(p 'ping 1)
(p 'ping 2)
}}}

What is the expected output? What do you see instead?
Receiving process must receive all sent messsages in the sequence in which
they were sent.

Building the objc branch using XCode gives unusable binary.

When apply is used in a non-tail position and the result of the apply is
itself a tail call, the tail call never gets forced.

For example -
(define g (fn (x) (print x)))
(for-each (fn (x) (g x)) '(1 2 3))

will end up doing nothing.

List reversal functions are useful when working with recursive functions.
If a recursive function builds a list of things, then on occasion you need
the reverse list, in which case an in-place reversal function reverse! is
very useful to have.

Its useful to have block comments and the facility to comment out an
expression just like what Scheme provides. This won't complicate the muSE
runtime much and will only add a teeeeny little bit of overhead to the reader.

Build with VC2003 and muSE will crash whenever it tries to put up a
diagnostics box.

This issue was found thanks to Holger Meisen.

muSE has built-in support for using the ez2scm syntax. This support has
some fairly significant differences with the published ez2scm code
translator. Need to update muSE to be identical to the ez2scm translator.

For info, see http://code.google.com/p/ez2scm

Curently, muSE is unable to define and use recursive procedures because it
doesn't support tail recursion - more generally tail call elimination.

To put in tail call elimination.

In order to make muSE more portable across platforms, the portion of the
code that changes across platforms needs to be isolated so that ports can
be added systematically.

As of v338, the exception mechanism only kicks in if a coder uses the
try/raise/retry/finally expressions. Builtin functions currently don't
raise exceptions when unhandled conditions occur. They use some
idiosyncratic way of dealing with such conditions instead. 

All builtin functions should uniformly use the exception mechanism to deal
with .. well exceptional conditions.

It is sometimes useful to specify arguments to a function in an order
that's different from the declared order. This may be required for a
different argument evaluation order, using default values, or using
argument bindings given as an association list. 

It should be possible to distribute muSE based apps as stand-alone
executables. That will greatly aid its usability. 

1. Add a --exec flag to the REPL version of muSE to generate an executable.
2. If a "main" function is defined, then the created executable should
evaluate it, supplying the command line arguments as a list of strings. If
no main function is given, it should start the REPL.
3. Executables should be growable - i.e. you should be able to add more
definitions to an executable that already contains loaded muSE code.

When attempting to compile muSE r496 on linux via the build script
`build/posix/build', compilation fails with countless warning messages and
several errors. A brief summary of these messages follows, along with a
description of why the error occurred. Attached is the diff which was
necessary to build on linux, though I make no guarantees that the
formatting is to your liking, or the preprocessor catches all BSD-alikes.

1. A GCC warning about multicharacter expressions. Given that the text of
the ANSI standard lists these as implementation-defined instead of
undefined, this seems to be an odd quirk of GCC. It can be silenced with
-Wno-multichar.
2. A GCC warning about converting pointers to integers of different sizes.
The warning is slightly misleading, because a long long is at least long
enough to accomodate 64-bits of information as found in a pointer. It can
be silenced with -Wno-pointer-to-int-cast.
3. Compilation of muse_misc.c failed because the types of struct tm and
va_list were unknown. This occurs because the standard mandates that their
definitions be found in stdarg.h and time.h respectively, and including
them fixes the problem.
4. Compilation without optimizations to remove dangling functions may fail
on linking due to the lack of definition of those functions required by
muse_log outside of Windows. Conditionally compiling or even eliminating
this is the solution.
5. Compilation is aborted when sys/filio.h is not found, nor are the
definitions intended to be included from it, including SO_REUSEPORT. These
headers and definitions are a BSD extension, and are only found on
BSD-alike systems; ideally their near-analogues sys/ioctl.h and
SO_REUSEADDR should be used on POSIX-compliant, non-BSD systems.
6. Linking fails due to the absence of several math- and
dynamic-linking-related symbols, which _should_ be linked with explicitly.
7. The compiled muse binary fails immediately due to a 'double-free or
corruption' bug being detected by glibc in fclose. This occurs as the
is_muSEexec function closes its argument before returning, while the
calling function expects to close the FILE* itself.

Hello.

I currently get segfaults with muSE when i try to cons a lot of cells.
Happens when consing more than 10.000 cells using a recursive procedure,
on a Win32 (XP) machine, using both v372 and v437 from the Downloads tab.

Threading the env pointer through all the function calls has resulted in
this breakage. Need to fix ASAP.

Run code that makes millions of function calls and you'll probably see a
crash in the GC. This bug is relatively rarely encountered during normal
execution of muSE. It usually features in compute intensive runs for
measuring performance.

Bug exists as of version 10 of the source.

The REPL in v108 (processes branch) is broken. It tries to read in all its
input in one go, which works for files but not for the REPL.

(open-file "filename" 'for-writing) 
does not open a file for output.

What steps will reproduce the problem?
{{{
(define f
 (let ((x 1))
   (fn ()
    (let ((x (+ x 1))) x))))

(print (f))
}}}

What is the expected output? 
The printed result should be "2" because when the closure is created, the
value of "x" before the second let binding for x should be used in the
expression "(+ x 1)".

What do you see instead?
Instead you get a "+ cannot add a symbol and a number" kind of error.

What steps will reproduce the problem?
(dup list-of-100000-numbers)
will blow the muSE stack.

What is the expected output? What do you see instead?
Should return a copy of the given list of numbers.

This happens particularly when generating large data structures containing
numbers allocated in native code.

In revision 5 and before, only the higher order function "map" works as
intended on lists. 

1. Need to implement map, reduce and join for lists.
2. Extend the concepts to include vectors and hashtables.

If a function that might raise a condition is called twice within a try
block, then the handler setup by the try block will only be invoked once if
it resumes the condition.

For example -
(try (f a b) (f c d)
  {fn: (ex . ..) (ex 'default)})
will cause the app to terminate with an unhandled exception if f raises the
condition in both invocations.

The call to fn_expand_objc_expression() in muse_port.c still only uses:

#if __APPLE__ 

instead of:

#if defined(__APPLE__) && defined(MUSE_OBJC_SUPPORT)

This gives errors when trying to build without Objective C support on Mac OS X.

There's a couple small bits of code in muse_platform.h related to stack 
handling that assume a 32-bit system. Here's a 64 bit x86 implementation that 
seems to work:

#if 1
#   define SAVE_STACK_POINTER( var ) \
            void *var = NULL; \
            asm("movq %%rsp, %0;" : "=r"(var));

#   define CHANGE_STACK_POINTER(sp_value) \
            do\
            {\
                void *new_sp = (void*)(sp_value);\
                asm("pushq %0; popq %%rsp;" : : "r"(new_sp));\
            }\
            while(0)
#endif

funcspec sounds funky for using to describe a function intended to be used to 
compute data values 
in a collection. "datafn" is more direct.

A lot of build warnings are currently given by the VC2005 compiler. Need to 
eliminate them, fixing 
anything tha tmight be wrong about the code in the process.

1. Figure out an appropriate download location or wait for google to add a
release mechanism.
2. Build for MacOSX
3. Build for Win32

(I don't have a linux box. Anyone willing to do that can contact me.)

Dynamically scoped sub-expressions, when used within closures must always
work. Currently they work only for the first closure created that contains
them. If another closure is created at an even higher level, the
dynamically scoped sub-expression doesn't evaluate correctly if it refers
to values supplied to the second closure.

The muSE API make use of the notion of a "current environment" to which API
calls implicitly refer. This prevents multiple environments from being used
from multiple threads. Use and manage multiple non-interfering instances, etc.

This issue was reported by James McCartney. Thank you!

A major update was made to muSE, which is available as version 0.2a,
starting from revision 16. Brief description -

1. Diagnostics facility added - which pops error messages under Windows and
prints them to stderr under unices.

2. Major revamp of higher order functions. They are now polymorphic over
lists, vectors and hashtables. You can use map, reduce, length etc. with
all of them.

3. All file line endings changed to unix-style line endings.

4. Hashtable bug fixes.

.. and etc. that I can't bother to describe here.

If the guard's pattern is not a universal pattern and the supplied arguments 
don't match its pattern, 
the guard succeeds instead of failing.

As of revision 3, there is no printed representation for objects such as 
vecctors and hashtables. 
They all print out generically like "<prim:abcd>".

Currently only the "build-posix" script exists for building on unices.
Though it is trivial to build muSE - just load all sources in your
favourite IDE and hit build - it'll be nice to have that ready for a few
platforms at least.

As of v180 in muSE, in-stream byte arrays are notated as #nnnn[data].
Standard scheme notates it as #"data" with the length determined automatically.

I'd like to keep the explicit length while providing some compatibility for
using standard scheme-like byte strings. The explicit length version is
effective during transmission of large chunks of data 'cos there is no need
for escape codes.

Proposal: Support both #"blah" and #4"blah" notations for in-stream byte
arrays.

What steps will reproduce the problem?
Use sort! or sort on a large list - over say 5000 elements. The stack will
blow.

What is the expected output? What do you see instead?
The sort should succeed.