Am Di., 23. Juli 2024 um 17:06 Uhr schrieb Lassi Kortela :
> > 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 enc
Am Mo., 22. Juli 2024 um 20:47 Uhr schrieb Maxime Devos <
maximede...@telenet.be>:
> > [...]
>
> >
>
> >In what kind of situation might a library name be made up of identifiers
> (syntax objects) that might need to carry lexical information?
>
>
>
> As implied by the previous: never (in Guile, and
Arne, you may want to take a look at Chez's "module" syntax, see [1]. It is
orthogonal to our discussion about library names, but it may be what you
have in mind for your specific use case. A module is like a library but is
bound to an identifier, not to a library name.
Marc
--
[1] https://cisco
Am Mo., 22. Juli 2024 um 20:13 Uhr schrieb Lassi Kortela :
> > 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 n
Am Mo., 22. Juli 2024 um 22:52 Uhr schrieb Artyom Bologov :
> Hi y'all,
>
> I've been confused by the statements that R6/7RS don't have numbers in
> library names. Because both kinda do.
>
> R6RS seems to allow the last library name element to be a list (?) of
> numbers explicitly reserved for lib
Am Mo., 22. Juli 2024 um 19:43 Uhr schrieb Lassi Kortela :
> > 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
e.g. networking primitives is
> extremely limiting and this always greatly bothered me about RnRS.
>
> I have questions about your point #4 though.
>
> On 21.07.2024 11:54, Marc Nieper-Wißkirchen wrote:
>
> > Allowing numbers in library names makes certain syntactic extensions (as
I would like to comment on what I think are common misconceptions about the
RnRS library system.
1. The RnRS library system is neither a prerequisite for being able to
write portable code nor is it particularly helpful in this regard. The RnRS
library system should better be called a module system
Am Di., 28. Feb. 2023 um 05:27 Uhr schrieb Philip McGrath
:
>
> Hi,
>
> On Monday, February 27, 2023 2:26:47 AM EST Marc Nieper-Wißkirchen wrote:
[...]
> > Nevertheless, I am not sure whether it is relevant to the point I
> > tried to make. The "#!r6rs" does
Am Mo., 27. Feb. 2023 um 00:22 Uhr schrieb Philip McGrath
:
>
> Hi,
>
> On Sunday, February 26, 2023 6:02:04 AM EST Marc Nieper-Wißkirchen wrote:
> > Am So., 26. Feb. 2023 um 08:46 Uhr schrieb :
> > > Message: 1
> > > Date: Sun, 26 Feb 2023 02:45:12 -0500
&g
Am So., 26. Feb. 2023 um 08:46 Uhr schrieb :
> Message: 1
> Date: Sun, 26 Feb 2023 02:45:12 -0500
> From: "Philip McGrath"
> To: "Maxime Devos" , Ludovic Courtès
> , "Matt Wette" ,
> guile-devel@gnu.org
> Cc: "Christine Lemmer-Webber"
> Subject: Re: [PATCH] add language/wisp to G
Am Di., 26. Jan. 2021 um 08:08 Uhr schrieb Linus Björnstam <
linus.bjorns...@veryfast.biz>:
> Hi Y'all!
>
> I have an efficient, almost done implementation of srfi-121. I believe it
> lacks generator-unfold, but that is all. make-coroutine-generator is
> implemented using delimited continuations a
Am Di., 4. Aug. 2020 um 17:24 Uhr schrieb John Cowan :
>> At the moment,
>> there is no general programmatic way to know whether a specific
>> implementation is up-to-date with respect to these post-finalization
>> notes or not.
>
>
> How could there be? The implementations are written in a Turi
Am Mo., 3. Aug. 2020 um 21:41 Uhr schrieb Marc Nieper-Wißkirchen
:
> > I'm sorry to say it, but in my opinion SRFI-121 and SRFI-158 should be
> > deprecated and avoided. The reference implementations do not match the
> > specifications, and the specifications themselves
Am Mo., 3. Aug. 2020 um 18:00 Uhr schrieb :
> Message: 1
> Date: Sun, 02 Aug 2020 18:39:32 -0400
> From: Mark H Weaver
> To: John Cowan
> Cc: guile-devel@gnu.org
> Subject: Re: [PATCH] add SRFI: srfi-121; generators
> Message-ID: <87v9i0zn7k@netris.org>
> Content-Type: text/plain
> It didn'
Am Fr., 23. Nov. 2018 um 22:28 Uhr schrieb Marc Nieper-Wißkirchen <
m...@nieper-wisskirchen.de>:
> Hi Mark,
>
> Am Fr., 23. Nov. 2018 um 21:26 Uhr schrieb Mark H Weaver :
>
>> Hi Marc,
>>
>> Marc Nieper-Wißkirchen writes:
>>
>> > Am Mi., 21.
Hi Mark,
Am Fr., 23. Nov. 2018 um 21:26 Uhr schrieb Mark H Weaver :
> Hi Marc,
>
> Marc Nieper-Wißkirchen writes:
>
> > Am Mi., 21. Nov. 2018 um 04:38 Uhr schrieb Mark H Weaver >:
> >
> > I'm not aware of any language in the R[567]RS that makes it clear
&
Hi Mark,
Am Fr., 23. Nov. 2018 um 08:56 Uhr schrieb Mark H Weaver :
> Hi Marc,
>
> Marc Nieper-Wißkirchen writes:
>
> > Am Mi., 21. Nov. 2018 um 04:38 Uhr schrieb Mark H Weaver >:
> >
> > > Ellipsis identifiers are a bit more tricky, because unlike othe
> Now to R6RS. Section 6.4 says that auxiliary syntax describes a syntax
> binding. Section 12.4 of the R6RS Library Report defines `...' as auxiliary
> syntax. The example definition of `case' in Section 12.5 ibid. shows
> explicitely that auxiliary keywords are matched using `free-identifier=?'
>
Am Mi., 21. Nov. 2018 um 04:38 Uhr schrieb Mark H Weaver :
> Hi Marc,
>
Dear Mark,
thank you very much for all your detailed replies; these are extremely
helpful!
> No, it does not monotonically grow during the course of expansion. One
> way to think about it is that it's the lexical environm
Am Sa., 17. Nov. 2018 um 16:17 Uhr schrieb Marc Nieper-Wißkirchen <
marc.nie...@gmail.com>:
> Am Do., 15. Nov. 2018 um 17:55 Uhr schrieb Marc Nieper-Wißkirchen <
> marc.nie...@gmail.com>:
>
>> I would like to alias an identifier in Guile. By this, I mean the
>> fo
Am Do., 15. Nov. 2018 um 17:55 Uhr schrieb Marc Nieper-Wißkirchen <
marc.nie...@gmail.com>:
> I would like to alias an identifier in Guile. By this, I mean the
> following: Given a bound identifier `x', I want to lexically introduce
> another identifier `y' with the same
>
> > I agree and I see that my example doesn't demonstrate what it should
> > have demonstrated because `bar' is not executed before `foo' is used
> > as a macro. The example should have been more like the following:
> >
> > (define-syntax foo
> > (lambda (stx)
> > (with-ellipsis e
> >
Am Fr., 16. Nov. 2018 um 01:01 Uhr schrieb Mark H Weaver :
> Hi Marc,
>
> Marc Nieper-Wißkirchen writes:
>
> > > Let's assume we are writing a macro that reimplements syntax (or some
> > > variation thereof) and which has to check whether identifiers ar
Hi Mark,
> Let's assume we are writing a macro that reimplements syntax (or some
> variation thereof) and which has to check whether identifiers are
> ellipses. For example, the following could be given:
>
> (with-ellipsis e
> (my-syntax a e)
>
> Now, this could
I would like to alias an identifier in Guile. By this, I mean the
following: Given a bound identifier `x', I want to lexically introduce
another identifier `y' with the same binding as `x' so that `x' and `y'
become `free-identifier=?'.
The following is one use case: I have written a macro `custom
Hi Mark,
>
> > So what we actually need is a procedure of
> > two arguments: `(ellipsis? e ctx)' returns `#t' if the identifier `e'
> > is the current ellipsis in the lexical environment of the identifier
> > `ctx'.
>
> Hmm. I don't actually see a need for the second argument, do you? I
> can't
Hi Mark,
thank you very much for replying so quickly.
Am Mi., 14. Nov. 2018 um 20:11 Uhr schrieb Mark H Weaver :
> > The `ellipsis?' procedure in psyntax.ss does exactly this, but it
> > isn't available to user code. Re-implementing it is not possible
> > without accessing internal details like
Guile includes a mechanism to specify a custom ellipsis for `syntax-case'
macros. For macro writers it would be nice if there were a way to check
whether a given identifier is the current (custom) ellipsis.
The `ellipsis?' procedure in psyntax.ss does exactly this, but it isn't
available to user c
29 matches
Mail list logo
