On Sun, Jul 15, 2012 at 6:38 AM, Alan Manuel Gloria <almkg...@gmail.com> wrote:
> On Sun, Jul 15, 2012 at 5:54 AM, David A. Wheeler <dwhee...@dwheeler.com> 
> wrote:
>> Alan Manuel Gloria <almkg...@gmail.com>
>>> In any case, the "correct" way to replace the reader in 1.8 and 2.0
>>> and later is to use the current-reader fluid, but this isn't
>>> compatible with 1.6, and for reasons of my own I want compatibility
>>> with Guile 1.6 1.8 and 2.0.
>>
>> We definitely want maximum compatibility, especially in the long run.   This 
>> task is basically simple text processing, nearly all of it should be 
>> extremely portable!!   I really want configuration/installation to be 
>> completely automated in the long term (we could use autoconf, cmake, or 
>> something else).  If we have to *pick* a specific target (at least as a 
>> default), for the Scheme code I think we should start by supporting guile 
>> 1.8 and 2.0; guile 1.6 is kind of long in the tooth.  But we *should* be 
>> able to support guile 1.6 & many others without serious problems.

I need to support guile 1.6 because that's all that's installed in my
day job, and the reason I'm here in readable-discuss is because I'm
going to write a tool (that I might use on my day job) in scheme, and
I got spoiled on Haskell and now I want indentation on my code.  So
even if you officially drop support for guile 1.6, I'm still going to
hack your code to support it ;) Hey, guile's official site still posts
1.6 as the very old stable series, and thus I assume hasn't actually
dropped support (unlike 1.4, which they no longer mention)

>>
>> Scheme's "eval" has variants.  I'm planning to pull it out to a separate 
>> "my-eval" function, so that it can be easily replaced/edited, and switch to 
>> R5RS's version as a default (see below).
>>
>> --- David A. Wheeler
>>
>> =========================================
>>
>> --- a/sugar.scm
>> +++ b/sugar.scm
>> @@ -54,6 +54,10 @@
>>  ; these only exist in guile
>>  (define sugar-load-save primitive-load)
>>  (define sugar-current-load-port-save current-load-port)
>> +
>> +(define (my-eval inp)
>> +  ; Scheme R5RS eval *requires* 2 arguments.
>> +  (eval inp (interaction-environment)))
>>  ;----GUILE ENDS
>>
>>  (define group 'group)
>> @@ -339,8 +343,7 @@
>>          (if (eof-object? inp)
>>              #t
>>              (begin
>> -              ; TODO: Scheme R5RS eval *requires* 2 arguments.
>> -              (eval inp)
>> +              (my-eval inp)
>>                (load port)))))
>>    (load (open-input-file filename)))
>>
>
> Hmm, in the code above you are putting it in between the "GUILE BEGINS
> - GUILE ENDS" pair, which I added so that we could mindlessly delete
> it when trying on non-Guile implementations.  Is this deliberate?  I
> think you are trying to make a portability layer.
>
> And I think you should really use (current-module) for Guile, not
> (interaction-environment). so as to work properly with how Guile's
> module system works.

Although now that I've sourcedived into Guile 1.6.8, it seems that
interaction-environment() just calls into current-module().

SCM_DEFINE (scm_interaction_environment, "interaction-environment", 0, 0, 0,
            (),
            "Return a specifier for the environment that contains\n"
            "implementation--defined bindings, typically a superset of those\n"
            "listed in the report.  The intent is that this procedure will\n"
            "return the environment in which the implementation would\n"
            "evaluate expressions dynamically typed by the user.")
#define FUNC_NAME s_scm_interaction_environment
{
  return scm_current_module ();
}
#undef FUNC_NAME

So maybe interaction-environment is indeed more portable.

Sincerely,
AmkG

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Reply via email to