Ken Raeburn wrote:
On Jul 22, 2009, at 05:11, Daniel Kraft wrote:
It seemed really hard to me to find at least *basic* information about
how the lexbind things works; I did build now an emacs with lexbind
from trunk, but so far as I see this is not meant to implement
"lexical-let" as the cl pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Kraft wrote:
> Hi Marijn,
>
> Marijn Schouten (hkBst) wrote:
>> Guile also has lexical and dynamic variables; the fluids[1]. Queinnec
>> in his
>> book LiSP also describes a system that has (default) lexical and dynamic
>> variable, on page 44.
On Thu, Jul 23, 2009 at 05:24:30PM +0200, Marijn Schouten (hkBst) wrote:
> For the calls above all the dynamic accesses can be determined statically.
> Lexical accesses can always be determined statically. Thus all accesses in
> this
> example can be determined statically and can be compiled to a
Hi,
thanks for your comments; I'm still a bit confused, though :$
Marijn Schouten (hkBst) wrote:
What's about this:
(defun test () a)
(let ((a 1))
(print a) ; 1
(print (test)) ; 1
(lexical-set! a 2)
there is only one variable `a' in my mental model,
so this changes the value of the only
On Tue 21 Jul 2009 15:10, Daniel Kraft writes:
> Just a little addition to the subject of extensions: I'd very much like
> to add lexical-let and lexical-let* as another set of extensions,
> because this gives the possibility to use "fast" lexical variables
> without the dynamic-scoping-fluid-pa
Hi Daniel!
Reviewing (and merging as much as possible of) your elisp branch is my
next Guile task, after taking care of that bug recently reported by
Martin Ward. Should be short work at this point.
This is a little late, but fwiw...
On Thu 16 Jul 2009 15:47, Daniel Kraft writes:
> I think I g
Hi Daniel,
On Mon 20 Jul 2009 19:53, Daniel Kraft writes:
> in the %nil thread a suggestion was brought up to support the `flet'
> construct (and `flet*' as well, if we choose to do so at all, I favour)
> in Guile's upcoming elisp implementation that behaves just like a let
> for function-slot b
Hi Ludovic,
This isn't a review really, because I changed the code in question... I
hope you find the new analyze-lexicals procedure easier to understand.
It's certainly better documented :)
On Thu 02 Jul 2009 19:35, l...@gnu.org (Ludovic Courtès) writes:
> l...@gnu.org (Ludovic Courtès) writes:
Hello!
Andy Wingo writes:
> I've finished up my refactor of Guile's arrays. To my eye it's much
> nicer now.
Hey, great!
Several general remarks:
* Since I'm conservative and lazy, I'd have happily let this code rest
in peace. ;-)
In particular, last time I checked[*], we had poor
Hi,
Just for the record :)
On Thu 23 Jul 2009 18:13, Mark H Weaver writes:
> On Thu, Jul 23, 2009 at 05:24:30PM +0200, Marijn Schouten (hkBst) wrote:
>> For the calls above all the dynamic accesses can be determined statically.
>> Lexical accesses can always be determined statically. Thus all a
Hi szgyg,
I can't recall where we were with this.
1. psyntax-pp.scm sometimes regenerating itself
2. some kind of segfault related to stack sizes on cygwin
3. The following:
On Tue 07 Jul 2009 17:53, szgyg writes:
> That segfault was an fd_set overflow. We should
> #define FD_SETSIZE 1024
>
Hi,
On Thu 23 Jul 2009 12:47, Daniel Kraft writes:
> Ken Raeburn wrote:
>> On Jul 22, 2009, at 05:11, Daniel Kraft wrote:
>>> It seemed really hard to me to find at least *basic* information
>>> about how the lexbind things works; I did build now an emacs with
>>> lexbind from trunk, but so far
On Wed 22 Jul 2009 11:11, Daniel Kraft writes:
> And checks with the cl package's implementation of lexical-let give the
> result, that an inner let does the same as if it was another
> lexical-let; that is, does not revert to dynamic binding but rather sets
> only the lexical value.
Interesting
¡Hola!
Andy Wingo writes:
> OK, here's another idea. Why don't we keep this as a separate pass --
> enabled if you pass a compilation option. That way it can be more
> functional, and you can keep approximate source information.
By "pass", you mean a new "language" in the tower? As in
`lookup-
Hi Juhani,
On Thu 02 Jul 2009 17:49, Juhani Viheräkoski writes:
>> > With recent changes in guile vm there are lots on improvements on the
>> > Gambit benchmarks.
>>
>> Improvements compared to what?
>
> I should have been more concise..
You were concise, but not precise ;-)
So here's a proje
Hi,
On Mon 20 Jul 2009 11:20, l...@gnu.org (Ludovic Courtès) writes:
> Neil Jerram writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Andy Wingo writes:
>
> [...]
>
Array_handle_release is a bad idea.
>>>
>>> Fair enough.
>>
>> FWIW, I agree (I think with both of you) that `we migh
On Fri 03 Jul 2009 17:32, Mark H Weaver writes:
> It might be worth considering a build-time option to disable %nil, so
> that it's possible to build a version of guile which doesn't pay this
> price.
You probably found it, but Guile does have such an option.
(Jeez, I didn't think I'd ever find
On Tue 14 Jul 2009 17:15, l...@gnu.org (Ludovic Courtès) writes:
> Note to Andy: the GCS recommends against assignments in `if' expressions
> (info "(standards)Syntactic Conventions"). :-)
Ooooh, bummer. I've grown to like these :)
I also like the comma operator :)
Anyway, will avoid in the fu
On Fri 03 Jul 2009 02:04, Andreas Rottmann writes:
> Playing around with Guile's now-in-core syntax-case support (using Git
> HEAD as of today), I found that quasisyntax seems quite broken:
We've spoken over IRC since then, but for those that do not frequent
there, it's simply not implemented. Y
Hi Mark,
This is also not a patch review yet :)
On Thu 09 Jul 2009 18:11, Mark H Weaver writes:
> I added the following macros, whose names explicitly state how %nil
> should be handled. See the comments in the patch for more information
> about these.
>
> scm_is_false_assume_not_lisp_nil s
On Jul 23, 2009, at 16:46, Andy Wingo wrote:
On Tue 21 Jul 2009 15:10, Daniel Kraft writes:
Just a little addition to the subject of extensions: I'd very much
like
to add lexical-let and lexical-let* as another set of extensions,
because this gives the possibility to use "fast" lexical varia
Neil Jerram writes:
> I'm afraid a whole weekend is not possible for me, as it's family
> time. Is during the following week (24th-28th) any good for you?
Yes, on the 24th. (I'd probably take this opportunity to walk with my
relatives in the mountains the day(s) before.)
> You'd be very welco
On Tue 14 Jul 2009 10:07, Neil Jerram writes:
> but the right thing to do is to fix the scm_set_source_properties_x ()
> code.
Yes, this would be better.
Andy
--
http://wingolog.org/
On Sun 12 Jul 2009 17:21, Mike Gran writes:
> I'm finding that master fails to build with the following terminating
> error:
>
> ---
>
> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
> "ice-9/lineio.go" "ice-9/lineio.scm"
> ERROR: In procedure make_objcode_by_mmap:
> ERROR:
Hello!
On Tue 14 Jul 2009 21:48, Daniel Kraft writes:
> (defun primep (p &optional from)
> (let ((i (if from from 2)))
> (while (and (/= (% p i) 0) (<= (* i i) p))
> (setq i (1+ i)))
> (/= (% p i) 0)))
>
> (primep 1283939) -> #t
This is fantastic.
> While of course the #f shoul
On Wed 15 Jul 2009 00:05, l...@gnu.org (Ludovic Courtès) writes:
>>> Then it could also try to interpret version numbers and determine
>>> whether that bytecode is really incompatible, or whether it can
>>> interpret it.
>>
>> Are there scenarios where that would be worthwhile?
>
> Maybe, e.g., wh
On Wed 15 Jul 2009 10:36, Daniel Kraft writes:
> Ludovic Courtès wrote:
>>> as well as found a (hopefully good) solution to automatically create
>>> fluids not yet present on reference.
>>
>> Is each Elisp variable mapped to a fluid? Eventually, you may need VM
>> instructions for fluid-{ref,se
Andy Wingo writes:
> On Fri 03 Jul 2009 02:04, Andreas Rottmann writes:
>
>> Playing around with Guile's now-in-core syntax-case support (using Git
>> HEAD as of today), I found that quasisyntax seems quite broken:
>
> We've spoken over IRC since then, but for those that do not frequent
> there,
On Mon 20 Jul 2009 21:09, "Kjetil S. Matheussen"
writes:
> On Mon, 20 Jul 2009, Bill Schottstaedt wrote:
>
>> For some reason, this code strikes me as funny:
>>
>> (let ((j (lambda () 0))
>> (k 0))
>> (do ((i (j) (j))
>>(j (lambda () 1) (lambda () (+ i 1
>> ((= i 3) k)
On Mon 20 Jul 2009 05:33, Ken Raeburn writes:
> On Jul 19, 2009, at 16:10, Neil Jerram wrote:
>>> BTW, I implemented also the function bindings of symbols using this
>>> fluid-based dynamic scoping at the moment -- but on second thought,
>>> there's no scoping at all for function slots (all are g
On Tue 21 Jul 2009 21:48, Daniel Kraft writes:
> (defvar x 1)
> (defun foo () x)
> (lexical-let ((x 2))
> x ; -> 2
> (foo) ; -> 1
> (setq x 3)
> x ; -> 3
> (foo) ; -> 1
> (let ((x 4))
> x ; -> 4?
> (foo) ; -> 4
> (setq x 5)
> x ; -> 5
> (foo) ; -> 5
> ) ; end t
On Thu 23 Jul 2009 23:53, Ken Raeburn writes:
> On Jul 23, 2009, at 16:46, Andy Wingo wrote:
>> On Tue 21 Jul 2009 15:10, Daniel Kraft writes:
>> Just a little addition to the subject of extensions: I'd very much
>> like
>>> to add lexical-let and lexical-let* as another set of extensions,
>>>
On Thu 23 Jul 2009 23:21, l...@gnu.org (Ludovic Courtès) writes:
> ¡Hola!
>
> Andy Wingo writes:
>
>> OK, here's another idea. Why don't we keep this as a separate pass --
>> enabled if you pass a compilation option. That way it can be more
>> functional, and you can keep approximate source infor
Hi,
On Fri 24 Jul 2009 00:35, Andreas Rottmann writes:
> Andy Wingo writes:
>
>> On Fri 03 Jul 2009 02:04, Andreas Rottmann writes:
>>
>>> Playing around with Guile's now-in-core syntax-case support (using Git
>>> HEAD as of today), I found that quasisyntax seems quite broken:
>>
>> We've spok
Hi Andy,
thanks for your comments!
Andy Wingo wrote:
Reviewing (and merging as much as possible of) your elisp branch is my
next Guile task, after taking care of that bug recently reported by
Martin Ward. Should be short work at this point.
Cool! But just take your time ;)
At least, is the
Andy Wingo wrote:
in the %nil thread a suggestion was brought up to support the `flet'
construct (and `flet*' as well, if we choose to do so at all, I favour)
in Guile's upcoming elisp implementation that behaves just like a let
for function-slot bindings, enabling dynamic scoping for them.
It i
Andy Wingo wrote:
On Tue 21 Jul 2009 15:10, Daniel Kraft writes:
Just a little addition to the subject of extensions: I'd very much like
to add lexical-let and lexical-let* as another set of extensions,
because this gives the possibility to use "fast" lexical variables
without the dynamic-sco
Andy Wingo wrote:
I'll keep in mind also the lexbind idea of optionally making every
binding lexical. Andy, can you give me a hint/example/pointer how
compiler options work? This would be exactly the place to provide this,
I think. Additionally we could add an option to remove the "variable is
38 matches
Mail list logo
