[ANN] Guile Curses Bindings: 0.2
Guile bindings for the NCurses libraries (curses, panel, form, and menu) have been updated and are to be found at http://gano.sourceforge.net/ This wrapset is now feature complete. The docs need scrubbing, but, are nearly complete. As a consequence, I'm calling this "beta". It has been tested on Guile 1.8.x on an oldish GNU/Linux and on Cygwin.
Re: Me no understand scoping
2008/8/1 Clinton Ebadi <[EMAIL PROTECTED]>: > > module-define! MODULE NAME VALUE > > e.g. > (let ((foo 'bar)) > (module-define! (current-module) foo 5) > bar) > => 5 > > Issue: this will be a top level binding, but a solution using `eval' > would also produce a top level binding (as it executes there to allow > lexical environments to be optimized...). I've been trying to make it using local-eval to be able to make a definition within a closure. There's only a tiny problem: it's not working. When I execute: (local-eval (list 'define a 5) (the-environment)) everything works fine, but when I make a function of it, (define (define@ name value) (local-eval (list 'define name value) (the-environment))) and when I invoke it, it breaks with "Bad define placement". The problem gets solved when I make a macro of it: (define-macro (define@ name value) `(local-eval (list define ,name ,value)(the-environment))) but it still breaks when called from a nested local-eval. > Doing such things, however, is fairly unschemey. What things and why? What I'm trying to do is to understand the rules of making and using environments. As for now, these rules seem to be quite random and unpredictable (so it's rather hard to call them rules actually), which is sad because closures are a very powerful yet simple mechanism (definitely simpler than what GOOPS or CLOS have to offer if it comes to OOP -- both in concepts and implementation) See you around :) M.
Re: Me no understand scoping
Time to trot out the tired old koan [1] ... Maciek Godek wrote: which is sad because closures are a very powerful yet simple mechanism (definitely simpler than what GOOPS or CLOS have to offer if it comes to OOP -- both in concepts and implementation) " The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." " Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. " On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. [1] http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html
