Your two points sound good.
However, I personally hope that Guile will continue to be friendly towards
those using it as an embedded language. There, a C API is important. There
*is* a downside in moving to Scheme from that perspective, but that is fine
as long as it is easy to call Scheme from C.
Mikael Djurfeldt writes:
> design a new module hierarchy, introduce aliases for module bindings,
> and still supply the old module hierarchy during a few years for
> backward compatibility.
Please do not do this. It is a recipe for disaster.
Do you remember when Lilypond broke with Guile 2.0?
H
just my 2 cents...
about moving code from C to Scheme, it seems to be the Racket choice , they
had Racket written in C and now they have a new version based on Chez
Scheme that is mainly written in Scheme, they move a lot of code from C to
Scheme as far as i know...
About breaking backward compat
>However, I personally hope that Guile will continue to be friendly towards
>those using it as an embedded language. There, a C API is important. There
>*is* a downside in moving to Scheme from that perspective, but that is fine as
>long as it is easy to call Scheme from C. The typical use case
Damien Mattei writes:
> About breaking backward compatibility , i understand it could be a
> disaster... but if Python made this choice
The experience of Python should not be encouragement. It was a disaster.
Many tools are *still* broken, especially specialist tools. More than
one and a half d
>Regarding the junk, I very much agree. I also look forward to getting rid of
>ice-9 :). As has been spoken about here previously, I suggest that we design a
>new module hierarchy, introduce aliases for module bindings, and still supply
>the old module hierarchy during a few years for backward
Maxime Devos writes:
>> I suggest that we design a new module hierarchy, introduce aliases for
>> module bindings, and still supply the old module hierarchy during a few
>> years for backward compatibility.
> Also, on deprecation and removal: just because you deprecate something,
> doesn’t mean
And that a new hierarchy we define is not guaranteed to actually *stay*
better. There would be errors, but different ones. We can only expect
that the new one will be significantly better in case where either the
computing environment changed substantially or where our knowledge and
skill of how t
>Maxime Devos writes:
>>> I suggest that we design a new module hierarchy, introduce aliases for
>>> module bindings, and still supply the old module hierarchy during a few
>>> years for backward compatibility.
>> Also, on deprecation and removal: just because you deprecate something,
>> doesn’t
Le vendredi 28 juin 2024 à 22:52 -0400, Thompson, David a écrit :
> Who actually wants to use that C API?
lilypond $ git grep '\bscm_' '**/*.cc' '**/*.yy' '**/*.ll' | wc -l
3961
signature.asc
Description: This is a digitally signed message part
Hi David and all,
"Thompson, David" writes:
> As a rule, I think Guile should *not* add any additional names to the
> default environment without an extremely good reason. Because (guile)
> is imported implicitly, new names can cause clashes with existing code
> that require #:replace to suppres
How about a GRFI site to deal with proposals to Guile?
How about a GRFI site to deal with proposals to Guile?
I advise against starting a GRFI unless you can find plausible ways to
solve the known problems with the SRFI process. In case you can solve
these difficult problems which many smart people have failed to solve,
perhaps the new process co
Le samedi 29 juin 2024 à 12:04 -0700, Matt Wette a écrit :
> How about a GRFI site to deal with proposals to Guile?
In the current state of Guile, even simple patches are routinely taking
months to get reviewed and merged by the maintainers, if they get replies
at all. Not assigning blame here, ju
On 6/28/24 09:20, Andrew Tropin wrote:
On 2024-06-26 18:06, Philip McGrath wrote:
On 6/26/24 07:41, Andrew Tropin wrote:>
That said, the evaluator does attach so-called "meta-data" information
to procedures, such as the procedure name.
https://www.gnu.org/software/guile/manual/html_node/Proced
Hi,
On 6/28/24 22:52, Thompson, David wrote:
First, I think Guile's default environment is a total mess. It's
the very definition of a junk drawer. There's over 1000 names in
the (guile) module! Contrast this with R7RS-small's (scheme base)
module that only has 200ish. Guile is an old projec
>> The default environment is irrelevant to most Scheme libraries, since
> it is irrelevant to any library defining modules with
> ‘define-module’, ‘define-library’ or ‘library’ forms (which is pretty
> much the only reasonable way to define modules unless you are making
> your own system). This al
>Instead of run-time reflection on values, I think an IDE implementing
jump to definition should use source location and binding information
from syntax objects. That's how DrRacket does it.
>The attached DrRacket screenshot (of [1]), in which I've tacked a bunch
of binding arrows, shows how lo
Hi Richard,
On Sat, Jun 29, 2024 at 3:02 PM Richard Sent
wrote:
>
> I see my little patch has ignited a comparatively oversized firestorm.
> Oops. ;)
I wasn't sure if my email would get 0 replies or a lot of replies...
but the latter happened. I just want to be clear that this is *not* a
judgeme
Hi Mikael,
On Sat, Jun 29, 2024 at 3:38 AM Mikael Djurfeldt wrote:
>
> Your two points sound good.
>
> However, I personally hope that Guile will continue to be friendly towards
> those using it as an embedded language. There, a C API is important. There
> *is* a downside in moving to Scheme fr
Thank you for keeping an open line of communication between Racket and
Scheme.
Obviously `#lang` does much more than this (we Racketeers tend to say
`#lang` as shorthand for a bunch of complementary but mostly independent
features), but I think a particularly important aspect is that each
mod
21 matches
Mail list logo
