Re: [racket-users] Migrating from a "model-driven" language framework to Racket

['John Clements' via Racket Users]

> ...

> So far, I have made two attempts to work around these issues: (1) by creating 
> a metamodel-like data structure using Racket structs, and transforming syntax 
> objects into struct instances; or (2) using syntax objects only and attaching 
> context data to each of them as a syntax property.
> Both have strengths and weaknesses, and I am still feeling that I am not 
> using Racket with the right mindset.

I think your (2) sounds like a lighter-weight solution. However, it definitely 
does seem as though much of the difficulty here is related to the differences 
between a more imperative and a more functional style. I think your idea of a 
simplified example—especially one illustrating the situations in which context 
information is required—would be an excellent idea!

John



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f560d4b5-9707-4be8-8644-d41c8f249b1b%40mtasv.net.

Re: [racket-users] Exception throwing in web-server

[Bogdan Popa]

Norman Gray writes:

> But what happens in this case (the my-app/error case in my example) is
> that the (server) program keeps going but the client stalls.  The
> unexpected error in the response-output procedure is caught, and (as
> far as I can see) handled by killing the producer thread _without_
> closing the connection.  To be clear, I think that the handler should
> do both.

The handler you pointed to in your other email is intended to catch
network errors and abrupt hangups from the client, but will not catch
exceptions raised by the response's output function.  For that, there
needs to be an exception handler in the chunker thread.

I've opened a PR to add such a handler here:

https://github.com/racket/web-server/pull/93

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/m2mu5vu1v5.fsf%40192.168.0.142.

Re: [racket-users] Exception throwing in web-server

[Ryan Culpepper]

I'm assuming chunked Transfer-Encoding, which is IIRC what the Racket web
server uses for unknown-length payloads. If the server hasn't committed to
chunked encoding (by sending the header), then it probably hasn't sent the
status code either. So truncation is definitely detectable.

RFC 7230 Section 6.3.1 and 6.3.2 give more specific guidance than "do the
right thing", as I read it. I would summarize it as: Only automatically
retry if you know that the operation is idempotent (6.3.1) or hadn't been
processed yet (6.3.2), and only automatically retry once; otherwise, kick
the error up a level and let them decide.

RFC 7230 Section 9.6 (Message Integrity) mentions using "length or
chunk-delimited framing to detect completeness", so I think using a chunk
framing violation to signal incompleteness is fair game.

Re semantics: I haven't read that RFC yet, but generally, *semantics* only
apply to *syntactically* well-formed things. So introducing a syntax error
(the chunk framing violation) is a good way of saying "nevermind, don't
even *try* to interpret this payload", given that there are no other
options.

Re TCP: It's not a TCP error, and the client shouldn't assume it was.
Section 6.3.1 starts with "Connections can be closed at any time, with or
without intention." And the idea generalizes to any connection-oriented
transport layer. (Hanging up the phone isn't a phone error, and if you're,
say, a telemarketer, you probably wouldn't even consider the possibility
that it was a network failure.)

So I still think closing the connection after making the response
syntactically valid is a good default for the Racket web server.

BTW, if you control the client, you could also use "trailing headers" (see
Section 4.1), but the internet tells me that browsers don't support them.

Ryan


On Mon, May 25, 2020 at 9:48 PM Norman Gray 
wrote:

>
> Ryan and Matthew, hello.
>
> On 25 May 2020, at 19:43, Ryan Culpepper wrote:
>
> > As I understand the HTTP protocol (that is, some but not lots), the
> > most
> > reasonable thing for the server to do if it discovers an error after
> > the
> > status code has been sent seems to be to just hang up and let the
> > client
> > realize that *something* went wrong. I don't mean just truncate the
> > output;
> > I mean the server should say "here comes another chunk" and then close
> > the
> > TCP connection, so it cannot be mistaken for a valid response. (The
> > servlet
> > should probably make a note so the next request doesn't just fail in
> > exactly the same way.)
>
> I have spent a fair amount of quality time with the HTTP RFCs, and I'm
> surprised I can't think of an answer to this off the top of my head.
>
> Looking through RFC 7230, however (RFCs 7230--5 replace RFC 2616), we
> find in Sect.3.3.3 'Message Body Length',
>
> Since there is no way to distinguish a successfully completed,
> close-delimited message from a partially received message
> interrupted
> by network failure, a server SHOULD generate encoding or
> length-delimited messages whenever possible.  The close-delimiting
> feature exists primarily for backwards compatibility with HTTP/1.0.
>
> If a response includes a Content-Length header, then truncation would be
> detectable, if not, not.
>
> This passage is talking about network failure, but I think the
> server-failure we're talking about here is morally similar.  RFC 7230
> Sect 6.3.2, though it's talking about a slightly different thing, also
> conceives of the notion of 'partial failure conditions' whilst being
> vague about what these are or what a client should do (the implication
> is that the client should... do the right thing).
>
> HTTP is generally deliberately rather vague about the payload -- the
> representation of the named resource -- and RFC 7231 Sect.3.3 'Payload
> Semantics' is a mere four paragraphs long.  It includes text
>
> For example, the payload of a
> 200 (OK) response to GET (Section 4.3.1) represents the current
> state
> of the target resource, as observed at the time of the message
> origination date
>
> There's quite a lot that doesn't say, -- it's even prefaced by 'for
> example'.  It doesn't even say that the payload _accurately_ represents
> the state of the resource.  That sounds like quibbling, but it fits in
> with a general idea of 'the client gets what it's given, and it'll like
> it'.
>
> However vague this is, I think this would not be consistent with a
> server deliberately causing a TCP error, in a protocol at a lower layer
> than HTTP.  Apart from anything else (a) the HTTP transaction might not,
> in principle, be running over TCP, and (b) it would be a lie, since the
> problem wasn't a TCP problem.
>
> In other words, truncating the output isn't desirable, obviously, but
> the alternatives of a deliberate lower-layer error, or stalling, seem
> both to be against the spirit of the spec.
>
> Matthew said:
>
> > AFAICT this is the intended behavior. To me it is consistent with 

Re: [racket-users] Exception throwing in web-server

[Norman Gray]

Ryan and Matthew, hello.

On 25 May 2020, at 19:43, Ryan Culpepper wrote:

As I understand the HTTP protocol (that is, some but not lots), the 
most
reasonable thing for the server to do if it discovers an error after 
the
status code has been sent seems to be to just hang up and let the 
client
realize that *something* went wrong. I don't mean just truncate the 
output;
I mean the server should say "here comes another chunk" and then close 
the
TCP connection, so it cannot be mistaken for a valid response. (The 
servlet

should probably make a note so the next request doesn't just fail in
exactly the same way.)


I have spent a fair amount of quality time with the HTTP RFCs, and I'm 
surprised I can't think of an answer to this off the top of my head.


Looking through RFC 7230, however (RFCs 7230--5 replace RFC 2616), we 
find in Sect.3.3.3 'Message Body Length',


   Since there is no way to distinguish a successfully completed,
   close-delimited message from a partially received message 
interrupted

   by network failure, a server SHOULD generate encoding or
   length-delimited messages whenever possible.  The close-delimiting
   feature exists primarily for backwards compatibility with HTTP/1.0.

If a response includes a Content-Length header, then truncation would be 
detectable, if not, not.


This passage is talking about network failure, but I think the 
server-failure we're talking about here is morally similar.  RFC 7230 
Sect 6.3.2, though it's talking about a slightly different thing, also 
conceives of the notion of 'partial failure conditions' whilst being 
vague about what these are or what a client should do (the implication 
is that the client should... do the right thing).


HTTP is generally deliberately rather vague about the payload -- the 
representation of the named resource -- and RFC 7231 Sect.3.3 'Payload 
Semantics' is a mere four paragraphs long.  It includes text


   For example, the payload of a
   200 (OK) response to GET (Section 4.3.1) represents the current 
state

   of the target resource, as observed at the time of the message
   origination date

There's quite a lot that doesn't say, -- it's even prefaced by 'for 
example'.  It doesn't even say that the payload _accurately_ represents 
the state of the resource.  That sounds like quibbling, but it fits in 
with a general idea of 'the client gets what it's given, and it'll like 
it'.


However vague this is, I think this would not be consistent with a 
server deliberately causing a TCP error, in a protocol at a lower layer 
than HTTP.  Apart from anything else (a) the HTTP transaction might not, 
in principle, be running over TCP, and (b) it would be a lie, since the 
problem wasn't a TCP problem.


In other words, truncating the output isn't desirable, obviously, but 
the alternatives of a deliberate lower-layer error, or stalling, seem 
both to be against the spirit of the spec.


Matthew said:

AFAICT this is the intended behavior. To me it is consistent with the 
usual policy: an uncaught error stops the program. If you want the 
program to keep running, then you have to catch the error and make 
other arrangements.


But what happens in this case (the my-app/error case in my example) is 
that the (server) program keeps going but the client stalls.  The 
unexpected error in the response-output procedure is caught, and (as far 
as I can see) handled by killing the producer thread _without_ closing 
the connection.  To be clear, I think that the handler should do both.


All my servlet routes are surrounded by a top-level `with-handlers` 
block that catches `exn:fail?`. If I get an error, I usually a) log it 
to the remote system, b) send an email to myself, and c) send a status 
400 response to the browser with the error string. But the web server 
keeps running as usual.


I'm not positive where you mean by 'servlet routes'.  If you mean 
creating a handler to wrap my-app/foo in my example, then yes, that's 
what I do, too, and/or create a handler within my-app/foo before I 
create the response object.  But it looks as if I must _additionally_ 
create a handler inside the response-output procedure (on the occasions 
when I do that 'by hand'), to cope with any exceptions thrown in there.


Of course, I should design that response-output procedure so that it 
won't throw exceptions, but... never say never.


Best wishes,

Norman


--
Norman Gray  :  http://www.astro.gla.ac.uk/users/norman/it/
Research IT Coordinator  :  School of Physics and Astronomy
// My current template week for IT tasks is: Monday, Tuesday, and Friday

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/E012F389-5CCC-48E1-A255-96F8CAC70FD4%40glasgow.ac.uk.

Re: [racket-users] Exception throwing in web-server

[Matthew Butterick]

AFAICT this is the intended behavior. To me it is consistent with the usual 
policy: an uncaught error stops the program. If you want the program to keep 
running, then you have to catch the error and make other arrangements. All my 
servlet routes are surrounded by a top-level `with-handlers` block that catches 
`exn:fail?`. If I get an error, I usually a) log it to the remote system, b) 
send an email to myself, and c) send a status 400 response to the browser with 
the error string. But the web server keeps running as usual. 

> On May 25, 2020, at 10:30 AM, Norman Gray  wrote:
> 
> This means that a further possibility is to have an exception handler within 
> the serialiser, and handle exceptions appropriately there (as in 
> my-app/handlers above).  However all this means that a carefully-written 
> servlet _must_ have such handlers, if an inadvertent exception in the 
> serialiser procedure isn't to stall a client.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/D9679928-BF4D-4115-8E28-5D4D6FAC48B9%40mbtype.com.

Re: [racket-users] Re: Exception throwing in web-server

[Ryan Culpepper]

As I understand the HTTP protocol (that is, some but not lots), the most
reasonable thing for the server to do if it discovers an error after the
status code has been sent seems to be to just hang up and let the client
realize that *something* went wrong. I don't mean just truncate the output;
I mean the server should say "here comes another chunk" and then close the
TCP connection, so it cannot be mistaken for a valid response. (The servlet
should probably make a note so the next request doesn't just fail in
exactly the same way.)

Is there are reason not to change the web server to do this automatically?

Ryan


On Mon, May 25, 2020 at 7:30 PM Norman Gray 
wrote:

>
> Thank you, Brian and Jesse, for your thoughts on this.  There may still
> be an exception problem here, though.
>
> (and sorry for being sluggish to respond)
>
> On 16 May 2020, at 20:16, Norman Gray wrote:
>
> > Now, in tracking this down I can see that I have a wrong design here:
> > the servlet has started producing output before the exception is
> > thrown, so it's at this point really too late for me to be throwing
> > errors and producing custom 5xx error pages.
>
> Brian said:
>
> > I think you need to decide when to stream, and when not to stream. In
> > my
> > web framework, most requests involve computing the entire response
> > string
> > prior to calling (response ...), so if an error is encountered, I can
> > send
> > an error response instead of a success response.
>
> and Jesse:
>
> > I suggest thinking of a servlet as a response builder, and, if
> > possible, to
> > delegate serialization of the response (output-response & friends)
> > till
> > after a response? value has been created.
>
> I agree this is the right way of thinking about things here, and it's
> reassuring to have that confirmed.  Part of what was confusing me was
> that it's not particularly clear from the documentation what
> serve/servlet's #:servlet-responder is there for.  It appears to be just
> an odd spelling of 'exception handler', as far as I can tell from the
> code.
>
> Indeed it's true that, once the HTTP status code has hit the wire,
> there's no provision in the protocol to change one's mind and come up
> with a different status (it's possible that forthcoming HTTP/3, with its
> concern to multiplex content on the wire, will come up with something
> here, but I haven't examined HTTP/3 in detail, and I'd be surprised if
> this was one of its concerns).
>
> However, a problem comes when the serialiser _does_ produce a 'real'
> exception -- meaning an exception that isn't one that I expected it to
> produce.  In that case, the response.rkt code just hangs.
>
> Consider:
>
>  #lang racket/base
>  (require web-server/servlet
>   web-server/servlet-env)
>
>  (define (make-response/output writer)
>(λ (req)
>  (response 200 #"OK" (current-seconds) #"text/plain" '()
> writer)))
>
>  (define my-app/simple
>(make-response/output
> (λ (op)
>   (display "hello" op
>  (define my-app/error
>(make-response/output
> (λ (op)
>   (error "Oooops")
>   (display "Hello" op
>  (define my-app/handlers
>(make-response/output
> (λ (op)
>   (with-handlers ((exn:fail? (λ (ex) (display "Eeek!" op
> (error "Oooops")
> (display "Hello" op)
>
>  (serve/servlet my-app/error
> #:servlet-regexp #rx""
> #:command-line? #t)
>
> If we run this server, and dereference , for
> example with curl, then the retrieval simply hangs.
>
> It appears that the handler in
> web-server-lib/web-server/response.rkt:148 is supposed to handle this
> case, but it appears not to.  I think it's possible the handler should
> be in to-chunker-t instead or as well.
>
> This means that a further possibility is to have an exception handler
> within the serialiser, and handle exceptions appropriately there (as in
> my-app/handlers above).  However all this means that a carefully-written
> servlet _must_ have such handlers, if an inadvertent exception in the
> serialiser procedure isn't to stall a client.
>
> Best wishes,
>
> Norman
>
>
> --
> Norman Gray  :  https://nxg.me.uk
> SUPA School of Physics and Astronomy, University of Glasgow, UK
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/AB2357DF-5A41-429F-A7BB-7B4321EEDBE3%40glasgow.ac.uk
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on 

[racket-users] Re: Exception throwing in web-server

[Norman Gray]

Thank you, Brian and Jesse, for your thoughts on this.  There may still 
be an exception problem here, though.


(and sorry for being sluggish to respond)

On 16 May 2020, at 20:16, Norman Gray wrote:

Now, in tracking this down I can see that I have a wrong design here: 
the servlet has started producing output before the exception is 
thrown, so it's at this point really too late for me to be throwing 
errors and producing custom 5xx error pages.


Brian said:

I think you need to decide when to stream, and when not to stream. In 
my
web framework, most requests involve computing the entire response 
string
prior to calling (response ...), so if an error is encountered, I can 
send

an error response instead of a success response.


and Jesse:

I suggest thinking of a servlet as a response builder, and, if 
possible, to
delegate serialization of the response (output-response & friends) 
till

after a response? value has been created.


I agree this is the right way of thinking about things here, and it's 
reassuring to have that confirmed.  Part of what was confusing me was 
that it's not particularly clear from the documentation what 
serve/servlet's #:servlet-responder is there for.  It appears to be just 
an odd spelling of 'exception handler', as far as I can tell from the 
code.


Indeed it's true that, once the HTTP status code has hit the wire, 
there's no provision in the protocol to change one's mind and come up 
with a different status (it's possible that forthcoming HTTP/3, with its 
concern to multiplex content on the wire, will come up with something 
here, but I haven't examined HTTP/3 in detail, and I'd be surprised if 
this was one of its concerns).


However, a problem comes when the serialiser _does_ produce a 'real' 
exception -- meaning an exception that isn't one that I expected it to 
produce.  In that case, the response.rkt code just hangs.


Consider:

#lang racket/base
(require web-server/servlet
 web-server/servlet-env)

(define (make-response/output writer)
  (λ (req)
(response 200 #"OK" (current-seconds) #"text/plain" '() 
writer)))


(define my-app/simple
  (make-response/output
   (λ (op)
 (display "hello" op
(define my-app/error
  (make-response/output
   (λ (op)
 (error "Oooops")
 (display "Hello" op
(define my-app/handlers
  (make-response/output
   (λ (op)
 (with-handlers ((exn:fail? (λ (ex) (display "Eeek!" op
   (error "Oooops")
   (display "Hello" op)

(serve/servlet my-app/error
   #:servlet-regexp #rx""
   #:command-line? #t)

If we run this server, and dereference , for 
example with curl, then the retrieval simply hangs.


It appears that the handler in 
web-server-lib/web-server/response.rkt:148 is supposed to handle this 
case, but it appears not to.  I think it's possible the handler should 
be in to-chunker-t instead or as well.


This means that a further possibility is to have an exception handler 
within the serialiser, and handle exceptions appropriately there (as in 
my-app/handlers above).  However all this means that a carefully-written 
servlet _must_ have such handlers, if an inadvertent exception in the 
serialiser procedure isn't to stall a client.


Best wishes,

Norman


--
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/AB2357DF-5A41-429F-A7BB-7B4321EEDBE3%40glasgow.ac.uk.

RE: [racket-users] Re: local variables are hyperlinked inscribble/manual

[Jos Koot]

Thank you Ryan and Ryan.

I think make-element-id-transformer is the easiest solution.
(let ([set #f])   (racket set)) is nice too because it can be used just where 
needed.
I’ll try if that works around an interaction too.

An expression containing ‘set’ both as local and as imported variable remains a 
problem, I think,
but never mind, that can and probably must be avoided.

Thanks again, Jos


From: Ryan Culpepper
Sent: 25 May 2020 17:28
To: Ryan Kramer
Cc: Racket Users
Subject: Re: [racket-users] Re: local variables are hyperlinked 
inscribble/manual

You can also use make-element-id-transformer, like this:

    (define-syntax SET
      (make-element-id-transformer
       (lambda _ #'(racketvarfont "set"

Then Scribble will automatically replace SET within rendered code with the 
element expression above.

Another trick is to break the for-label binding by introducing a local binding 
that shadows it. For example, if you write

    (let ([set #f])
      (racket set))

then the occurrence of `set` within the `racket` form isn't linked to `set` 
from racket/set. This trick relies on being able to put a let around the 
occurrences you don't want linked but not the ones that you do want linked, so 
it might not work in all cases.

Ryan


On Mon, May 25, 2020 at 4:55 PM Ryan Kramer  wrote:
My favorite way to avoid this problem is simply to choose another name, or use 
`except-in` to avoid importing `set` for-label. But if you must use the name 
`set` and you want it linking to racket/set most of the time (but not this 
time), here is a technique I've used in the past:

#lang scribble/manual

@(require (for-label racket) scribble/eval
  (for-syntax racket
  syntax/parse))

@(define-for-syntax (replace-helper stx orig-sym new-sym)
   (let ([content (syntax-e stx)])
 (cond
   [(list? content)
    (datum->syntax stx
   (map (λ (child) (replace-helper child orig-sym new-sym))
    content)
   stx stx)]
   [(equal? orig-sym content)
    (datum->syntax #f new-sym stx #f)]
   [else
    stx])))

@(define-syntax (replace stx)
   (syntax-parse stx
 [(_ [orig:id new:id] body:expr)
  (replace-helper #'body (syntax-e #'orig) (syntax-e #'new))]))

@(replace
  [SET set]
  @interaction[
 (let ((SET 1)) (add1 SET))])

On Sunday, May 24, 2020 at 11:26:54 AM UTC-5, jos.koot wrote:
Hi,
I have:
 
#lang scribble/manual
@(require (for-label racket) scribble/eval)
@interaction[
(let ((set 1)) (add1 set))]
 
I prepare a HTML document with DrRacket (in Windows 10).
Works, but local variable set is hyperlinked to procedure set in the documents 
(racket/set). I would like this variable to be typeset as any other local 
variable. How can I do that without loosing the hyperlink where I do mean the 
procedure from racket/set ?
 
Thanks, Jos
-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ffd4f155-ee18-409d-b92f-9450d976220f%40googlegroups.com.
-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CANy33qk3Q3F6uLx9_Y%2BRNUb4j-z4DEuH3_%2BEgSc4evnNHpoXgg%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5ecbeed6.1c69fb81.358b9.eec7%40mx.google.com.

Re: [racket-users] Re: local variables are hyperlinked in scribble/manual

[Ryan Culpepper]

You can also use make-element-id-transformer, like this:

(define-syntax SET
  (make-element-id-transformer
   (lambda _ #'(racketvarfont "set"

Then Scribble will automatically replace SET within rendered code with the
element expression above.

Another trick is to break the for-label binding by introducing a local
binding that shadows it. For example, if you write

(let ([set #f])
  (racket set))

then the occurrence of `set` within the `racket` form isn't linked to `set`
from racket/set. This trick relies on being able to put a let around the
occurrences you don't want linked but not the ones that you do want linked,
so it might not work in all cases.

Ryan


On Mon, May 25, 2020 at 4:55 PM Ryan Kramer 
wrote:

> My favorite way to avoid this problem is simply to choose another name, or
> use `except-in` to avoid importing `set` for-label. But if you must use the
> name `set` and you want it linking to racket/set most of the time (but not
> this time), here is a technique I've used in the past:
>
> #lang scribble/manual
>
> @(require (for-label racket) scribble/eval
>   (for-syntax racket
>   syntax/parse))
>
> @(define-for-syntax (replace-helper stx orig-sym new-sym)
>(let ([content (syntax-e stx)])
>  (cond
>[(list? content)
> (datum->syntax stx
>(map (λ (child) (replace-helper child orig-sym
> new-sym))
> content)
>stx stx)]
>[(equal? orig-sym content)
> (datum->syntax #f new-sym stx #f)]
>[else
> stx])))
>
> @(define-syntax (replace stx)
>(syntax-parse stx
>  [(_ [orig:id new:id] body:expr)
>   (replace-helper #'body (syntax-e #'orig) (syntax-e #'new))]))
>
> @(replace
>   [SET set]
>   @interaction[
>  (let ((SET 1)) (add1 SET))])
>
>
> On Sunday, May 24, 2020 at 11:26:54 AM UTC-5, jos.koot wrote:
>>
>> Hi,
>>
>> I have:
>>
>>
>>
>> #lang scribble/manual
>>
>> @(require (for-label racket) scribble/eval)
>>
>> @interaction[
>>
>> (let ((set 1)) (add1 set))]
>>
>>
>>
>> I prepare a HTML document with DrRacket (in Windows 10).
>>
>> Works, but local variable set is hyperlinked to procedure set in the
>> documents (racket/set). I would like this variable to be typeset as any
>> other local variable. How can I do that without loosing the hyperlink where
>> I do mean the procedure from racket/set ?
>>
>>
>>
>> Thanks, Jos
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/ffd4f155-ee18-409d-b92f-9450d976220f%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CANy33qk3Q3F6uLx9_Y%2BRNUb4j-z4DEuH3_%2BEgSc4evnNHpoXgg%40mail.gmail.com.

[racket-users] Re: local variables are hyperlinked in scribble/manual

[Ryan Kramer]

My favorite way to avoid this problem is simply to choose another name, or 
use `except-in` to avoid importing `set` for-label. But if you must use the 
name `set` and you want it linking to racket/set most of the time (but not 
this time), here is a technique I've used in the past:

#lang scribble/manual

@(require (for-label racket) scribble/eval
  (for-syntax racket
  syntax/parse))

@(define-for-syntax (replace-helper stx orig-sym new-sym)
   (let ([content (syntax-e stx)])
 (cond
   [(list? content)
(datum->syntax stx
   (map (λ (child) (replace-helper child orig-sym 
new-sym))
content)
   stx stx)]
   [(equal? orig-sym content)
(datum->syntax #f new-sym stx #f)]
   [else
stx])))

@(define-syntax (replace stx)
   (syntax-parse stx
 [(_ [orig:id new:id] body:expr)
  (replace-helper #'body (syntax-e #'orig) (syntax-e #'new))]))

@(replace
  [SET set]
  @interaction[
 (let ((SET 1)) (add1 SET))])


On Sunday, May 24, 2020 at 11:26:54 AM UTC-5, jos.koot wrote:
>
> Hi,
>
> I have:
>
>  
>
> #lang scribble/manual
>
> @(require (for-label racket) scribble/eval)
>
> @interaction[
>
> (let ((set 1)) (add1 set))]
>
>  
>
> I prepare a HTML document with DrRacket (in Windows 10).
>
> Works, but local variable set is hyperlinked to procedure set in the 
> documents (racket/set). I would like this variable to be typeset as any 
> other local variable. How can I do that without loosing the hyperlink where 
> I do mean the procedure from racket/set ?
>
>  
>
> Thanks, Jos
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ffd4f155-ee18-409d-b92f-9450d976220f%40googlegroups.com.

Re: [racket-users] Re: Should I stop sending packages to the catalog?

[Alex Harsanyi]

On Thursday, April 30, 2020 at 3:59:49 PM UTC+8, Laurent wrote:
>
> Alex, that looks like an interesting workflow. Maybe worth a blog post? ;)
>


Well, it took longer than I anticipated, but here it is: 
https://alex-hhh.github.io/2020/05/dependency-management-in-racket-applications.html

I understand that everyone has a different workflow and my workflow will 
not be directly applicable to them, but hopefully a few ideas can be 
re-used.  I also tried to explain what I would like from a "dependency 
management" solution.

Alex.
 

>
> On Thu, Apr 30, 2020 at 12:11 AM Alex Harsanyi  > wrote:
>
>>
>> You could both send packages to the package catalog and instruct your 
>> users to use a different package source if they wish to use old versions.  
>> I don't see these two options in conflict with each other.
>>
>> As an application writer, I am on the other side of this problem, by 
>> depending on other packages. Having limited time to work on my project I 
>> want to upgrade package dependencies at my own pace.   The solution I found 
>> is to use git submodules and add each package as a submodule to my 
>> application.  I  construct a catalog of these packages, at an exact git 
>> commit, and simply run a raco pkg install, knowing that the exact version 
>> that I want will be there.  From time to time, I update these submodules 
>> and allow some time for fixing any problems that might result from these 
>> updates.  This has worked reasonably well so far, and I can reliably 
>> reconstruct older versions of the application knowing that all dependencies 
>> will be correct for that old version.
>>
>> For my part, for any packages that my application depends on, their 
>> authors can make any breaking changes they want, as this will not 
>> immediately break my application.  At a later date I can review these 
>> changes, update my application and move to the new version.
>>
>> The only downside is that installed packages are at "user scope" rather 
>> than "application scope" so once installed from the git submodules, that 
>> package becomes available to all applications on my computer.   So far this 
>> has not been a real issue, although I had to uninstall, switch catalogs and 
>> re-install a few times.
>>
>> I personally regard pkgs.racket-lang.org as the source for the latest 
>> package versions, for users which just started using the package. Users who 
>> need precise versioning, can always setup their own package catalogs (i 
>> discovered that it is a really simple process)
>>
>> Alex.
>>
>>
>> On Thursday, April 30, 2020 at 12:47:25 AM UTC+8, Sage Gerard wrote:
>>>
>>> April 9th in the #general Slack channel taught me that there was no 
>>> clean way to
>>> release a breaking change in a package. I'm open to working on version 
>>> pinning
>>> support in raco pkg provided that a maintainer can walk me through some 
>>> code.
>>>
>>> In the meantime, as much as I appreciate the efforts made in the current 
>>> system,
>>> I'm considering stopping my contributions to the package catalog until 
>>> further notice.
>>> I'm open to submitting packages if I am confident in their longevity, 
>>> but I don't want
>>> to end up in the position I've been in for the last few weeks when 
>>> planning a release.
>>> That position being an inability to release an edition that is not in 
>>> some way "aware"
>>> of a prior edition. In my view, changing the package/collection name is 
>>> an
>>> example of that problem, not a solution to it.
>>>
>>> I'm considering asking my users to specify different package sources in 
>>> their info.rkt
>>> files when dealing with my work. Before I commit to that decision, I 
>>> wanted to tap into
>>> those of you who have already been here. How have you handled breaking 
>>> changes
>>> for your projects? How have you communicated with your users to make 
>>> sure they
>>> were adequately prepared? Am I being too black-and-white about this?
>>>
>>> *~slg*
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/b3b54ccf-b4f1-425e-802a-110d5ac26591%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ddfa63d5-974b-43af-969c-df147470920f%40googlegroups.com.

Re: [racket-users] Migrating from a "model-driven" language framework to Racket

[Jens Axel Søgaard]

Hi Guillaume,

Thanks for taking the time to write this question.

...
> My main concern is about managing the scopes/lexical contexts in my
language.
> I am still browsing the documentation but I have found no library or
guide that addresses this issue.
> The language examples that I have found are either too simple (their
scoping rules can be easily mapped to those of Racket through macros),
> or use ad-hoc techniques, so that it is difficult to infer a general
methodology.

There are several approaches. As you have found out the simplest is to map
language constructs to similar Racket forms.
If the scoping rules are different, you can consider implementing Racket
forms with new scoping constructs first,
and then map your dsl to your new forms.

> Maybe I can create a small example to further illustrate what I want to
do and where I am stuck.
I think that's a good idea. It is much easier to provide feedback based on
a concrete example.


/Jens Axel





Den tor. 21. maj 2020 kl. 18.36 skrev Guillaume Savaton <
guillaume.sava...@gmail.com>:

> I am a Racket beginner trying to create my own DSL.
> As a long-time user of Xtext and other similar tools in the Eclipse
> ecosystem, I have come to Racket expecting that it would address similar
> concerns.
> At the moment, I have mixed feelings: I find the metaprogramming
> facilities in Racket very effective, but at the same time I am struggling
> to achieve tasks that were supported natively by Xtext.
>
> For those who don't know Xtext, here is a summary of how it works:
>
>- A language project is based on a grammar with attribute annotations.
>- The grammar is converted into a "metamodel", i.e. a set of classes
>where each grammar rule corresponds to a class.
>- A parser is automatically generated. It can convert some source text
>into a "model", i.e. a set of instances of the classes from the metamodel.
>- A model can be manipulated using Java APIs. Specialized languages
>are available to constrain a model, query it, transform it, or generate
>code using templates.
>
>
> In Racket, I have started my language project by reproducing what I would
> have done in Xtext:
>
>- I have created a grammar with bragg
>- I have written a set of syntax classes that play the role of the
>metamodel
>- Syntax objects play the role of the model, and I can get their
>attributes with syntax-parse
>- I have written several macros that can generate Racket code in the
>simplest cases.
>
>
> However, I miss some facilities that Xtext provides out-of-the-box:
>
>- Racket syntax classes do not directly support inheritance.
>- Syntax objects are not tied to syntax classes in a class-instance
>relationship, and I have to use syntax-parse every time I want to read an
>attribute.
>- Xtext automatically creates child->parent references in the
>generated AST. In Racket, it seems that I cannot get the parent of a syntax
>object.
>- Xtext provides a default mechanism for resolving named references,
>and a scoping API for languages that need specific scoping rules. The AST
>generated by Xtext is actually an object graph rather than a tree.
>
>
> My main concern is about managing the scopes/lexical contexts in my
> language. I am still browsing the documentation but I have found no library
> or guide that addresses this issue.
> The language examples that I have found are either too simple (their
> scoping rules can be easily mapped to those of Racket through macros), or
> use ad-hoc techniques, so that it is difficult to infer a general
> methodology.
>
> So far, I have made two attempts to work around these issues: (1) by
> creating a metamodel-like data structure using Racket structs, and
> transforming syntax objects into struct instances; or (2) using syntax
> objects only and attaching context data to each of them as a syntax
> property.
> Both have strengths and weaknesses, and I am still feeling that I am not
> using Racket with the right mindset.
>
> I hope I have made my concerns clear. Maybe I can create a small example
> to further illustrate what I want to do and where I am stuck.
> Have you experienced similar concerns in one of your projects?
> What design patterns would you recommend ?
> Do you know any well-commented real-life example that I could use for
> inspiration?
>
> Thanks in advance for your answers.
>
> Guillaume Savaton
>
> N.B: I have also published a similar question at stackoverflow two weeks
> ago, but it still has no answer:
>
> https://stackoverflow.com/questions/61622912/domain-specific-languages-in-racket-compared-to-model-driven-frameworks-such-as
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>