Hi Mike,
On Tue 24 Jan 2012 07:08, Mike Gran writes:
> My beef is with potentially removing the ability to use an integer seed in
> seed->random-state. It is useful and common. Many other languages
> and schemes do it the same way. Its strengths and limitations are
> indicated in the manual.
Andy Wingo writes:
> On Mon 23 Jan 2012 22:03, Mark H Weaver writes:
>> Your priorities are reversed from what they ought to be.
>>
>> What you _should_ be worried about is making commitments in our API that
>> we must continue to support forever. This is a _real_ problem, since it
>> constrain
Peter TB Brett writes:
> It seems pretty clear to me that the only (debatable) downside to
> using Mark's implementation is that some definitions end up in the
> "wrong" module, while your implementation has several potentially
> *major* problems (including the necessity of providing universally
On Tue 24 Jan 2012 11:30, Peter TB Brett writes:
> It seems pretty clear to me that the only (debatable) downside to using
> Mark's implementation is that some definitions end up in the "wrong"
> module, while your implementation has several potentially *major*
> problems (including the necessity
Hi Mark,
On Tue 24 Jan 2012 03:11, Mark H Weaver writes:
> you seem unabashedly content to lock us into using psyntax forever,
This statement is an exaggeration. While I am content with psyntax now,
all change is possible, with time. While it's important to think of the
future (and the past),
Andy Wingo writes:
> On Tue 24 Jan 2012 11:30, Peter TB Brett writes:
>
>> It seems pretty clear to me that the only (debatable) downside to using
>> Mark's implementation is that some definitions end up in the "wrong"
>> module, while your implementation has several potentially *major*
>> probl
Hi Andy,
I'm worried about this change you recently committed:
> diff --git a/module/ice-9/psyntax.scm b/module/ice-9/psyntax.scm
> index 1bf3c32..fd33e98 100644
> --- a/module/ice-9/psyntax.scm
> +++ b/module/ice-9/psyntax.scm
> @@ -636,7 +636,12 @@
> ;; labels must be comparable with "eq?"
Hello,
>> If we can already foresee the need to deprecate an interface, wouldn't
>> it be better not to add it in the first place?
>
> I don't see the need to deprecate them now, not more than any other
> identifier that we export.
I think this may be the key to this argument. There are two separ
On Tue 24 Jan 2012 14:25, Mark H Weaver writes:
> I don't see why we need universally-unique gensyms
> I've already explained why they are not needed
> for macros compiled in another session.
Ah, I forgot to reply to that. I found it:
On Mon 16 Jan 2012 14:28, Mark H Weaver writes:
> The rea
Hello Mark :)
Thanks again for your deep thoughts. This conversation is a bit
stressful for the both of us, but we wouldn't be having it if we didn't
both care about Guile.
In the spirit of diffusing tension here, feel free to imagine all of my
words as coming from Mr. Collins for the duration o
On Tue 24 Jan 2012 15:01, Mark H Weaver writes:
> `local-eval' combines syntax objects from two different sessions into a
> single syntax object (in the wrapper procedure), and thus there may be
> label name collisions. Now, if this combined syntax object is
> serialized as a compiled procedure,
Hi David,
On Fri 20 Jan 2012 19:17, David Pirotte writes:
> guile 2.0.3.150-88c0
> guile-lib release-0.2.1-2-ge9fe22b
>
> ...
> make[1]: Entering directory `/usr/local/src/guile-lib/git-clone/src'
> ../dev-environ /usr/local/bin/guile-tools compile -o "text/parse-lalr.go"
> "
Andy Wingo writes:
> (define-syntax-rule (define-const x val)
> (begin
> (define t val)
> (define-syntax x (identifier-syntax t
>
> Here, `t' will have a fresh mark.
>
> Now, if in one compilation unit, I do:
>
> (define-const x 10)
>
> And in another, I do:
>
> (let ((t
Andy Wingo writes:
> On Tue 24 Jan 2012 15:01, Mark H Weaver writes:
>
>> `local-eval' combines syntax objects from two different sessions into a
>> single syntax object (in the wrapper procedure), and thus there may be
>> label name collisions. Now, if this combined syntax object is
>> seriali
Andy Wingo writes:
> In the spirit of diffusing tension here, feel free to imagine all of my
> words as coming from Mr. Collins for the duration of this thread ;-)
Hehe :)
> On Tue 24 Jan 2012 14:25, Mark H Weaver writes:
>
>> Andy Wingo writes:
>>
>>> None of the interfaces that I proposed le
Hi,
1. module level macro bindings are reachable already with the api. so
beeing able to reach locally
defined one as well can be seen as a way to make that feature complete.
2. (define-syntax name val) (let-syntax ((name val)) ...) etc should be
aboute
creating bindings and hence the binding val
16 matches
Mail list logo
