Hi Mark,
On Sat 14 Jan 2012 21:37, Mark H Weaver writes:
> If a top-level variable needs to be expanded in user code, then you'd
> better explicitly choose a stable name for it.
Indeed, this is the best solution, for interface stability.
But what should happen when users do introduce top-level
Hello!
Mark H Weaver skribis:
> Andy Wingo writes:
>
>> On Wed 16 Nov 2011 04:58, Mark H Weaver writes:
>>
>>> I think there are better ways to address this problem. I will explore
>>> these in another email.
>>
>> I look forward to this. Please be sure to address the following issues:
>>
>>
Mark H Weaver wrote:
> There's another option: we could properly track the compile-time
> dependencies of each module, and automatically consider a .go file stale
> if _any_ of its compile-time dependencies are newer than it.
>
> To be more specific: I think we need to record, in every syn
David Kastrup writes:
> Mark H Weaver writes:
>
>> Furthermore, we could provide distros with the necessary
>> infrastructure to automatically recompile guile modules as needed
>> after package upgrades.
>>
>> I know of at least one precedent for this behavior: the emacs packages
>> in Debian.
Mark H Weaver writes:
> Furthermore, we could provide distros with the necessary
> infrastructure to automatically recompile guile modules as needed
> after package upgrades.
>
> I know of at least one precedent for this behavior: the emacs packages
> in Debian. Last I checked, Debian had an ela
Andy Wingo writes:
> On Wed 16 Nov 2011 04:58, Mark H Weaver writes:
>
>> I think there are better ways to address this problem. I will explore
>> these in another email.
>
> I look forward to this. Please be sure to address the following issues:
>
> * Debian upgrading guile to a newer versi
Hi Mark,
On Wed 16 Nov 2011 04:58, Mark H Weaver writes:
> Even if the tradeoff you chose were justified (which I do not concede),
> I believe that you handled this commit improperly. In your message to
> the scheme-reports list, you clearly described what you did, were honest
> about the lack
Andy Wingo writes:
>> What you have implemented here is not Scheme, but rather something
>> that looks like Scheme and claims to be hygienic, but will in fact
>> break hygiene in many plausible cases.
>
> This statement galls me to no end. I don't even know how to reply to
> it. I have written a
On Thu 10 Nov 2011 17:46, Mark H Weaver writes:
>> I need to be able to allow distributors to release a new Guile binary
>> package without causing recompilation of user libraries. Of course
>> this requires some care in maintenance, so as to only make compatible
>> changes, but the trivial case
On Fri 11 Nov 2011 21:20, l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> Andy Wingo writes:
>>> On Thu 10 Nov 2011 05:36, Mark H Weaver writes:
What method do you use to uniquify a macro-introduced top-level name,
such that a recompile yields the same name? I ha
Hi,
Mark H Weaver skribis:
> Andy Wingo writes:
>> On Thu 10 Nov 2011 05:36, Mark H Weaver writes:
>>> What method do you use to uniquify a macro-introduced top-level name,
>>> such that a recompile yields the same name? I have doubts that this is
>>> possible without breaking hygiene in some
Hi Andy,
Andy Wingo writes:
> On Thu 10 Nov 2011 05:36, Mark H Weaver writes:
>> What method do you use to uniquify a macro-introduced top-level name,
>> such that a recompile yields the same name? I have doubts that this is
>> possible without breaking hygiene in some cases.
>
> See http://thr
Hi Mark,
On Thu 10 Nov 2011 05:36, Mark H Weaver writes:
> Hi Andy,
>
> What method do you use to uniquify a macro-introduced top-level name,
> such that a recompile yields the same name? I have doubts that this is
> possible without breaking hygiene in some cases.
See http://thread.gmane.org/
Hi Andy,
> commit de41e56492666801078e73860a358e1c63cbc8c2
> Author: Andy Wingo
> Date: Fri Nov 4 19:34:22 2011 +0100
>
> hygienically rename macro-introduced bindings, reproducibly
>
> * module/ice-9/psyntax.scm (chi-top-sequence): Detect bindings to
> identifiers introduce
14 matches
Mail list logo
