guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unknown location: definition in expression context in subform optnam


From: Bruce Korb
Subject: Re: unknown location: definition in expression context in subform optname-from of "_^"
Date: Sun, 29 Jan 2012 13:14:46 -0800

Hi Andy,

On Sun, Jan 29, 2012 at 12:28 PM, Andy Wingo <address@hidden> wrote:
>  * Bruce's original problem statement says nothing about columns.

That's because I, personally, in my application, didn't put forth the effort
originally (~15 years ago) and it's "too hard" to retrofit.

>  * The eval-string introduced in 2.0.1 does add a #:column facility.
>    It also adds #:module, #:lang, and #:compile?.

It was only recently I dropped support for Guile 1.4 and I still support 1.6.
Translation: I may be dead before 1.8 could be desupported.

>  * All things being equal, writing Guile functionality in Scheme is
>    better than in C.  (Note the caveat, please.)

Is Guile intended as the be-all and end-all in application languages,
or as an "extension language".  It was initially billed as an "extension
language", tho, I confess, it's been over a decade since I started using it.

>    As a corrolary, for it to make little difference to C code what
>    language something is implemented in, it needs to be easy to call
>    Scheme from C without creating C bindings.  (Note that there is a
>    difference between "easy" and "familiar"; Rich Hickey's "Simple Made
>    Easy" presentation deals with this point at some length.)

Amen.

> The proposed scm_c_eval_string_from_file_line does not allow for #:lang.
> It also has a trailing boolean argument, which is something of an
> antipattern.

Something of precisely what I, personally, needed, with little to no
concern over being applied to variations on a theme.  It was presented
more as a "Here's my problem, here's my hack around it, *please*
come up with something better."  And you have.  Thank you.
I look forward to using it and getting that cruft out of my code.

> Keyword arguments suit this task much better.

Indeed.  I certainly agree that that is better for supporting so many
variations.

>> Our current API encourages sloppiness by making it tedious to do the
>> right thing.  We provide a very convenient interface to evaluate a C
>> string without source information, thus encouraging coders to use that
>> even if source information is conveniently available to them.  It seems
>> to me that we should provide equally convenient means of doing the right
>> thing.
>
> This is true.

Amen.  "vehement agreement" here. :)

Regards, Bruce



reply via email to

[Prev in Thread] Current Thread [Next in Thread]