Printing and transparency are in fact separate:
(struct test (x)
#:methods gen:custom-write
[(define (write-proc t p m)
(write (format "<test ~a>" (test-x t)) p))])
The above untangles the concepts:
> (test 5)
"<test 5>"
> (struct? (test 5))
#f
But I suppose it could be useful to have a comparable default printer
without struct? returning #t, like (struct test (x) #:show)
On Thu, Mar 13, 2014 at 9:00 AM, Matthias Felleisen <matth...@ccs.neu.edu>wrote:
>
> We need to distinguish at least two aspects of this question:
>
> (1) structure instances are first-class values in most languages that
> offer structures.
> Even in the context of C++ you can program as if you were dealing with
> structure
> instances as values.
>
> (2) structure type definitions, such as (struct posn (x y)) are pieces of
> syntax, so
> using the terminology 'first-class' with them is inappropriate. The very
> idea of
> first-class value means something that a program can deal with at run-time
> w/o (m)any restrictions. [You can also define 'first-class' with respect
> to other
> times when programs compute. Even then I have difficulties calling a
> definition
> a first-class object.]
>
> The next part of your question is whether we should have inheritance
> (everything
> is a struct) and whether we should expose it in the teaching languages.
> The former
> is a design decision that I have rarely exploited; my hunch is that a
> programmer
> can live without it and that a meta-/tool-programmer needs it. The latter
> is a
> flaw that we could probably fix easily now.
>
> -- Matthias
>
>
>
>
>
>
>
>
>
> On Mar 13, 2014, at 6:30 AM, Yi D wrote:
>
> Hi,
>
> The documentation says that struct creates structures that are treated as
> first-class
> values. I can see the motivation for pursuing expressiveness. So what do
> we achieve
> using first-class structures? On the down side, I see some problems. For
> example, in
> the Beginning Student language, a posn is both a posn? and a struct?.
>
> > (posn? (make-posn 1 2))
> #t
> > (struct? (make-posn 1 2))
> #t
>
> I guess this is because posn is declared to be #:transparent.
>
> In my opinion, exposing the struct? nature of posn undermines abstraction
> and breaks
> encapsulation. But without declaring it #:transparent, the printer could
> not echo
> informative response. It seems to me the two aspects: exposing the
> struct?nature and
> informative result are unnecessarily tangled. If they can be separated, we
> may be able
> to give informative result and at the same time not to expose the
> struct?nature of
> structure types.
>
> Best,
>
> Yi
> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users
>
>
>
> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users
>
>
____________________
Racket Users list:
http://lists.racket-lang.org/users
