internal definitions is to be believed.
What I am saying is: congrats, you found a bug :)
Sorry about confusing you. I was never really sure about letrec* behaviour, but
you nerdsniped me and I spent some time reading the "fixing letrec (reloaded)"
paper, and now things are more clear.
-
side-effects and you don't move around side-effecting code.
If you do (display "heippa!") instead it works as you want.
I believe racket (which does the same optimization) has the same behaviour.
-- Linus Björnstam
Den 2023-09-24 kl. 09:09, skrev Dr. Arne Babenhauserheide:
Hi,
whi
Hi!
I have finally started getting some computer time again, and I will make sure
to get this into some kind of extra library in the official SRFI repo.
It will not be official, but maybe for a future SRFI based on SRFI 171.
--
Linus Björnstam
On Wed, 28 Jun 2023, at 14:27, Colin
http://wingolog.org/pub/fash.scm
--
Linus Björnstam
On Sat, 4 Mar 2023, at 12:22, Philip McGrath wrote:
> On Sat, Mar 4, 2023, at 5:28 AM, Linus Björnstam wrote:
>> Andy already has a fast implementation of functional hashtables
>> ("fash") which are of a particu
On Sat, 4 Mar 2023, at 17:38, pukkamustard wrote:
> Hi Dave,
>
> Makes me wonder, are Andy Wingo's fash/fector purely functional? Why do
> they need atomic boxes? Aren't they only necessary for destructive
> updates?
This is to make sure that transient-fectors/flashes (in-place mutation with
emoval which
should be trivial to add. Other than that it has all the basic functionality
needed to build a complex library on top.
--
Linus Björnstam
On Tue, 28 Feb 2023, at 18:03, Lassi Kortela wrote:
>> I've been thinking how it'd be nice to have available in Guile a number of
>
On Wed, 25 Jan 2023, at 16:38, Greg Troxel wrote:
> My reaction, without thinking much, and being fuzzy on a lot of things
> is that part of the point of guile is that it is Scheme which to me
> means RnRS conformance. Of course it's not exactly and every other
> Scheme impl is not exactly.
On Wed, 25 Jan 2023, at 16:09, Ludovic Courtès wrote:
> Hello!
>
> Linus Björnstam skribis:
>
>
> Daniel pushed this as 764e3614b8c13de604399572a67d071621e9ca21 in
> ‘main’. I had completely overlooked this thread but I wasn’t quite sure
> about it, so I did
;let-expression
body".
I will not have the ability to address anything nor actually send my updates
patch for what is probably months. If anyone wants to take over I would be
happy. For what it is worth, I have already signed a copyright assignment to
the FSF.
Best regards
Linus Bjö
of SRFI-171 code does
not.
I am not in any position to sign code off for inclusion in guile proper, but if
the define-public thing is fixed it very much has my blessing.
Best regards
Linus Björnstam
On Wed, 21 Dec 2022, at 01:48, Colin Woodbury wrote:
> Happy holidays everyone, I h
On Fri, 18 Nov 2022, at 11:22, Lassi Kortela wrote:
> R7RS defines the syntax of `let` et.al. as follows (section 3.5):
>
> (let (*) )
>
> Where:
>
> = *
> = *
>
> So their definition of lambda:
>
> (lambda * * )
>
> could be abbreviated:
>
> (lambda )
>
> I haven't read "Fixing letrec" but
ody is probably the
simplest way to express it.
best regards
Linus Björnstam
"is like the body of a lambda" be a better wording? That would imply that
at least one expression is required. English is very much not my first
language, and documentation changes are the ones that I fear the most...
best regards
Linus Björnstam
On Thu, 17 Nov 2022, at 08:25, l
Hi there!
This commit adds internal definitions to derived conditional forms, with-fluids
and and-let*. This means the bodies of when, unless and with-fluids, and the
clause bodies of case and cond behave like a lambda body.
There is no performance hit since guile optimizes a (let () ...)
appendix and add some error reporting.
The most difficult part is documenting it :)
Andy have the idea hos blessing, and will mean guile gets define in expression
context in when, unless, cond, case, while, and do as well as in derived forms.
--
Linus Björnstam
On Sat, 27 Aug 2022, at 18:48
the hashx-* functions for daredevils and
for future srfi needs) is the way to go.
Best regards
Linus Björnstam
On Mon, 21 Feb 2022, at 14:18, Stefan Israelsson Tampe wrote:
> A datastructure I fancy is hash tables. But I found out that hashtables
> in guile are really slow, How? First of all w
.
--
Linus Björnstam
On Sun, 6 Feb 2022, at 21:13, Stefan Israelsson Tampe wrote:
> Hmm just why conditionals use begin and not let,
>
> On Sun, Feb 6, 2022 at 11:49 AM wrote:
>> On Sun, Feb 06, 2022 at 10:45:54AM +0100, Linus Björnstam wrote:
>> > You need to use ,optimize.
You need to use ,optimize.
--
Linus Björnstam
On Sun, 6 Feb 2022, at 10:27, to...@tuxteam.de wrote:
> On Sun, Feb 06, 2022 at 07:44:31AM +0100, Linus Björnstam wrote:
>>
>> On Sat, 5 Feb 2022, at 18:31, Stefan Israelsson Tampe wrote:
>> > Hmm this was wrong, I mean
&
On Sat, 5 Feb 2022, at 18:31, Stefan Israelsson Tampe wrote:
> Hmm this was wrong, I mean
>
> For conditional variables we have a default begin. So then why on earth
> do you not have an implicit let?, Just laziness?
> There should be a good reason or? this is a pretty fundamental change
>
removes the last bodies in guile forms that have a definition context,
which may be confusing for beginners.
I would say that the compatibility question with the enforcing cond of rnrs is
the only thing that needs proper addressing.
Best
Linus Björnstam
On Wed, 16 Jun 2021, at 21:11, Linus
). If you
want to discuss some ideas or have any question we can take this off-list.
Another thing would be to not use call/cc in the def form. Let/ec is a lot
faster.
--
Linus Björnstam
On Mon, 20 Dec 2021, at 01:05, Damien Mattei wrote:
> Hi,
> I finished today the first version of
believe libgccjit would be a
step sideways considering the above.
Best regards
Linus Björnstam
On Sun, 10 Oct 2021, at 01:06, Andy Tai wrote:
> can guile make use of libgccjit?
>
> would be an interesting optional addition to guile
thing, even though we will provide 2 cons
and case forms to do that.
--
Linus Björnstam
On Thu, 17 Jun 2021, at 11:06, Maxime Devos wrote:
> Linus Björnstam schreef op wo 16-06-2021 om 21:11 [+0200]:
> > Hi there!
> >
> > This patch updates some derived conditional form
Hi there!
This patch updates some derived conditional forms (and do and and-let*) to
support definitions in expression context. Meaning it makes this valid code:
(cond
((pred? arg)
(define a (something arg))
(when (error-case a)
(error "a is broken"))
(define b (something2
in a very nice direction for some time!
--
Linus Björnstam
On Fri, 23 Apr 2021, at 17:00, Mikael Djurfeldt wrote:
> Hi,
>
> Yesterday, Andy committed new code to the compiler, some of which
> concerned skipping some arity checking.
>
> Also, Stefan meanwhile committe
find anything.
--
Linus Björnstam
On Thu, 8 Apr 2021, at 17:53, Arthur A. Gleckler wrote:
> On Tue, Jan 26, 2021 at 3:54 AM Linus Björnstam
> wrote:
> > The code's internet presence is apparently gone (bitbucket mercurial. I
> > don't know how I missed that ). I
om:
https://git.sr.ht/~bjoli/awesome-coroutine-generators
I tried to extend it while sober. It didn't work, so be warned I guess. The
code is somewhat a mess, but short enough to be understandable.
Best regards
Linus Björnstam
On Thu, 18 Feb 2021, at 18:24, Mike Gran wrote:
> Hello All-
>
!
--
Linus Björnstam
On Sat, 27 Feb 2021, at 10:39, Dr. Arne Babenhauserheide wrote:
> I’d like to contribute a basic implementation of the Web of Trust in
> Freenet that provides spam-detection without centralized control:
>
> https://hg.sr.ht/~arnebab/wispwot/browse/wispwot
, and if so: which one?
--
Linus Björnstam
On Thu, 18 Feb 2021, at 08:34, Linus Björnstam wrote:
> Hi there!
>
> I was spelunking through the guile source tree and found (rnrs base).
> The vector-map and vector-for-each in there are horribly inefficient.
> They are doing (list
Hi there!
I was spelunking through the guile source tree and found (rnrs base). The
vector-map and vector-for-each in there are horribly inefficient. They are
doing (list->vector (apply map PROC (map vector->list vectors))), which means
it spends quite some time checking for circular
The code's internet presence is apparently gone (bitbucket mercurial. I don't
know how I missed that ). I won't have access to that code for about 2 weeks,
but I will upload it and try to get it up to par with the updated SRFI-158.
Lg. Linus Björnstam
On Tue, 26 Jan 2021, at 08:14, Marc Nieper
Sorry, I though this was in the guile mailing list.
--
Linus Björnstam
On Tue, 26 Jan 2021, at 07:48, Linus Björnstam wrote:
> Hi Y'all!
>
> I have an efficient, almost done implementation of srfi-121. I believe
> it lacks generator-unfold, but that is all. make-corouti
already spent some time integrating srfi-171 into guile, so I'm not
entirely unfamiliar with the task.
Best regards
Linus Björnstam
On Tue, 26 Jan 2021, at 04:29, John Cowan wrote:
> Note that 121 is withdrawn, so people should implement 158.
>
> On Sat, Jan 23, 2021 at 1:38 AM Mark
Works like a charm!
--
Linus Björnstam
On Thu, 14 May 2020, at 10:38, Andy Wingo wrote:
> On Wed 13 May 2020 23:16, Linus Björnstam
> writes:
>
> > On the latest master equal? was not reduced to eq? on chars in the repl
> > for things like ,opt (defin
this and the record unification I feel I have very little motivation to write
my own extensible pattern matcher :)
--
Linus Björnstam
On Wed, 13 May 2020, at 15:55, Andy Wingo wrote:
> Hi :)
>
> On Wed 13 May 2020 13:20, Linus Björnstam
> writes:
>
> > Hi there!
> >
> &g
the comparisons directly involving the literal is optimized: (equal? a b #\c)
-> (and (equal? a b) (eqv? b #\c)).
Any feedback is welcome.
--
Linus Björnstam
0001-Make-equal-to-eqv-or-eq-if-any-suitable-literals-are.patch
Description: Binary data
with guile optimisations.
--
Linus Björnstam
On Mon, 4 May 2020, at 22:50, Linus Björnstam wrote:
> You didn't see my other reply. The matching code isn't suboptimal. The
> equality predicate is The problem is that match compares using equal?
> even for literal chars (where eqv? is a l
matcher does (among other things: some serious list matching
reordering!). That is a daunting task though.
--
Linus Björnstam
On Mon, 4 May 2020, at 22:09, Ludovic Courtès wrote:
> Hi,
>
> Linus Björnstam skribis:
>
> > On Mon, 4 May 2020, at 11:36, Ludovic Courtès wrote:
>
are not possible.
Concerning "the macro writer's bill of rights" I could maybe think this it
would be a rather nice thing to turn equal? to eqv? when one argument is a char
literal :D
--
Linus Björnstam
On Mon, 4 May 2020, at 11:36, Ludovic Courtès wrote:
> Hey!
>
> Ale
On Mon, 4 May 2020, at 11:36, Ludovic Courtès wrote:
> > One thing I found is that `match` is slow. The code looked nicer but had to
> > change it back to lets and conds as the performance
> > increase was ~2 seconds.
>
> Oh, in which case exactly? And are you sure your hand-written code is
Hi yall!
I managed to bork the documentation in my patch that added SRFI-171 to guile.
Here is the two-line patch to fix it.
Sorry if it caused anyone any trouble. I just built guile from head on mac os x
with this patch applied, an none of the warnings were my fault.
--
Linus Björnstam
regression if they are implemented as two distinct macros?
If one does a proper define-inlinable*, it can be used to implement
define-inlinable (since that would be the simple case for it).
What do the maintainers think?
--
Linus Björnstam
ing-append doesn't do that.
Nice to see that my suggestions worked!
--
Linus Björnstam
On Wed, 22 Apr 2020, at 00:03, Aleix Conchillo Flaqué wrote:
> Hi,
>
> I was trying to get some guile-json performance times loading large
> JSON file. However, I'm getting increasing numbers at e
Oleg replied that he will look into this bug when he has time (and that the
patch looked reasonable), which sounded non-imminent :) Hopefully this means
that there will be an upstream patch sometime in the future.
--
Linus Björnstam
On Thu, 16 Jan 2020, at 13:00, Linus Björnstam wrote
(and more secure) for
the pipeline as well.
Thank you for this patch.
Linus Björnstam
On Tue, 10 Mar 2020, at 08:35, Rutger van Beusekom wrote:
>
> Hi Ludo,
>
> I have processed your feedback in this version of the patch.
>
> Ludovic Courtès writes:
>
> > Hi Rutger!
>
Thanks! I will address all those.
The tests are written and passing, so I will remove the redundant TODOs.
--
Linus Björnstam
On Sun, 8 Mar 2020, at 15:40, Ludovic Courtès wrote:
> Hi Linus,
>
> Linus Björnstam skribis:
>
> > From c382d7808a8d41cd4e9ef8a17b7ba9553835499
Will it not inline "(not-inline x)" and then peval it to x? What are you trying
to avoid? I am out on very deep water here, now I am just genuinely curious :D
--
Linus Björnstam
On Thu, 13 Feb 2020, at 08:36, Stefan Israelsson Tampe wrote:
> No even if you have cross module
it implicitly boxed.
Slow unless guile is able to do unboxing...
Ludo used the trick here:
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=bf1f5422bdb364667d6761dd73454558d6dbf895
--
Linus Björnstam
On Wed, 12 Feb 2020, at 18:44, Stefan Israelsson Tampe wrote:
> Hi all,
>
> Curr
to the compiler. One work-around
would be to output the literal lambda in place of ,inner but by then you should
just output a (let ...) With the lambda in it and let the inliner take care of
it.
--
Linus Björnstam
On Sat, 1 Feb 2020, at 15:23, David Kastrup wrote:
> Linus Björnstam wri
On Sat, 1 Feb 2020, at 12:09, David Kastrup wrote:
>
> Can you expand about the "expansion time and macro time separation"?
>
> If we have
>
> (define decl '())
> (define (make-var n v) (list "var" n v))
> (defmacro define-session (name value)
> (define (inner n v)
> (set! decl
>
Did you try just expanding it to a define? Or just output a module-define! at
runtime and run a module-define! at compile time.
--
Linus Björnstam
On Sat, 1 Feb 2020, at 10:54, Han-Wen Nienhuys wrote:
> Here is an example that shows better how things work, and what might
> be the
Read the docs. That seems to be a documentation bug. Try fiddling with the
arguments to eval when and see if you can make it work.
--
Linus Björnstam
On Fri, 31 Jan 2020, at 20:17, Han-Wen Nienhuys wrote:
> On Fri, Jan 31, 2020 at 7:20 PM Linus Björnstam
> wrote:
> > I
On Fri, 31 Jan 2020, at 20:17, Han-Wen Nienhuys wrote:
>
> eval-when looks like it might be a solution to the puzzle , but
> honestly, the doc at
>
> https://www.gnu.org/software/guile/manual/html_node/Eval-When.html
>
> has me mystified. When I run the example through guile 2.2 and
>
on the result of that
module-define! during expansion. You can however wrap it in an eval-when to
solve that issue. That allows you to specify when code gets run. With
module-define! I personally find it all a bit icky, but I usually stay as far
away from phasing as I can :)
--
Linus Björnstam
work in newer guiles, since I doubt any
scheme is a s lax about expansion time and macro time separation.
--
Linus Björnstam
On Wed, 29 Jan 2020, at 00:08, Han-Wen Nienhuys wrote:
> Some of the lilypond Scheme files do the following:
>
>
> (define decl '())
> (define (make-var
of
scopes") I suspect I am out of luck.
Väl mött
Linus Björnstam
On Fri, 24 Jan 2020, at 13:13, Stefan Israelsson Tampe wrote:
>
>
> -- Forwarded message -
> From: *Stefan Israelsson Tampe*
> Date: Fri, Jan 24, 2020 at 12:42 PM
> Subject: Re:
(let ((a (car random-identifier)))
(cons (* a a) (loop (cdr random-identifier))
Happy hacking
Linus Björnstam
On 2020-01-16 22:35, Arne Babenhauserheide wrote:
Can we get this into the Scheme standard, too?
If you want a portable implementation, you can actually hack it using
macros. Re-define lambda, define, let(*,-values,letrec,letrec*) and
begin to rewrite everything to letrec and you are done!
change
but we think the situation is globally much better, and we expect that
very few people will be affected by the change.
Is this semantic change a change from previous Guile or a deviation from
the Scheme standard?
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
--
- Linus Björnstam
There is no 'debug options, as the error says. Read more here:
https://www.gnu.org/software/guile/manual/html_node/Debug-Options.html#index-debug_002denable
--
Linus Björnstam
On Sat, 18 Jan 2020, at 19:45, dsm...@roadrunner.com wrote:
> This ought to work, right?
>
> From a
treat fun as a noun: GNU Guile -
fast functional fun :D
I'd leave the fine details of taglines to someone who is better versed in
english than me, though.
--
Linus Björnstam
On Sat, 18 Jan 2020, at 15:08, Ludovic Courtès wrote:
> Hello Guilers!
>
> The Guile logo has this “GNU
formatting wrong.
Best regards
Linus Björnstam
On 2020-01-05 12:30, Andy Wingo wrote:
Hi :)
Since this is a final SRFI I think there's no problem getting it in.
Some formatting notes follow; since it's your first Guile patch I'm a
bit verbose :) Probably this will miss 3.0.0 but make 3.0.1, FWIW
looks
different:
(xml->sxml "")
;; => (*TOP* (e ">"))
The question is whether this patch should be sent upstream. Since there has
been very little activity there, I suspect it is a lost cause.
Failing tests have been looked through, verified and fixed. No unexpected
error
r patterns.
If that is faster, I can port a constant-space one that I have in ocaml
somewhere in the catacombs of my.computer.
--
Linus Björnstam
On Fri, 20 Dec 2019, at 18:32, lloda wrote:
>
> This patch adds string-replace-substring that wingo posted to the
> mailing list to (ice-9 strings).
;
> On Sun 22 Dec 2019 15:55, Linus Björnstam
> writes:
>
> > From 7e8d3b22ba5f814c40dbb5ab616a318c0cdc2f3e Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Linus=20Bj=C3=B6rnstam?=
> > Date: Sun, 22 Dec 2019 15:38:34 +0100
> > Subject: [PATCH 1/2] Added srfi-171
I forgot the copyright!
All the papers are in order with the FSF for the copyright assignment.
--
Linus Björnstam
On Sun, 22 Dec 2019, at 15:55, Linus Björnstam wrote:
> Hi there!
>
> This is a patch to add srfi-171 (transducers) to guile.
>
> It adds the srfi implemen
have built it successfully on the latest master. This would be my first ever
commit to a project I did not start myself, with the added bonus that I have no
idea of how git works. Be kind :)
Happy holidays!
Linus Björnstam
0001-Added-srfi-171-to-guile-under-the-module-name-srfi-s.patch
was a large and a small language.
--
Linus Björnstam
On Sun, 17 Nov 2019, at 15:44, Andy Wingo wrote:
> Hey all :)
>
> Just a little heads-up that I just landed R7RS support. Thanks to Göran
> Weinholt for akku-scm (https://gitlab.com/akkuscm/akku-r7rs/) and
> OKUMURA Yuki for yuni (htt
.
--
Linus Björnstam
On Wed, 16 Oct 2019, at 15:14, Andy Wingo wrote:
> Hello all,
>
> In the last few weeks, a conversation among GNU maintainers that has
> been simmering for years burst into public. For a while it resubmerged
> into private GNU lists, but now it has resurfaced to a
69 matches
Mail list logo
