Arne wrote:
Additionally we’d have to ask whether these should actually be in
(guile ...). (ice-9 match) is actually from chibi-scheme, just with
three shims added so the upstream code runs unmodified. Calling that
(guile ...) would falsely imply that it is implementation specific.
The deeper I
Arne wrote:
Indeed, Scheme doesn't have a clear separation between full-featured
RnRS implementations and subset implementation. Several people have
noted that this is confusing.
Maybe the r7rs-benchmark preludes and postludes could be a start for
documentation of that?
https://github.com/ecr
Arne wrote:
Would it be possible to start into that by creating prefixes for the
different package repositories?
(akkuscm ...) and (snow-fort ...)
I advise against doing that, as the same package can be published to
multiple repositories.
Would that be a problem? All it needs is a referenc
I haven’t received the e-mail you are responding too (in particular, I
don’t know who you are responding to), but …
I was talking to Marc; it seems there is a delay in list traffic.
As already has been answered:
The practical harm is (srfi |1|) is non-standard, but it looks standard
because
In R7RS, (srfi 1) and (srfi |1|) are different library names.
What is the practical harm?
(If there is some obscure point whereby the semantics don't add up in an
intuitive way, I would genuinely like to hear about it. In practice, I
think library aliases will be a must-have feature eventuall
There are other costs involved, e.g., when mappings from library names
to the pathnames have to be specified. While it is straightforward to
encode a number of characters like "/" or ":", it is not so
straightforward to encode numbers differently from symbols that look
like numbers.
Why would
As I wrote, this is a syntactic extension of Chez Scheme - but a very
useful one - and outside of the R6RS. The Unsyntax expander I wrote
also implements it.
If patching these two implementations to use the first library name part
instead of the last is the only technical obstacle to numbers
To correctly attach marks (in the R6RS syntax model) to the imported
identifiers, the expander needs marks associated with the library name
(and takes the marks of the last name part, which, therefore, must be an
identifier).
Where does the decision to take the last library name part come from?
> In R7RS non-negative integers can be library name parts. Since these
library names look natural, it would be good to backport this to R6RS
implementations.
Then (library [...] (import (srfi 1)) [...]) would work, and since
‘library’ is (R6RS) standard and reasonably portable it would then
ap
I don’t know if ‘(import ...)’ is standard either (sure it is as part of
‘define-library’, but I didn’t find it on its own in r7rs.pdf),
(import ...) is standard in both R6RS and R7RS, and supported by every
serious implementation of those standards. Please spread it.
R7RS talks about "progra
That said, I think that in Scheme, standard is quite different from portable –
if something standard is implemented, it will be (mostly) according
to the standard, so in this way it is ‘portable’, but that’s a big ‘if’. For
large Schemes (and small Schemes for which the RnRS or SRFI stuff is
imp
Would it be possible to start into that by creating prefixes for the
different package repositories?
(akkuscm ...) and (snow-fort ...)
I advise against doing that, as the same package can be published to
multiple repositories.
(how do I find out whether they are portable? Do I have to try?)
Why wouldn’t this smart newbie learn more?
Many things are competing for his time.
I mean, in an alternate
universe, the CIPM and or their predecessors might have liked soccer
(cf. Ice-9) very much and called the unit of mass the ‘football’ instead
of the ‘(kilo)gram’. In that universe, “the
Is anything except for (srfi ...) and (rnrs ...) expected to be
portable? I thought till now that if I want my code portable, an easy
way would be to restrict my imports to these.
The R6RS and R7RS library definition framework (which is broadly
compatible across both standards) offers a realist
Why not move (language xyz) into (guile language xyz) as well?
+1
I’m not sure about all the top-level module thingies though, sometimes
other implementations implement the same thing too. For example, Racket
has an SXML implementation. If the API is compatible (and located under
the same mo
If so, why would a smart newbie learn more?
I did.
Did you not?
As a committed schemer, I forgive almost any obstacle.
I actually liked that name — and still like it. Keep in mind that being
professional quality doesn’t require being teflon-proof naming. Python
includes `import this` and `
It would be easy to state in more places "the standard library of guile
is called ice-9 (see [history])".
With no disrespect intended -- I understand it's a joke that was funny
at one time -- "the standard library of Guile is called ice-9" sounds
like "the unit of mass is called footballs". If
(import (srfi :1)) ;; works
(import (srfi :1 lists)) ;; works
The colon in :1 is a hack due to a limitation in the R6RS spec.
I recommend that Guile support both 1 and :1 (as well as the symbol |1|)
by internally converting to some normal form.
(import (srfi :1 awesome-feature)) ;; also wor
I mean deprecation doesn't mean it has to be removed immediately.
There will be some time before it is actually removed. We can even push
it to Guile 4.
Given a long timeline i doubt older programs would be advised to be used
or even work with recent guile. Given the rest of the cleaning
dis
Aliasing (ice-9 *) to (guile *) for avoiding the "what's that none
standard ice-9 library?".
Sounds reasonable. "What is ice, and why version 9?"
Also (srfi srfi-N) with something meaninful
for humans that don't want to lookup srfi.schemers.org or keep a
cheatsheet on their desk. e.g., (srfi
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
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
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
I've been thinking how it'd be nice to have available in Guile a number of
purely functional datatypes, these being hashmaps, vectors, and sets.
Those are core data types of Clojure. It'd be nice if the canonical
Scheme versions of these types have Clojure-compatible semantics. This
will make
That is a better way to write it indeed. clause-body being equal to a lambda
body.
Thank you.
No problem.
Nb. I made an oversight - the section of R7RS with the grammar I quoted
says:
"These were derived from rules in the grammar given in chapter 7 by
replacing some occurrences of with ,
Not quite. Guile extends the lambda body (and by extension let-forms) to allow
mixed definitions and expressions:
(lambda ()
(display "Heippa!")
(define routsi #t)
(and (read) routsi))
which expands to, more or less, a letrec*. All in accordance to the paper
fixing letrec(reloaded).
Would "is like the body of a lambda" be a better wording?
R7RS section 3.5. says:
(lambda * * )
The * are the stuff you are adding.
Hello,
We managed to contact the owner of the domain name scheme.org and are
slowly working to put up websites there.
One of our projects is to give each prominent Scheme implementation its
own subdomain to use as its authors see fit. We now have all of the
major ones covered except for Guil
28 matches
Mail list logo
