From: Borislav I. <bor...@ko...> - 2004-04-05 17:49:09
|
Hi, | Yes, unfortunately, the psyntax stuff is pretty difficult to | use. The reason is that it starts out with a letrec with 141 | functions that have been alpha substituted (uniquely | renamed). And these get printed out during the backtrace, | and are fairly useless. I think things are blowing up | because a old define-macro is being defined and the new | macroexapnder blows up for some reason. I'll need to look at this. | | I'll send some code for avoidng loading files twice. | | One thing you might help would be to change the definitions | in the first letrec to be top level defines. I really would | like this to be easier to use. Would it be better if the whole macro system was compiled into Java and loaded all the time, by default? This would potentially make macros more efficient and also allow libraries to freely use macros without worrying about including psyntax. For instance, I am thinking of developing some sort of general documentation facility with macros. A function would be documented with some expression like this: (doc myfunction { general description of myfunction } (param a { description of param a} ) (param b { description of param b} ) (returns { description of return value} ) ) This could then be used to generate help files, or to get information about a function while interacting with scheme: (info myfunction) => (myfunction a b): general description a: description of parameter a etc... I think this would be extremely useful. Even scheme primitives could be documented this way. I'm sure I could use many of the goodies in "elf/*", but there are simply not documented and only to know what's available, I have to read through the source files. Documentation would be included alongside the main code. One would also be able to able to search through the docs based on patterns (like in apropos or emacs) etc. Perhaps, even some sort of literate programming can be implemented by replacing top-level defines by a macro equivalent that processes documentation expressions within the body of the define separately: (define (myfunction a b) (info { myfunction computes the blabla of two numbers } ) (param a { a is the number that ...} ) (let (....) (doc { First, we test whether blabla} ) (if (blabla) (doc { if blabla indeed, then x is returned}) x etc... Hmm, maybe I'm dreaming too much. I have no idea how feasible this is - I only started learning how to use macros. In terms of readability of the resulting code, it shouldn't be a problem with appropriate syntax coloring for documentation "directives". BTW, don't know if this would be a good way to do it, but I patched my Netbeans plugin (which I use exclusively to interact with Jscheme) to implement your workaround in evaluating macros: // 'input' comes from InputPort.read() private static Object evalObject(Object input) { final Symbol EVAL = Symbol.intern("eval"); final Symbol QUOTE = Symbol.QUOTE; Pair to_eval = new Pair(EVAL, new Pair(new Pair(QUOTE, new Pair(input, Pair.EMPTY)), Pair.EMPTY)); return Scheme.eval(to_eval); } Perhaps, this can be used temporarily in jscheme.REPL is it's too complicated fixing "the right way". Best, Boris |