Hi everyone,
I have started playing with generics and quickly got myself in trouble.
Consider the following two modules:
-- foo.rkt
#lang racket
(provide (all-defined-out))
(require racket/generic)
(define-generics bar
[baz bar])
---
On 2013-08-27 14:31:11 +0200, Konrad Hinsen wrote:
> ---
> (struct foo-bar (quux)
> #:methods foo:gen:bar
> [(define (baz x) (baz (foo-bar-quux x)))])
> ---
>
> But now th
Asumu Takikawa writes:
> This is what the `define/generic` form is for. You can then re-write
> your struct definition as
Great, thanks! I had seen define/generic but its documentation made me
believe that its use is more restricted. But it works fine in my
demonstration code.
Unfortunately, I
e: [racket] Generics and modules
Asumu Takikawa writes:
> This is what the `define/generic` form is for. You can then re-write
> your struct definition as
Great, thanks! I had seen define/generic but its documentation made me
believe that its use is more restricted. But it works fine in my
de
J. Ian Johnson writes:
> No, your function is just ill-founded. Do you mean to destruct x to
> find an inner bar to call gen-foo-far-baz on it?
I want to make the field baz of struct foo-bar accessible through the
generic interface method foo-bar-baz.
The background is that struct foo-bar alre
Konrad Hinsen writes:
> Is there a workaround for that case as well?
I found one myself, though it's a bit of a kludge:
-- foo-bar.rkt
#lang racket
(provide (all-defined-out))
(require (prefix-in foo: "foo.rkt")
(only-in racket/generic def
August 27, 2013 11:53:43 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket] Generics and modules
J. Ian Johnson writes:
> No, your function is just ill-founded. Do you mean to destruct x to
> find an inner bar to call gen-foo-far-baz on it?
I want to make the field baz of struct fo
J. Ian Johnson wrote at 08/27/2013 12:18 PM:
You'll want foo-bar-baz the field accessor to be bound to something else that
won't be shadowed when you define foo-bar-baz the generic function.
BTW, I've found that the generated struct accessor names very often
conflict with names of procedures
> I've been wondering whether it would be more practical for struct-generated
> names to concatenate with colon (":") as a separator, rather than with minus
> ("-").
1. Yes. In addition to name conflicts, it's harder on human code
readers (or at least, me) when '-' is overloaded. Especially if the
J. Ian Johnson writes:
> You'll want foo-bar-baz the field accessor to be bound to something
> else that won't be shadowed when you define foo-bar-baz the generic
> function. Your define-generics likely is not in the same scope as
> the struct foo-bar definition, since
Right.
> Leads to a s
On Tue, 27 Aug 2013 20:03:43 +0200, Greg Hendershott
wrote:
I've been wondering whether it would be more practical for
struct-generated
names to concatenate with colon (":") as a separator, rather than with
minus
("-").
1. Yes. In addition to name conflicts, it's harder on human code
re
On Wed, Aug 28, 2013 at 5:07 AM, Tobias Hammer wrote:
> On Tue, 27 Aug 2013 20:03:43 +0200, Greg Hendershott
> wrote:
>
> . is only special when surrounded by spaces abc.def is a perfectly valid
> variable name (as is abc. and .abc).
Oh, wow. Very early on learning Scheme, I somehow got the idea
12 matches
Mail list logo
