> Yes, I think this is the thing to do.
>
> Can you rework your patch, Noah?
Will do.
Here it is.
On Sun, Feb 13, 2011 at 3:10 PM, Noah Lavine wrote:
>> Yes, I think this is the thing to do.
>>
>> Can you rework your patch, Noah?
>
> Will do.
>
0001-Set-sockaddr_in.sin_len-field-when-it-exists.patch
Description: Binary data
n Sun, Feb 13, 2011 at 2:19 PM, Andy Wingo wrote:
> Hi Noah,
>
> I think it makes sense to have a reader that actually returns comments.
> That, to me, is the general solution: the REPL reader just treats a
> comment as whitespace.
>
> On Sun 13 Feb 2011 16:22, Noah Lavine wr
Hello,
> Nice! Can you add a test case?
I've thought about it, and I'm not sure how to do it well. The trouble
is that this only applies to the REPL, not scripts. So a test would
have to wrap the REPL in something and make sure its output is right.
I might be able to do that, but if I just comp
d there is some interaction between modules
and syntax generators that I don't understand.
The patch will apply to the wip-mlucy branch.
Thanks,
Noah
On Fri, Feb 18, 2011 at 5:03 PM, Andy Wingo wrote:
> On Wed 02 Feb 2011 01:26, Noah Lavine writes:
>
>> Here it is! All of the un
Hello,
I think the list you want is in Guile's README file, which says that
Guile depends on these libraries:
- libgmp
- libiconv
- libintl
- libltdl
- libunistring
- libgc
- libffi
Unless of course I misunderstood your question.
Noah
On Mon, Feb 28, 2011 at 2:13 PM, Bruce Korb wrote:
> Thank
Hello all,
I believe what I'm saying is equivalent to what Andreas said, but let
me put it in this way: I think the Right Thing to do is to change what
we think of as a name - instead of a name being a symbol, a name would
be a symbol plus the environment it was defined in (which is what a
syntax
nicer chunks.
Noah
On Fri, Mar 4, 2011 at 5:52 AM, Andy Wingo wrote:
> On Wed 23 Feb 2011 16:10, Noah Lavine writes:
>
>> I need to ask for help in order to work on this more. I thought I
>> would first move the code-generating functions to their own module. It
>> seems like
Yes, welcome! It's great to have you!
On Fri, Mar 4, 2011 at 4:28 PM, Neil Jerram wrote:
> Andy Wingo writes:
>
>> Hey all,
>>
>> Let's welcome new contributor Mark Harig! Mark is interested in
>> documentation, but who knows to what nooks and hollows of Guile the hack
>> will lead. Welcome ab
Here's another patch, which in retrospect may be the most useful of
the series. It adds a section called "PEG Internals" to the manual,
and begins documenting how PEG actually works. This should make
hacking PEG a lot easier.
Noah
On Sun, Mar 6, 2011 at 12:25 AM, Noah Lavine wro
I've been toying with the idea of an AOT compiler for Guile, and I
think that would make a good summer project.
I think you'd want to compile from Tree-IL to GCC's GIMPLE format (the
highest-level intermediate representation they have, I think). One
interesting possibility would be basing it on St
Also, about your CPAN for guile (CGAN?) idea - it seems like with what
you said about stowfs that what you're looking for is similar to Nix,
but used to install Guile packages. (www.nixos.org)
Do you think it would be useful to just compile a version of Nix with
a different root directory, make so
Hello,
> Really? I thought you were toying with JIT. :-)
Yes, it's been a while since we talked about that :-). I still want to
do it, though. The current status as I see it is that I have a
prototype JIT that works, and a plausible way to integrate it into
Guile's VM. What needs to happen now
Hello,
>> We talked about having a Scheme-based language that could compile to
>> both plain C and JIT, but decided that would make the VM too
>> complicated,
>
> Maybe I forgot to feed that thread, but I think it might be easier to
> have a high-level representation the VM opcodes as sexps (possi
Hello all,
Guile supports srfi-23 (the `error' procedure), and probably has
forever, but it's not documented. This patch adds a note in the manual
saying we support it, and also adds srfi-23 to our list of cond-expand
features that we support.
I think this is safe to apply to stable-2.0.
Noah
Hi,
> Not that I have any say in that, but IMHO, it would be preferable to
> keep external libraries maintained separatly from the Guile core;
> however in this case, including it in the core might be justified by its
> proposed use in the JIT compiler.
Yeah. I agree, actually.
> FWIW, there's a
Hello all,
I recently ran up against an issue about modules with circular
dependencies while working on PEG stuff. I reduced it to the following
test case.
Here is file "test-a.scm":
(define-module (test-a)
#:use-module (test-b))
(define-syntax hello
(syntax-rules ()
((hello) "Hello, wo
Hello,
> The problem is that modules are resolved at compile-time, in addition to
> run-time, so there just can’t be circular dependencies.
It's true that a module couldn't depend, at compile-time, on a module
that was only available at run-time. However, I think we could handle
circular dependen
Hello all,
>> Furthermore, such a default would not restrict our users at all -- they
>> can always use the non-_c_ variants with a symbol explicitly constructed
>> with (e.g.) scm_from_utf8_symbol.
>
> We have those convenience functions for a reason. You recently proposed
> several more conveni
Hello,
>> I think it would make sense to include ‘fmt’ in core Guile only if the
>> API is reasonably stable and there are infrequent upstream releases, so
>> we don’t quickly end up shipping an old incompatible version.
>
> Agreed, and I don't know if this is the case or not.
>
> I would add on a
Hi,
> I think the solution is to confront the circularity directly. It exists
> because the PEG s-exp grammar also deals with the string grammar, which
> needs an already-build PEG parser.
>
> Let's break it instead into layers without cycles: removing the string
> grammar from the s-exp code gen
> I've been working on that. The attached two patches break the
> circularity. The code still isn't organized brilliantly, but after
> applying these I think we would only want pretty minor cleanups before
> merging PEG into the main branch.
Actually, forget this bit. I wrote it before I remembere
> This last is the best. What if we define a module that serves as a
> registry of PEG match behaviors, like `(ice-9 peg matchers)'. Then we
> define `define-peg-matcher' or something, so that we can:
>
> (define-peg-matcher and cg-and)
>
> where define-peg-matcher is
>
> (define-syntax define-pe
The coolness is irrefutable. :-)
On Wed, Mar 30, 2011 at 7:08 AM, Andy Wingo wrote:
> Howdy,
>
> On Mon 21 Mar 2011 00:16, l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo writes:
>>
>>> "Guido, compile my-file.scm."
>>
>> Is the pun[*] intended? :-)
>
> OK, point taken. Too bad though!
Hello,
I'm no expert on what the project needs done, but I noticed your email
has been sitting for a few days with no reply. Have you been talking
to people on IRC?
Noah
On Mon, Mar 28, 2011 at 12:51 AM, Diogo F. S. Ramos wrote:
> Hello everybody,
>
> I've been following some discussions about
> Not since the e-mail. I'm still waiting for feedback.
I will tell you what I think, then, but keep in mind that many people
on this list know a lot more than I do.
The first idea is something I think Guile people are very interested
in, and you could expect to do significant work, possibly havi
29, 2011 at 9:20 AM, Andy Wingo wrote:
> On Tue 29 Mar 2011 14:47, Noah Lavine writes:
>
>>> (define-peg-matcher and cg-and)
>>
>> That's doable. But if we're going to choose what to do entirely based
>> on the first element of the list, then we could a
Hello,
Your ideas sound neat, but there are a few things I am not familiar with.
On Thu, Mar 31, 2011 at 10:31 AM, Diogo F. S. Ramos wrote:
>> What do you want to do in this area? There is important work to do with
>> introspection, but we would need to see your ideas and your code.
>
> You can
Hello,
Thanks for the advice!
I am in America (in the Eastern Time Zone, to be precise). I'm a
relatively new committer, which is why I haven't been advertising for
people to mentor, but I would be happy to help with anything I could.
Noah
On Mon, Apr 4, 2011 at 5:50 PM, Phil wrote:
> If anyon
Hello,
> There is one _very_ serious problem with using GCC to compile Scheme, or
> at least there was the last time I researched this issue: tail calls.
I might be wrong about this, but I thought that GCC supported multiple
calling conventions, with the user telling GCC which one to use
(cdecl,
5 AM, Mark H Weaver wrote:
> Noah Lavine writes:
>>> There is one _very_ serious problem with using GCC to compile Scheme, or
>>> at least there was the last time I researched this issue: tail calls.
>>
>> I might be wrong about this, but I thought that GCC supporte
Hello,
> 1. I think we shouldn’t augment the C API unless strictly necessary,
> because the idea is to write Scheme, not C, and because of the
> maintenance cost.
Why would we not want to augment the C API?
It seems like a natural complement to augmenting the Scheme API, since
Guile is
Hello,
> Regarding GCC, I have spoken to GCC folk, and they are not averse to
> making GCC into a more modular thing. There are obvious licensing
> concerns, but these are surmountable: Guile and GCC could work together
> somehow. The problem, as I understood it last year, was that GCC
> doesn't
You make good points, but I disagree. I think the ideal for Guile
should be a situation where C and Scheme can be used basically
interchangeably, with Guile providing the glue in between.
A situation like that would certainly lead people to write as much as
possible in Scheme, because if C and Sch
> Basically what you have to do is to sign up for the
> summer-of-c...@gnu.org list, and also go to
> http://www.google-melange.com/gsoc/org/google/gsoc2011/gnu, and apply to
> be a mentor. The number of spots is not decided finally until the 25th
> or so.
Done.
Hello,
I would be happy to mentor for SoC! I think it's a great program. I
can also promise that I'll have a lot more time to work on Guile stuff
over the summer than I do now, which should be perfect for SoC. :-)
My only questions are about logistics. Do I have to do any paperwork
or something l
Hello Guile and Clisp developers,
I'm writing to talk about vague big-picture ideas, but please bear
with me for a minute, because I think this could be useful.
I noticed in the recent GNU Summer of Code applications (I'm a mentor
for Guile) that CLisp wants to become embeddable, and embed into E
I think that mechanism is all that Guile uses at present. However, it
should be general enough to resolve all situations where variables of
the same name refer to different entities, assuming you set up the
environments correctly.
Are you planning on implementing a theorem prover for Guile? That w
> The beta rule is in denotational semantics something like
> ((lambda x . E_1) E_2) => [E_2/x]E_1, E_2 free for x in in E_1
> where [E_2/x]E_1 means substituting all free occurrences of x with E_2.
>
> In addition, one has the alpha rule
> (lambda x . E) => (lambda y . [y/x]E), y free for x in E
Hello,
> I think we should first compare the virtual machines.
>
>
> If no obvious impossibility is observed, then perhaps modifying the
> compiler of clisp to generate guile VM code would be an easy path to
> obtain a CL implementation running on guile VM. (This would disable the
> interpreter i
>> The fact that we represent different variables as gensyms is an
>> implementation detail, and unimportant. (In fact, I might like to
>> change that detail at some point to get better error messages, but
>> it's not high on my to-do list.)
>
> What are you referring to here?
It's just part of my
Hello all,
I just pushed some changes to the wip-peg branch. They eliminate the
last remaining circularity in the module imports and then add
everything to the Makefile. It passes all tests on my machine.
This is my first time pushing something, so I hope I did it correctly.
If the patches aren't
g the module which would be closed before the body of the
module. Perhaps if the first s-expression in a file is a module, then
the rest of the file could be an implicit (begin ...) form in the
module definition.
Thanks for all of your work on this
Noah Lavine
These are all good points. Integrating different languages is hard.
Quite frankly, I am not yet sure that sharing a VM would be a good
idea for us, but as we talk more about it it is seeming more and more
reasonable. I sent my original message because I saw that CLisp was
becoming an embeddable li
Hello all,
I'm afraid this email is coming much later in the planning process
than it should, and quite possibly we won't be able to do any of this
for SoC, and that's fine with me. But I was thinking about what we
could do that would be a "killer feature" for Guile's CPAN - something
that isn't a
Hello,
Let me clarify a bit about Lightning and the stuff I've been doing:
Lightning is a very low-level assembler framework. It is embeddable,
and Guile could certainly target it, but targeting Lightning would be
just a speed enhancement - it wouldn't make us more compatible with
anything else.
I don't know about the packaging, but I think the .go files depend on
the endianness of the machine but nothing else. So you should be able
to move them between different little-endian or big-endian machines
(unless I'm wrong). But it seems much safer to me to just compile
things. You shouldn't hav
> Well, IIRC, it's not a feature that "dorodango does not have" ;-):
> dordango's package container format (referred to as a "bundle") can
> contain multiple packages. So it is possible to pack all your
> dependencies in a single ZIP, and install them in one go using that
> bundle. There's a bit
I just looked at the code. It's really cool! This looks like a way to
write modules that use C and Scheme together in such a way that the
code is all in one place. I think it could be much easier to read code
written this way than code in separate C and Scheme files.
What do other people think?
N
Hello,
> I do not know how you are reading the Guile Reference
> Manual, but the printed version is about 809 pages long. At
> present, the indices run from page 755 to 809, so the
> revision that is suggested, above, would not be small.
>
> What would be of some help to get this project started
> Is anyone interested in implementing a path library?
>
> Andy
I might be able to work on it. I haven't done much for Guile lately,
but I expect to have a lot more free time once my semester ends on May
7th.
However, I don't know much about how Windows paths work. Are there any
special considera
ah
On Sun, May 1, 2011 at 7:54 AM, Andy Wingo wrote:
> On Sat 16 Apr 2011 00:04, Noah Lavine writes:
>
>> I just pushed some changes to the wip-peg branch. They eliminate the
>> last remaining circularity in the module imports and then add
>> everything to the Makefile.
> Yep! Check that racket web page I linked to. You don't have to
> implement all of it, but it should be possible to implement, given the
> path abstraction.
Okay, I've read it. It doesn't seem very complicated. Should we strive
for API compatibility? I don't see any programs needing it right no
Hello all,
I have another issue to raise. I think this is actually parallel to
some of the stuff in the (web) module, as you will see.
I've always thought it was ridiculous and hackish that I had to escape
spaces in path strings. For instance, I have a folder called "Getting
a Job" on my desktop,
That makes sense.
On Thu, May 5, 2011 at 11:24 AM, Andy Wingo wrote:
> Hello,
>
> If you call `map' or `for-each' with more than one list, our versions of
> these operators will detect if the lists are of unequal length, and
> throw an error in that case.
>
> However, SRFI-1 has long provided an
Cool!
On Fri, May 6, 2011 at 5:18 PM, Stefan Israelsson Tampe
wrote:
> Hi,
>
> Just wanted to chime in and tell you a little about what I'm doing with the
> guile-unify package.
>
> First off, this is a tool to do backtracking effectively e.g. tree searches
> and make heavy use of
> dynamic varia
strings to file system paths in a
clean way.
Noah
On Wed, May 4, 2011 at 5:24 AM, Ludovic Courtès wrote:
> Hi Noah,
>
> Noah Lavine writes:
>
>> The reason this strangeness enters is that path strings are actually
>> lists (or vectors) encoded as strings. Conceptually,
Hello,
Guile's Summer of Code project this summer was an implementation of
Emacs Lisp. I am curious - what is happening with that? Is it
progressing?
I follow the list, but haven't heard anything since the decision on
which project we wanted.
Noah
Hello,
I agree that this is much shorter, but I'm worried about defining the
short syntax in a way that forces you to choose between syntax-rules
and syntax-case. What I mean is that you could just as easily have
(define-syntax (foo bar)
...)
expand to
(define-syntax foo
(syntax-rules ()
> Except, it doesn't. My version doesn't insert either syntax-case or
> syntax-rules; it just inserts the lambda and lets you do whatever.
Oh, I must have been temporarily insane. My apologies. :-)
Your idea makes a lot of sense.
Noah
Hello all,
It's been a while, but I just got the wip-peg branch from the main
repository and tried to build it. After doing "make clean && make", I
get this error:
Undefined symbols:
"_rpl_open", referenced from:
_scm_open_file in libguile_2.0_la-fports.o
_scm_load_objcode in libgui
ls. My inbox is a
> bit lossy :)
>
> Cheers,
>
> Andy
>
> On Tue 06 Sep 2011 04:25, Noah Lavine writes:
>
>> I have fixed this. There is currently a branch on Savannah called
>> "wip-peg-fixed" which has all of the peg changes rebased on top of
&
This is excellent! Congratulations!
An interesting note from my current project: a partial evaluator means
you don't have to use macros to define the PEG parser (while keeping
exactly the same efficiency as now): instead of having (define-peg
pattern) be a macro that analyzes pattern and outputs c
Hello all,
It looks to me like the last thing needed before the peg branch can be
used is to change some of the S-expression representations of the
components. Here are the five that I think need changing, taken from
the manual, with suggested replacements.
-- PEG Pattern: zero or more a
Pa
Hello,
> The syntactic changes you propose all make sense to me, FWIW.
Great! Then I will push an implementation soon unless someone else objects.
> A more general question about PEG: how do you bind a variable to the
> result of a pattern? For instance, if you want the result of (* "a") to
> b
tructure out of a
match record.
I hadn't really looked at this part of the module, but it looks to me
now like the names aren't descriptive enough. Maybe we should change
them before putting this in a release.
Noah
On Sat, Sep 10, 2011 at 5:35 PM, Ludovic Courtès wrote:
> Hi!
>
> No
e easy for people to learn and forwards-compatible with
whatever our future plans for parsing are. I will try to send an email
soon with some thoughts on that.
Noah
On Sat, Sep 17, 2011 at 9:09 PM, Noah Lavine wrote:
> Hello,
>
>> Can you give an example of what ‘peg-parse’ and ‘peg:
Hello all,
I was just going through updating the PEG documentation when I
encountered a very weird situation, and I don't know how to solve it.
As you probably know, the PEG system can take an s-expression
representation of a PEG grammar (a "peg s-exp") and turn it into a
function that can parse s
Hello,
> It is complicated though. The other option is to write a PEG
> interpreter or compiler in Scheme. An interpreter would interpret the
> s-expressions directly, or some simplified form of them. A compiler
> would pre-process the s-expressions to produce a procedure, built from
> closures
Hello,
> If the s-expression is a compile-time constant, and if the PEG compiler
> is written in purely-functional style and confined within a single
> top-level form, then peval should be able to produce the parser
> procedure at compile-time. Otherwise, it would be produced at run-time.
>
> Thi
>> For instance, what about doing
>>
>> (compile (peg-sexp-compile ) #:from scheme-syntax
>> #:to value)
>>
>> ? That seems like a nice API to me.
>
> You could do the same with #:from 'scheme, no?
I don't think so, because I think #:from 'scheme expects an
S-expression, but peg-sexp-compile ret
Oh, excellent! I had assumed it did not. I will update the PEG documentation.
On Wed, Sep 21, 2011 at 3:22 PM, Andy Wingo wrote:
> On Wed 21 Sep 2011 20:44, Noah Lavine writes:
>
>> I think #:from 'scheme expects an S-expression, but peg-sexp-compile
>> returns a syntax o
Hello all,
As the PEG module nears some reasonable level of completion, we should
figure out what all of the functions need to be named so everyone can
reasonably understand them.
At first I thought the names should be consistent wtih the LALR and
regexp modules, so all of the parsing modules wou
Hello,
>> define-peg-sexp - define a nonterminal from an s-expression
>> define-peg-string - define a set of nonterminals from a string
>
> To me this sounds like you are defining an sexp or a string, which
> doesn't make much sense. I don't think that we need to preserve
> symmetry here, because
Hello all,
It looks to me like the PEG project is wrapping up. We're talking
about what to name things now, which means the library is likely
pretty close to inclusion in Guile. After this I will want another
Guile project to work on. My original intention was to work on a JIT
compiler for Guile,
Hello,
>> - You write a function that assumes its arguments are of a certain
>> type. You'd like to be sure this is true, so your program won't throw
>> exceptions in the middle.
>
> That would be cool. However, I suspect that for best results you’d want
> procedures to have type annotations, a
Hello,
> (Though I think that the term ‘constant’, as used by GCC, is confusing.
> I don’t have a better name to propose, though.)
How about 'algebraic'? As in functions in basic algebra. (I know it
has a different meaning, though.)
Or alternatively, something referencing the lambda calculus, si
Hello,
>> I think it can be done effectively, but I'm not quite sure what you
>> mean by "dynamic module composition." Do you mean that this might
>> prevent you from making modules that use arbitrary other modules? Or
>> that it might not work if you loaded modules at runtime from the REPL?
>
> I
I believe debian maintainers are responsible for packaging Guile for
Debian. You should contact whoever maintains the Guile package there.
I don't know anything about cygwin.
On Thu, Sep 29, 2011 at 6:38 AM, roman wrote:
> Hello,
>
> the last version of guile available for cygwin and debian/ubun
Hello,
I hate to make more work for people, but I think the PEG module is
almost ready for merging, and could probably be merged if we resolved
this names issue. Any other thoughts?
Noah
On Thu, Sep 22, 2011 at 1:56 PM, Noah Lavine wrote:
> Hello,
>
>>> define-peg-sexp - defin
Hello all,
Could anyone tell me the status of the ELisp implementation since July
21st (the last update)?
I'm especially interested now because of a thread on emacs-devel -
http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00753.html.
People were talking about adding multithreading to Emac
spect that most
people don't know what's happening or where to look. If you set up a
branch, I for one would love to check it out and perhaps contribute
some patches. Do you need permission from the Emacs maintainers to do
that, or anything else?
Noah
On Sun, Oct 9, 2011 at 9:37 AM, wrote:
> Hmm... this touches on a political issue I'd been avoiding thinking about.
> Namely, adding Guile to Emacs, with Guile's new FFI support, would make
> dynamically loading new executable code into Emacs easy, technically,
> including non-GPL code written specifically to extend Emacs. There's
Hello,
It seems like the right thing to do might be to do setlocale(LC_ALL,
"") in Guile's main(). Let me argue that this accomplishes two goals
which we want to accomplish
- it does the right thing by default: you want your program to be
able to talk to the user in the user's own language. This
Hello again,
I've been working on the compiler issue and I've had to start looking
at processing Tree-IL. As a result, I realized that the Tree-IL
documentation is a bit out-of-date. I would like to fix it, but there
are some things I don't understand.
- It looks like every Tree-IL type has a src
Hello,
> Record-case parses slots by name, not by position.
> Match destructures by position, not by name.
Oh, interesting.
>> - On a related note, why do most of the Tree-IL record type not appear
>> in the define-type statement in tree-il.scm line 133, and is that
>> connected with the bo
>> Then I have a new goal: understand that. :-)
>
> The deal is that macroexpansion produces tree-il. The usual
> macroexpander is provided by psyntax. But before psyntax is loaded,
> when the first bits of Scheme are seen, there is a boot expander written
> in C that produces tree-il, with suppo
Hello,
I am certainly not an authoritative source, but it's been a while, so
here is what I know. As far as I can tell, these questions haven't
been decided yet. All we know is that we want a guildhall.
However, having your packages in it would be great, so please do
package them up and contribut
> I guess in general I'd prefer something like Racket's #!lang directives,
> though I'm not opposed to this approach. Dunno!
How about using language directives when available, and trying to
guess the language when not?
And about the directives, what should they be? ',language' is what we
used t
Hello Guile developers,
Despite the long gap since my last email, I have in fact been working
on the compiler project. This email has two purposes: first, to make
sure that I have a basically reasonable design before I work more, and
second, to ask a logistical question.
First of all, I very much
Hello,
> This, however, is a lie, since there is no place above where "vectag"
> would be explained. There is an explanation about how it will be
> printed as part of an array, but not how it is specified.
>
> Would it please be possible
>
> a) to not just deprecate some function when there are _
Hello Guile developers,
Following up on my last email, I am nervously announcing a new branch,
'wip-compiler'. I hope that in a few months this branch will contain a
working compiler. For now, it contains a few new data structures and a
function that converts Tree-IL to a form that will be nicer f
> Cool. As a quick reaction, I have some doubts about this project. But,
> I guess a WIP branch would be a good thing to have, and it would make
> the discussion more concrete.
Probably so. But if you have time, what are your doubts? I would much
rather talk about problems now than after I've im
Hello,
I haven't really been contributing to this thread, so please take my
opinion with a grain of salt. But it does appear to me that we should
support capturing a lexical environment, as Mark and David describe.
So I took a look at ice-9/eval.scm to see how difficult it would be to
implement.
On Tue, Dec 13, 2011 at 6:39 PM, Andy Wingo wrote:
> On Wed 14 Dec 2011 00:00, Noah Lavine writes:
>
>> I haven't really been contributing to this thread, so please take my
>> opinion with a grain of salt. But it does appear to me that we should
>> support captur
> The details of the interpreter's implementation are not public, I'm
> afraid. The interpreter does its job, but not quickly, and any change
> to make it better would involve a change to the environment
> representation.
>
> Anyway, it's looking in the wrong place. There is a compiler too.
And
Perhaps this is obvious to everyone else, but it just occurred to me
that (capture-local-environment) is just
(call-with-current-continuation), but running in the environment of
the evaluator instead of the program being evaluated. It's as though
the evaluator was going to look in a tree for more c
On Thu, Dec 15, 2011 at 11:19 AM, Nala Ginrut wrote:
> well, I see. I haven't used Stalin before, so I guess the generated C code
> must be compiled without any Gcc extension?
I think he's making a joke that Richard Stallman is always pedantic,
so the -pedantic flag is redundant.
> @Noah: Anyway
Hello Guile developers,
I have recently hit an issue and I wish I knew a standard way to handle it.
I want to write tests for a module of mine. Because I like being
paranoid, I'd like to test almost every function in the module. But a
lot of these functions are internal to the module - there's no
Hello,
>> Indeed, only the macro expander has enough information to generate an
>> optimal list of "reachable lexicals", i.e. lexical variables that are
>> accessible using normal symbols (as opposed to syntax objects) [more
>> on this below].
>
> Are you certain that you want to restrict the set
101 - 200 of 420 matches
Mail list logo
