Re: [racket-users] abort test but not test suite?

[Alexis King]

The check-equal? function and friends don't do anything special to delimit 
control, so failing a check will abort the whole program if it isn't contained 
within a test case. You can use the test-case or test-begin forms to limit the 
extent of fail-check (which just raises an exn:test:check exception).

(test-begin
  (check-equal? (f x) 4))

Alternatively, you might want to take a look at define-simple-check, 
define-binary-check, and define-check, which allow that sort of control without 
explicitly wrapping checks in test cases.

 On Mar 30, 2015, at 13:52, 'John Clements' via users-redirect 
 us...@plt-scheme.org wrote:
 
 I’m writing a test suite, and I’d like a way to abort a test without aborting 
 a test suite.  It looks to me like “fail-check” is supposed to do this. 
 Here’s the code I wrote:
 
 #lang racket
 
 (require rackunit)
 
 (define (f x)
  (fail-check foo)
  (/ 1 0))
 
 (check-equal? (f 3) 4)
 (check-equal? 9 13)
 
 I would like for the first test to fail with error message “foo”, and the 
 second one to fail normally.
 
 However, the ‘fail-check’ aborts the test and all remaining tests. Is this 
 the expected behavior?
 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] carmack s-expression tweet

[Alexis King]

It might be interesting to create a binary s-expression format for more 
efficient reading/writing, a la BSON’s relationship to JSON. Perhaps even with 
some sort of optional compression. Racket’s reader is fairly complicated, 
though, so it might need to restrict itself to a useful subset?

 On Mar 27, 2015, at 16:12, John Carmack jo...@oculusvr.com wrote:
 
 On Friday, March 27, 2015 at 2:45:00 PM UTC-5, Brian Craft wrote:
 Was this a reference to a particular racket lib? And if so, which one?
 
 https://twitter.com/ID_AA_Carmack/status/577878167542734848
 
 I have a long history of bit packing multiplayer network messages, but for 
 this project I am just sending text s-expressions with read and write, and my 
 life is much better.  Yes, it is bulkier, but I'm sending binary VoIP data 
 after it, so it won't dominate bandwidth, and making software easier to write 
 and more reliable is a fine way to spend some of our wealth of resources 
 today.
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] carmack s-expression tweet

[Alexis King]

Oh, very neat... racket/fasl was precisely the sort of thing I was thinking of.

 On Mar 27, 2015, at 17:26, Jay McCarthy jay.mccar...@gmail.com wrote:
 
 Look at my original response to John's post about this... The binary format 
 you are thinking of is racket/fasl.
 
 Jay
 
 On Friday, March 27, 2015, Sean Kanaley skana...@gmail.com 
 mailto:skana...@gmail.com wrote:
 Couldn't this binary s-expression just be a struct?
 
 '(move 3 5)
 
 becomes
 
 (struct move (x y) #:prefab)
 (move 3 5)
 
 client/server will likely have some kind of matching either way, and prefab 
 structs can be matched
 
 (match command
   [(list 'move x y) ...
 
 becomes
 
 (match command
   [(move x y) ...
 
 On Fri, Mar 27, 2015 at 7:15 PM, Alexis King lexi.lam...@gmail.com 
 javascript:_e(%7B%7D,'cvml','lexi.lam...@gmail.com'); wrote:
 It might be interesting to create a binary s-expression format for more 
 efficient reading/writing, a la BSON’s relationship to JSON. Perhaps even 
 with some sort of optional compression. Racket’s reader is fairly 
 complicated, though, so it might need to restrict itself to a useful subset?
 
  On Mar 27, 2015, at 16:12, John Carmack jo...@oculusvr.com 
  javascript:_e(%7B%7D,'cvml','jo...@oculusvr.com'); wrote:
 
  On Friday, March 27, 2015 at 2:45:00 PM UTC-5, Brian Craft wrote:
  Was this a reference to a particular racket lib? And if so, which one?
 
  https://twitter.com/ID_AA_Carmack/status/577878167542734848 
  https://twitter.com/ID_AA_Carmack/status/577878167542734848
 
  I have a long history of bit packing multiplayer network messages, but for 
  this project I am just sending text s-expressions with read and write, and 
  my life is much better.  Yes, it is bulkier, but I'm sending binary VoIP 
  data after it, so it won't dominate bandwidth, and making software easier 
  to write and more reliable is a fine way to spend some of our wealth of 
  resources today.
 
  --
  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 
  javascript:_e(%7B%7D,'cvml','racket-users%2bunsubscr...@googlegroups.com');.
  For more options, visit https://groups.google.com/d/optout 
  https://groups.google.com/d/optout.
 
 --
 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 
 javascript:_e(%7B%7D,'cvml','racket-users%2bunsubscr...@googlegroups.com');.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 -- 
 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 
 javascript:_e(%7B%7D,'cvml','racket-users%2bunsubscr...@googlegroups.com');.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 -- 
 Jay McCarthy
 http://jeapostrophe.github.io http://jeapostrophe.github.io/
 
Wherefore, be not weary in well-doing,
   for ye are laying the foundation of a great work.
 And out of small things proceedeth that which is great.
   - DC 64:33

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] carmack s-expression tweet

[Alexis King]

Hmm, yes, on closer inspection, I see that you’re right. It’s not worthless, 
but it’s definitely not ideal for actually using as a communication protocol. 
So I guess my original point still stands: having a consistent binary encoding 
for s-expressions could be nice.

 On Mar 27, 2015, at 18:10, Neil Van Dyke n...@neilvandyke.org wrote:
 
 Just comenting only on Alexis's suggestion here, since sounds like John is 
 happy with sexps for now.
 
 I don't see how `racket/fasl` is suitable for heterogeneous interop, which is 
 a very common case needing this, perhaps the most common. Spec-wise, 
 `racket/fasl` is not defined, beyond that it can be shared between instances 
 of the same Racket version.  This FASL is fine for writing out compiled code 
 files that are already specific to Racket version, or perhaps IPC or stored 
 serialization when you're certain that the same Racket version will be used 
 to write and read.  Everything else I can think of, you want an open spec.
 
 You could make simple *specified* sexp serialization that is stable between 
 Racket versions and can also be implemented independent of Racket (e.g., 
 write type tag byte according to spec, write byte(s) prefixes for length of 
 variable-length objects, possibly references to pre-shared strings/symbols, 
 and possibly do some kind of string table compression as you go, etc.).  
 There's also always off-the-shelf specs, like Google protobufs.  Protobufs 
 are overkill for most purposes, and can be unnecessarily 
 cumbersome/bureaucratic to work with, but are available, with lots of 
 implementations.
 
 Neil V.
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: [racket] Intercepting WebSocket connections to the Racket web server?

[Alexis King]

I’ll look into what you suggested, but as a general followup to this, what 
would make the most sense for the WebSocket API to be able to receive these 
intercepted requests? I’m looking at the old net/websocket API as a reference, 
and it appears that the only supported server API is using ws-serve, which 
binds to a port and listens on it.

I think I’d want to implement some sort of simpler interface that would allow 
passing the I/O ports on to the WebSocket implementation, which would then 
return a websocket connection object. Does that seem reasonable? Is there 
specific idiomatic way of doing that sort of thing using the web server?

As an aside, I’m actually trying to port some code written as a Node.js server 
to Racket. Specifically, I’m using the Express library for the routing. This is 
what the main server file looks like (actually written in CoffeeScript): 
https://gist.github.com/lexi-lambda/c6da899cfa1d808b9338 
https://gist.github.com/lexi-lambda/c6da899cfa1d808b9338

I like the elegance of this sort of extensible routing system (I require the 
express-ws module, which extends the server to include websocket routing 
support). What would be the closest analogue in the Racket web server with the 
idea of that sort of “extensible” routing?

Thanks for the help,
Alexis

 On Mar 21, 2015, at 19:26, Jay McCarthy jay.mccar...@gmail.com wrote:
 
 The Web server models applications as servlet : request - response
 and there's no way to go from the request to the original HTTP
 connection.
 
 In contrast, the Web server has a lower level concept of a
 dispatcher that receives a parsed HTTP request AND the connection
 object (which has the I/O ports). If the WebSocket handshake has the
 sender start with a correctly formatted HTTP request, then this is
 what you want and you'd go from using something like serve/servlet to
 using something like serve/launch/wait and dispatch/servlet with
 another layer of dispatching.
 
 On the other hand, if the handshake doesn't have a complete request,
 then you'd need to customize the dispatching server directly with a
 new kind of read-request and request structure that can stop in the
 middle. I think what I'd do is make a super-struct and re-use
 everything from the HTTP server when the handshake isn't there.
 
 Jay
 
 On Sat, Mar 21, 2015 at 8:44 PM, Alexis King lexi.lam...@gmail.com wrote:
 The WebSocket handshake is intentionally implemented in such a way so that 
 WebSocket connections can be performed using the same port that the HTTP 
 server is running on. This is implemented by making the handshake a standard 
 HTTP 1.1 GET request with an “Upgrade: websocket” header.
 
 I’m interested in doing this using the Racket web server, but I’m not sure 
 how to intercept websocket connections. I’m completely willing to implement 
 all the websocket connection logic myself, I just need to know how to detect 
 headers sent with that Upgrade header before the web server has a chance to 
 handle them so that I can pass the connection off to my own websocket logic.
 
 What’s the proper way to achieve this sort of thing?
 
 Alexis
 
  Racket Users list:
  http://lists.racket-lang.org/users
 
 
 
 -- 
 Jay McCarthy
 http://jeapostrophe.github.io
 
   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
 And out of small things proceedeth that which is great.
  - DC 64:33

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] carmack s-expression tweet

[Alexis King]

Oh, very neat... racket/fasl was precisely the sort of thing I was thinking of.

 On Mar 27, 2015, at 17:26, Jay McCarthy jay.mccar...@gmail.com wrote:
 
 Look at my original response to John's post about this... The binary format 
 you are thinking of is racket/fasl.
 
 Jay
 
 On Friday, March 27, 2015, Sean Kanaley skana...@gmail.com 
 mailto:skana...@gmail.com wrote:
 Couldn't this binary s-expression just be a struct?
 
 '(move 3 5)
 
 becomes
 
 (struct move (x y) #:prefab)
 (move 3 5)
 
 client/server will likely have some kind of matching either way, and prefab 
 structs can be matched
 
 (match command
   [(list 'move x y) ...
 
 becomes
 
 (match command
   [(move x y) ...
 
 On Fri, Mar 27, 2015 at 7:15 PM, Alexis King lexi.lam...@gmail.com 
 javascript:_e(%7B%7D,'cvml','lexi.lam...@gmail.com'); wrote:
 It might be interesting to create a binary s-expression format for more 
 efficient reading/writing, a la BSON’s relationship to JSON. Perhaps even 
 with some sort of optional compression. Racket’s reader is fairly 
 complicated, though, so it might need to restrict itself to a useful subset?
 
  On Mar 27, 2015, at 16:12, John Carmack jo...@oculusvr.com 
  javascript:_e(%7B%7D,'cvml','jo...@oculusvr.com'); wrote:
 
  On Friday, March 27, 2015 at 2:45:00 PM UTC-5, Brian Craft wrote:
  Was this a reference to a particular racket lib? And if so, which one?
 
  https://twitter.com/ID_AA_Carmack/status/577878167542734848 
  https://twitter.com/ID_AA_Carmack/status/577878167542734848
 
  I have a long history of bit packing multiplayer network messages, but for 
  this project I am just sending text s-expressions with read and write, and 
  my life is much better.  Yes, it is bulkier, but I'm sending binary VoIP 
  data after it, so it won't dominate bandwidth, and making software easier 
  to write and more reliable is a fine way to spend some of our wealth of 
  resources today.
 
  --
  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 
  javascript:_e(%7B%7D,'cvml','racket-users%2bunsubscr...@googlegroups.com');.
  For more options, visit https://groups.google.com/d/optout 
  https://groups.google.com/d/optout.
 
 --
 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 
 javascript:_e(%7B%7D,'cvml','racket-users%2bunsubscr...@googlegroups.com');.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 -- 
 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 
 javascript:_e(%7B%7D,'cvml','racket-users%2bunsubscr...@googlegroups.com');.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 -- 
 Jay McCarthy
 http://jeapostrophe.github.io http://jeapostrophe.github.io/
 
Wherefore, be not weary in well-doing,
   for ye are laying the foundation of a great work.
 And out of small things proceedeth that which is great.
   - DC 64:33

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Save as Scribble file extension

[Alexis King]

I’ve done this, too. Could there be some way for #langs to report a default 
file extension to DrRacket?

 On Apr 9, 2015, at 15:31, Prabhakar Ragde plra...@uwaterloo.ca wrote:
 
 When I am editing a Scribble file in DrRacket and use Save Definitions 
 As... to start a new version, the system file dialog comes up (I am using OS 
 X) and the file name defaults to Untitled.rkt with the Untitled highlighted 
 (so I can type in my file name). But the file extension is wrong. I usually 
 want myfile.scrbl in this case, but I have saved so many instances of 
 myfile.rkt. Is it possible to have the file extension default to the current 
 one?
 
 This is not the only or greatest annoyance I encounter while editing Scribble 
 files in DrRacket, but this one might have an easy fix, while I suspect some 
 of the others (e.g. indentation) are going to be thornier and more long-term. 
 Thanks. --PR
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: What is the purpose of the undocumented #:dispatch option for define-generics?

[Alexis King]

Actually, looking over this, it looks like #:dispatch just overrides the 
existing predicate rather than augmenting it in any way. This still seems 
pretty strange. What is the use case for this?

 On Apr 24, 2015, at 00:49, Alexis King lexi.lam...@gmail.com wrote:
 
 I’m working my way through the implementation of racket/generic, and this 
 jumped out at me as a little odd. Apparently, in the #:defaults and 
 #:fast-defaults clauses of define-generics, there is support for an 
 undocumented #:dispatch clause. Using it looks a like this:
 
 (define-generics fooable
  (foo fooable)
  #:defaults
  ([list? #:dispatch empty?
(define (foo fooable)
  (displayln the empty list was foo'd))]))
 
 As far I can tell, all this does is introduce an extra predicate that is 
 checked in addition to the other one. As far as I can tell, this could just 
 be done with (and/c list? empty?), so this feels quite redundant. More 
 bizarre, if the #:dispatch clause is omitted, then it defaults to the same as 
 the first predicate!
 
 This means that the predicate is, when used as documented, always applied 
 twice for no reason I can discern. Any authors of racket/generic that could 
 provide some insight on what this is and why it exists?
 
 Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] What is the purpose of the undocumented #:dispatch option for define-generics?

[Alexis King]

I’m working my way through the implementation of racket/generic, and this 
jumped out at me as a little odd. Apparently, in the #:defaults and 
#:fast-defaults clauses of define-generics, there is support for an 
undocumented #:dispatch clause. Using it looks a like this:

(define-generics fooable
  (foo fooable)
  #:defaults
  ([list? #:dispatch empty?
(define (foo fooable)
  (displayln the empty list was foo'd))]))

As far I can tell, all this does is introduce an extra predicate that is 
checked in addition to the other one. As far as I can tell, this could just be 
done with (and/c list? empty?), so this feels quite redundant. More bizarre, if 
the #:dispatch clause is omitted, then it defaults to the same as the first 
predicate!

This means that the predicate is, when used as documented, always applied twice 
for no reason I can discern. Any authors of racket/generic that could provide 
some insight on what this is and why it exists?

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Another typed/racket puzzle: module+ and scope

[Alexis King]

Yes, it’s a known bug that submodules are broken within Typed Racket. I’m not 
entirely clear on the details, but I believe it is suspected that the reason is 
actually due to a bug in the macro expander, which should be fixed with Matthew 
Flatt’s new scope-sets model.

Otherwise, I don’t think there’s a particularly good workaround for this issue, 
so you’ll probably just have to avoid submodules in TR for the time being.

 On May 4, 2015, at 03:33, Norman Gray nor...@astro.gla.ac.uk wrote:
 
 
 Greetings.
 
 I have come across another occasion where TR appears to behave in an 
 unexpected way.
 
 Consider:
 
 %  cat add1.rkt
 #lang typed/racket/base
 
 (provide add1)
 
 (: add1 (- Integer Integer))
 (define (add1 x)
  (+ x 1))
 % cat call-add1.rkt
 #lang typed/racket/base
 
 (require add1.rkt)
 
 (module+ main
  ;(require add1.rkt)
  (printf 2 + 1 = ~a~% (add1 2)))
 % racket call-add1.rkt 
 add1.rkt:3:9: Type Checker: missing type for identifier;
 consider using `require/typed' to import it
  identifier: add1
  from module: add1.rkt
  in: add1
  context...:
   
 /Data/LocalApplications/Racket/6.1.1/share/pkgs/typed-racket-lib/typed-racket/typecheck/tc-toplevel.rkt:275:0:
  type-check
   
 /Data/LocalApplications/Racket/6.1.1/share/pkgs/typed-racket-lib/typed-racket/typecheck/tc-toplevel.rkt:411:0:
  tc-module
   
 /Data/LocalApplications/Racket/6.1.1/share/pkgs/typed-racket-lib/typed-racket/tc-setup.rkt:40:0:
  tc-setup
   
 /Data/LocalApplications/Racket/6.1.1/share/pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:25:4
   standard-module-name-resolver
 %  racket --version  
 Welcome to Racket v6.1.1.
 %
 
 It appears that the add1 is visible within the main module, but its type 
 isn't.  Adding the (require) inside the module produces the same error.  
 Adding the (require) inside the module and removing it from the enclosing 
 module does work in this example, but obviously makes add1 invisible in that 
 enclosing module.
 
 The TR documentation for #%module-begin 
 http://docs.racket-lang.org/ts-reference/special-forms.html?q=module-begin#%28form._%28%28lib._typed-racket%2Ftyped-racket..rkt%29._~23~25module-begin%29%29
  says
 
 Otherwise, the #%module-begin form of typed/racket behaves like 
 #%module-begin from racket.
 
 I take that to suggest that there should be no surprises here.  Looking 
 through the TR reference, the only other mention I can see of modules is in 
 Sect. 5.1 on 'Untyped Utilities'.  I can't see any notes on this in the TR 
 Guide Sect. 8, 'Caveats and Limitations'.
 
 As an additional remark (and this is a little weird), if I give in, and try 
 to use require/typed, then I get a rather perplexing error:
 
 % cat call-add1.rkt
 #lang typed/racket/base
 
 (require add1.rkt)
 
 (module+ main
  (require/typed add1.rkt [add1 (- Integer Integer)])
  (printf 5 + 1 = ~a~% (add1 5)))
 % racket call-add1.rkt  
 add12: unbound identifier;
 also, no #%top syntax transformer is bound
  in: add12
  context...:
   
 /Data/LocalApplications/Racket/6.1.1/share/pkgs/typed-racket-lib/typed-racket/utils/require-contract.rkt:13:0
   
 /Data/LocalApplications/Racket/6.1.1/share/pkgs/typed-racket-lib/typed-racket/tc-setup.rkt:40:0:
  tc-setup
   
 /Data/LocalApplications/Racket/6.1.1/share/pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:25:4
   standard-module-name-resolver
 %
 
 Best wishes,
 
 Norman
 
 
 -- 
 Norman Gray  :  http://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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Instantiating a module in a meta-language

[Alexis King]

I’ve written a meta-language that adds function literal syntax to the reader, 
inspired by Clojure and Rackjure’s shorthand function literals. It uses curly 
braces for these literals, so #{+ 2 %} reads as (lambda (%) (+ 2 %)).

This actually works great, but I also want to add a feature that the shorthand 
syntax becomes a shorthand for curry if no arguments are specified, so #{+ 2} 
reads as ((curry +) 2). This works fine when the language I pass to my 
meta-language is racket, but it fails in racket/base because the curry function 
is from racket/function, which hasn’t been instantiated. This is the error I 
get:

require: namespace mismatch;
 reference to a module that is not available
  reference phase: 0
  referenced module: ~/gits/racket/racket/collects/racket/function.rkt
  referenced phase level: 0 in: curry

Is there any way for my meta-language to force this to be instantiated whenever 
my meta-language is used? I’m using make-meta-reader from syntax/module-reader 
to implement my meta-language.

Thanks!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Why doesn't my readtable extension work in the REPL?

[Alexis King]

Perfect, thanks to both of you for your help. I’ve pushed a fix based on the 
at-exp implementation.

I actually didn’t know about afl, but I’m pleased to see that it works 
relatively similarly! I still like my syntax and auto-currying better, but I’m 
biased. ;)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Getting a sandboxed evaluator to work with a custom #lang's reader

[Alexis King]

Continuing my attempts to make a working meta-language, I'm now working on 
improving the documentation. I'd like to be able to use “interaction” from 
scribble/eval with a custom evaluator, but I'm having trouble getting a custom 
evaluator to work with my language.

I've tried using (make-module-evaluator #lang curly-fn racket/base), but that 
only enables the curly-fn reader for reading the initial program, not the 
additional input passed to the evaluator.

I have managed to do this sort of thing to get it working.

(parameterize ([sandbox-output 'string]
   [sandbox-error-output 'string]
   [sandbox-reader
(λ (in)
  (parameterize ([current-readtable (make-curly-fn-readtable)])
(reverse
 (let loop ([acc null])
   (define r (read-syntax in (current-input-port)))
   (if (eof-object? r) acc (loop (cons r acc)))])
  (make-module-evaluator #lang curly-fn racket/base))

That works, but I'm wondering if there's a better way.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Strange behaviour of the eq? operator in racket repl

[Alexis King]

Yes, Scheme (and therefore Racket) has eq?, eqv?, and equal?. I understand the 
desire for eq? and equal?, but I’ve always been skeptical of the necessity of 
eqv?. Either way, Scheme left this behavior unspecified, but I believe Racket 
specifies it (though I could be wrong).

Racket has two kinds of symbols, interned and uninterned. Symbols produced by 
the reader, whether via read or read-syntax, are interned. Additionally, 
string-symbol produces interned symbols. Certain functions such as gensym and 
string-uninterned-symbol produce uninterned symbols, but these are not 
commonly encountered, anyway.

Interned symbols, I believe, are guaranteed to be eq? since they’re, well, 
interned. There is a pool of interned symbols such that all symbols made up of 
the same string are all the same object, so they’re all eq?.

I can’t reproduce the behavior in the original message, and I don’t think it 
should be possible.

 On May 17, 2015, at 22:19, Michael Tiedtke michael.tied...@o2online.de 
 wrote:
 
 I'm new to Racket but even R5RS is rather clear about this issue:
 
 (citation from doc/r5rs/r5rs-std/r5rs-Z-H-9.html)
 (eq? 2 2)   ===  unspecified
 
 Rationale:   It will usually be possible to implement eq? much more 
 efficiently than eqv?, for example, as a simple pointer comparison instead 
 of as some more complicated operation. One reason is that it may not be 
 possible to compute eqv? of two numbers in constant time, whereas eq? 
 implemented as pointer comparison will always finish in constant time. Eq? 
 may be used like eqv? in applications using procedures to implement objects 
 with state since it obeys the same constraints as eqv?.
 
 
 You should use = with numbers as far as I remember.
 
 
 Il giorno 18/mag/2015, alle ore 02.41, George Neuner ha scritto:
 
 Hi,
 
 On 5/17/2015 5:32 PM, Atticus wrote:
 ---
 $ racket
 Welcome to Racket v6.1.1.
 (eq? 'l 'l)
 #f
 (eq? 'l 'l)
 #t
 
 
 $ racket --no-jit
 Welcome to Racket v6.1.1.
 (eq? 'l 'l)
 #f
 (eq? 'l 'l)
 #t
 (eq? 'l 'l)
 #f
 (eq? 'l 'l)
 #t
 (eq? 'l 'l)
 #t
 (eq? 'l 'l)
 #t
 (eq? 'l 'l)
 #f
 (eq? 'l 'l)
 #f
 
 
 ---
 
 How to reproduce this behaviour? Just start racket from the command line
 and type '(eq? 'l 'l), this should return #f (or sometimes #t). The next
 time the same expression returns #t. Whats also interesting is that with
 the command line option --no-jit the return value seems to randomly
 change between #t and #f.   ...
 
 I can't reproduce this.  Might there have been some control characters 
 accidentally in your input?
 
 I have 6.1.1  32-bit and 64-bit on Windows 7, and 64-bit on Centos 6.6 and 
 Ubuntu 14.04.  Tried them all  with and without JIT.  Also tried the repl in 
 DrRacket on Windows (Linux are command line only).   All worked as expected.
 
 George
 
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Specifying a contract for the end of a list

[Alexis King]

I've recently wanted a contract that lets me check the last element of a 
(potentially improper) list, ignoring the other elements. To do this in a 
general sense, I came up with this.

(define (listof* init/c last/c)
  (flat-named-contract
   `(listof* ,(contract-name init/c) ,(contract-name last/c))
   (flat-rec-contract listof* last/c (cons/c init/c listof*

That definition can then be used like this.

(define/contract num-tail
  (listof* any/c number?)
  '(a b c . 4))

The use-case I've found most helpful, though, is combining it with listof 
contracts to check sequences within lists or at the end of the lists.

(define/contract num-tail-proper
  (listof* any/c (list/c number?))
  '(a b c 4))

This works, but it only works with flat contracts. Would it be possible to 
generalize this to work with all contracts? Also, would this sort of combinator 
make sense in the standard library? The name I've used probably wouldn't be 
usable (since it could be confused with list*of), but I think the functionality 
is helpful.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Struggling with macros

[Alexis King]

What exactly is the difference here between your define-opcode macro and 
Racket’s define-struct form? For example, simply doing (define-struct A2 result 
left right relop) would generate make-A2, A2? A2-result, A2-left, etc.

What you describe is certainly possible, but I don’t think it’s currently clear 
why exactly you’d prefer your solution over just using the struct built-in. 
Could you elaborate on the differences between your domain-specific approach 
and the Racket form?

 On Apr 13, 2015, at 08:11, Nils Van Geele nils.vge...@gmail.com wrote:
 
 Hey all,
 
 Bit of context: I'm writing a compiler for a course and decided to use 
 Racket. I'm translating an AST to three address code-like instructions. 
 Because I do not want to manually write a great deal of boilerplate code for 
 each opcode, I figured I could use macros.
 
 I have a struct `instruction' that holds the argument registers/options, 
 result register, and the opcode. Using the macro I have in mind, I could for 
 instance generate all boilerplate for the A2 opcode (A = B binop C):
 
  (define-opcode A2
(result #t)
(arg left)
(arg right)
(arg relop))
 
 This would create the functions:
 - (make-A2 left right relop result), which creates a new instance of the 
 instruction struct
 - (A2? obj), which checks if obj is an instruction struct and the opcode 
 maches A2
 - (A2-left obj) and so on, all accessor functions
 
 In an opcode constructor such as make-A2, result is always the last argument, 
 and all other arguments are in the order in which they are defined.
 
 I already managed to write a much more simple version, which can be used as 
 follows:
 
  (define-opcode A2 #t 3)
 
 Which will just generate functions like make-A2, A2-arg1, A2-arg2, and so on. 
 However, I prefer the version with (result ...) and (arg ...), but I just 
 can't figure out how to write a macro for it, given that there must be only 
 one occurence of (result ...) and zero or more occurences of (arg ...).
 
 I hope someone will be able to help me or point me to some similar macros for 
 inspiration!
 
 Greetings,
 Nils Van Geele.
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] the Racket manifesto

[Alexis King]

I think Greg Hendershott’s Fear of Macros 
http://www.greghendershott.com/fear-of-macros/ tutorial is pretty top-notch. 
Would it make any sense to adapt and incorporate that into the Racket docs?

 On Apr 9, 2015, at 12:28, Geoffrey Knauth ge...@knauth.org wrote:
 
 Since from his first months learning Racket, my son Alex immediately started 
 diving into the language-altering aspects of Racket, when you do develop a 
 tutorial/pedagogy for that, you might see what reaction he has.
 
 On Thursday, March 26, 2015 at 8:18:53 AM UTC-4, Matthias Felleisen wrote:
 On Mar 26, 2015, at 7:42 AM, Konrad Hinsen wrote:
 
 In my opinion, it would be interesting to develop a pedagogical
 approach to the language development theme in the form of tutorials,
 books, or presentations. Maybe even a teaching language with a
 simplified version of syntax/parse. The goal would be both to lower
 the entry barrier to the most interesting aspects of the Racket
 universe, and to gain insight by teaching, i.e. find better ways
 to do things in the future.
 
 As you probably realize, this is the suggestion -- in more words --
 that is mentioned in the conclusion, and academics who know us will
 interpret this code in exactly this way. 
 
 The idea has been on my mind for years. Three years ago I opened a 
 notes file to get this going by 2015. Sadly, there are no entries
 since 2013 and overall there are only two entries overall. 
 
 But yes, section 3 is the hard part and work on 4 and 5 is 
 substitution as Daniel Kahneman would say. 
 
 -- Matthias
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Implementing a lazy for/stream using for/fold/derived and delimited control

[Alexis King]

I've never particularly loved racket/generator's interface, but you're right 
that it could be a useful base for this sort of abstraction. I do explicitly 
want a stream, but I could use in-generator in tandem with sequence-stream to 
get that.

That said, I would still be interested in figuring out how to roll it myself 
using a solution similar to what I proposed for learning purposes.

 On May 19, 2015, at 23:11, Konrad Hinsen konrad.hin...@fastmail.net wrote:
 
 On 20/05/2015 04:24, Alexis King wrote:
 
 I'm trying to implement a for/stream loop using for/fold/derived that will 
 return a lazy stream, as would be expected. One way to do this is by using 
 delimited control, which is what I'm currently trying. If there's an easier 
 way, let me know, but I'd still like to figure this out as a pedagogical 
 exercise.
 
 If I understand correctly what you are trying to do, the simplest solution 
 seems to be a generator.
 
 =
 #lang racket
 
 (require racket/generator)
 
 (define result-stream
  (in-generator
   (for ([i (in-naturals 10)])
 (yield i
 
 (for ([n result-stream])
  (printf ~s\n n))
 =
 
 This example is a bit pointless because result-stream could just as well be 
 replaced by (in-naturals 10), but I hope it is clear how this could be 
 generalized to a meaningful application.
 
 I use this a lot, to the point of considering defining something like 
 for/sequence to have nicer syntax for this.
 
 Konrad.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Implementing a lazy for/stream using for/fold/derived and delimited control

[Alexis King]

I'm trying to implement a for/stream loop using for/fold/derived that will 
return a lazy stream, as would be expected. One way to do this is by using 
delimited control, which is what I'm currently trying. If there's an easier 
way, let me know, but I'd still like to figure this out as a pedagogical 
exercise.

Right now, I'm just trying to play with for/fold and some control operators to 
get a feel for how a solution should work. Using racket/control, I've managed 
to get this working snippet:

(define result-stream
  (let ()
(define (stream-loop element continue)
  (stream-cons element
   (call-with-values
(thunk (call/prompt continue))
stream-loop)))
(call-with-values
 (thunk
  (prompt
   (for/fold ()
 ([i (in-naturals)])
 (let/cc continue
   (abort i continue)
 stream-loop)))

This will create an infinite, lazy stream bound to ‘result-stream’ containing 
all the natural numbers. It works, which is cool, but it also seems pretty 
overcomplicated.

Is there a better approach to this sort of thing that I'm missing? My intuition 
for working with control operators isn't the best, so I wouldn't be surprised 
if I was overlooking something.

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Implementing a lazy for/stream using for/fold/derived and delimited control

[Alexis King]

As I've continued to experiment with this, I've run into something that I don't 
really understand. I've managed to come up with this snippet of code.

(define (do prompt-tag)
  (define (loop element continue)
(if continue
(+ element (call-with-continuation-prompt continue prompt-tag loop))
element))
  (call-with-continuation-prompt
   (thunk
(for/fold () ([i (in-range 10)])
  (let/cc continue
(abort-current-continuation prompt-tag (let () i) continue)))
(abort-current-continuation prompt-tag 0 #f))
   prompt-tag loop))

(do (default-continuation-prompt-tag))
(do (make-continuation-prompt-tag))

The first of the two calls at the end returns 45, but the second returns 0. Why 
does using a non-default prompt tag change the behavior if I'm installing my 
own prompt anyway?


 On May 19, 2015, at 19:24, Alexis King lexi.lam...@gmail.com wrote:
 
 I'm trying to implement a for/stream loop using for/fold/derived that will 
 return a lazy stream, as would be expected. One way to do this is by using 
 delimited control, which is what I'm currently trying. If there's an easier 
 way, let me know, but I'd still like to figure this out as a pedagogical 
 exercise.
 
 Right now, I'm just trying to play with for/fold and some control operators 
 to get a feel for how a solution should work. Using racket/control, I've 
 managed to get this working snippet:
 
 (define result-stream
  (let ()
(define (stream-loop element continue)
  (stream-cons element
   (call-with-values
(thunk (call/prompt continue))
stream-loop)))
(call-with-values
 (thunk
  (prompt
   (for/fold ()
 ([i (in-naturals)])
 (let/cc continue
   (abort i continue)
 stream-loop)))
 
 This will create an infinite, lazy stream bound to ‘result-stream’ containing 
 all the natural numbers. It works, which is cool, but it also seems pretty 
 overcomplicated.
 
 Is there a better approach to this sort of thing that I'm missing? My 
 intuition for working with control operators isn't the best, so I wouldn't be 
 surprised if I was overlooking something.
 
 Thanks,
 Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] DrRacket seems to ignore print-reader-abbreviations?

[Alexis King]

 My guess is that the right thing would be to make pretty-print react to those 
 parameters the way print does but I'm not completely certain. 

That sounds right. The documentation for pretty-print already lists this:

 In addition to the parameters defined in this section, pretty-print conforms 
 to the print-graph, print-struct, print-hash-table, print-vector-length, 
 print-box, and print-as-expression parameters.

Adding print-reader-abbreviations to that list probably makes sense.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] DrRacket seems to ignore print-reader-abbreviations?

[Alexis King]

Looking at this a little bit more, it appears pretty-print has its own 
mechanism for controlling reader abbreviations, in the form of 
pretty-print-abbreviate-read-macros. Oddly enough, setting this to #f still 
causes DrRacket to use abbreviations.

 (print-as-expression #f)
 (pretty-print-abbreviate-read-macros #f)
 (pretty-print '(1 ,2 3))
(1 (unquote 2) 3)
 (print '(1 ,2 3))
(1 ,2 3)

Anyway, I think it would be nice to have pretty-print respect the existing 
print-reader-abbreviations parameter, but since 
pretty-print-abbreviate-read-macros exists, that seems a little unclear.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] strange bug with racket/gui

[Alexis King]

The problem here is that paint-callback is not called synchronously when you 
create a new canvas%, so before the callback code runs, the code following the 
creation of the canvas already attempts to use the drawing context.

Since canvas% implements canvas%, could you use the get-dc method of 
canvas% to retrieve the drawing context instead of using set! from inside 
paint-callback?

 On Jun 2, 2015, at 11:57, Luke Miles rashreportl...@gmail.com wrote:
 
 2 questions.
 
 
 First, when the the attached code is run, `send` throws an error because `dc`
 still has the value of void.
 
 Strangely, if I execute the below line in the REPL after the code has run,
 the rectangle is successfully displayed.
 (send dc draw-rectangle 30 20 10 40)
 
 Why is `dc` still void inside the code but not in the REPL afterwards?
 
 
 Second, I have some *bad* code in the attached file:
 (define canvas (void))
 (define dc (void))
 (new canvas% [parent frame]
 [paint-callback
   (λ (c d)
 (set! canvas c)
 (set! dc d))])
 I couldn't find a direct way to get `dc` and `canvas`, and I didn't want to 
 put
 my entire code in the function that paint-callback calls.
 
 Is there a more straightforward way to get these values?
 
 Thanks!
 -Luke
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.
 graphics-2.rkt

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] DrRacket seems to ignore print-reader-abbreviations?

[Alexis King]

When using DrRacket, the following program prints this output, which surprises 
me:

 (print-as-expression #f)
 (print-reader-abbreviations #f)
 (print '(1 ,2 3))
(1 ,2 3)

Evaluating the same thing from the CLI gives me the result I'd expect:

- (print-as-expression #f)
- (print-reader-abbreviations #f)
- (print '(1 ,2 3))
(1 (unquote 2) 3)

Is this intended behavior, or is this a bug?

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Closing big-bang windows

[Alexis King]

I, for one, thought the idea of “OS” reads and writes from Get Bonus was a neat 
abstraction, even if it is more or less just functional reads and writes to a 
giant hash table. Obviously that’s more complicated than would be appropriate 
for big-bang, but I thought I’d bring it up anyway.

 On Jun 23, 2015, at 8:30 AM, Matthias Felleisen matth...@ccs.neu.edu wrote:
 
 
 I have for years hoped to find time to think about 'distributing state' over 
 handlers in big-bang because I am perfectly aware of the scaling up 
 limitations. Your hashtable idea might be worth exploring. Tony and I are 
 also considering his actor system as a source of ideas. This may also give us 
 a handle at a special-purpose gc as Tony noted yesterday. But now I am way 
 off stuff I have done, and I don't like to discuss things that I might do so 
 forgive me for this much and I'll stop now -- Matthias
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Closing big-bang windows

[Alexis King]

 I guess I could add a close-on-stop clauses for programmers
 such as your son but it sounds almost like he's ready to move
 on to racket proper, as in use the Windowing API directly. 

FWIW, despite big-bang’s position as a teaching tool, I much prefer it over 
using the Windowing API directly, considering it provides a pure interface for 
working with real-time graphical applications. I like big-bang’s approach to 
that problem, and I’ve found myself using it many times due to its ease of use. 
In contrast, racket/gui is frustratingly imperative.

 He may also be interested in Jay's variant of 'universe', 
 which is faster (and comes with sound) or Neil's (experimental)
 3D version. I conjecture that they are both more open to extensions
 than my teaching versions 

I’m aware of pict3d/universe, but I admit I haven’t heard of Jay’s version. Is 
that what lux is? (Either way, it would be nice to get the docs building 
properly on pkg-build, since currently the build fails.)

Anyway, I think it would be nice to have something like 2htdp/universe that’s 
aimed at more experienced programmers. If lux is designed to be that, I’ll 
certainly take a look. Otherwise, would it be worth spending some time figuring 
out how to generalize and scale the ‘universe’ idiom to be a bit more powerful?

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Fast way to map over a list many times, changing ONE element each time?

[Alexis King]

As it turns out, this is a perfect application for my persistent vectors 
library. I used the following test harness, matching your examples and using 
the more “elegant” style of tackling the problem using for loops. I think the 
performance speaks for itself.

#lang racket/base

(require
  alexis/collection
  alexis/pvector)

(define (map-once f ls)
  (extend
   (pvector)
   (for/sequence ([i (in-naturals)]
  [elm (in ls)])
 (set-nth ls i (f elm)

(define (sqr x) (* x x))

(define num-test-cases 1)
(define num-runs-per-f 3)

(define v (extend (pvector) (take num-test-cases (randoms
(displayln pvector method:)
(for ([__ (in-range num-runs-per-f)])
  (time (void (map-once sqr v

; OUTPUT
; 
; pvector method:
; cpu time: 228 real time: 227 gc time: 64
; cpu time: 163 real time: 163 gc time: 71
; cpu time: 122 real time: 121 gc time: 31

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Sending RESTful Commands using Racket

[Alexis King]

You probably want to use the net/http-client library, specifically the 
http-sendrecv function. I’m not 100% sure, but I’d guess that the equivalent 
Racket code for your curl command would look something like this.

(require net/http-client
 net/uri-codec)

(http-sendrecv
 192.168.1.20 /api/username/lights/8/state
 #:method 'PUT
 #:data
 (alist-form-urlencoded
  '((on #t)
(bri 170)
(ct 500)))
 #:headers
 '(Content-Type: application/x-www-form-urlencoded))

See 
http://docs.racket-lang.org/net/http-client.html#%28def._%28%28lib._net%2Fhttp-client..rkt%29._http-sendrecv%29%29

 On Jun 17, 2015, at 7:57 AM, bruc...@gmail.com wrote:
 
 Hello,
 
 I'm new to programming, so patience is appreciated. I'm writing a simple 
 program in Racket to control Phillip Hue Bulbs in a performance environment. 
 Phillips has a simple RESTful API and I'm looking for the Racket commands or 
 library to send the commands. Previously I've used AppleScript to launch bash 
 curl commands, like:
 
   curl -x PUT -d '{on:true,bri:170,ct:500}' 
 http://192.168.1.20/api/username/lights/8/state
 
 Is there an easy way to send a similar message in Racket?
 
 Thank you,
 Bruce

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Persistent vectors: a generic collections proof-of-concept

[Alexis King]

 How does this compare to https://github.com/ijp/pfds/ or the work described 
 in http://www.ccs.neu.edu/racket/pubs/sfp10-kth.pdf ?

In the case of the former, that targets R6RS, while this is intended to be a 
more “native” Racket solution. The latter is in Typed Racket, while this is 
currently in untyped Racket since TR currently doesn't support generics. More 
importantly, however, neither of the linked resources implement this particular 
data structure. The closest would be the HAMT implementation from pfds, but my 
implementation provides a similar structure that is specifically designed to be 
used as a vector, so it's more finely-tuned for that purpose (and it has the 
appropriate interface one would expect for a vector).

In addition to the actual implementation differences, this is also designed 
with my generic collections library in mind to test the process for extending 
it with user-defined collections. So far, that seems to be working well, and 
I'll continue to figure out what needs to be added to the collections library 
as I flesh out the persistent vector implementation.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Persistent vectors: a generic collections proof-of-concept

[Alexis King]

 Hi, the full code is attached (I hope Google Groups will preserve it...).

Thank you for this! There is absolutely a performance gap, and I'll definitely 
look over it and see if I can figure out exactly why (I think a well-built 
sequence-based model should have comparable speed). I did implement an 
equivalent test to the one in your blog post, which I've included at the end of 
this email. While the stateful implementation does indeed perform noticeably 
better, the results I got with my lazy implementation are not nearly as dire as 
you seem to have described.

Specifically, the version operating on 100,000 elements and 1,000,000 elements 
yielded the following times, respectively:

; cpu time: 774 real time: 774 gc time: 195
; cpu time: 7029 real time: 7045 gc time: 1814

I did not encounter any out-of-memory problems in either test.

The test I used is as follows:

#lang racket

(require alexis/collection)

(define (sum seq)
  (foldl + 0 seq))

(define (test-sequence n foo)
  (compose
   sum
   (curry take n)
   (curry map foo)
   (curry filter odd?)))

(time
 ((test-sequence
   100
   (lambda (x)
 (* x
(sin (* pi (/ x 12)))
(+ 1 (exp (- (/ x 100)))
  (in-naturals)))

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Persistent vectors: a generic collections proof-of-concept

[Alexis King]

 Maybe this belongs a bit more to your previous thread, but it can also relate 
 here:
 I see you are making generic sequence interface to collections. Clojure from 
 1.7 seems to move more towards reducebles rather than sequable. I have 
 played with this idea for Racket a bit and it seems to work quite well (I 
 called them streams but in effect they are reducebles):
 
 https://mobiusengineering.wordpress.com/2015/01/11/stateful-streams-in-scheme/

It is my understanding that Clojure's new reducebles interface is not 
intended to replace the existing sequences interface but rather provides an 
alternative, specifically intended to enable parallel folds, trading laziness 
for parallelization. Arbitrary parallel computation is a bit more difficult on 
the Racket VM than on the JVM currently, so I'm not sure if that sort of thing 
would be practical in Racket, but either way, I don't believe this is intended 
to be a general-purpose solution at all.

Anyway, I'll take a look at them in more detail to see precisely what their 
purpose is. I took a look at the blog post you linked, and I admit I'm 
skeptical that such a model is actually any improvement. Composable operations 
can be a derived concept even with the lazy sequence model, akin to Clojure's 
transducers. I'd also posit that having a simple base model for sequences is 
reasonable rather than imposing a much more complex model with possible 
performance benefits.

On the other hand, I'd be quite interested in trying your implementation to 
test the performance differences for myself. Do you have that code in a single, 
self-contained snippet I could take a look at? The blog post itself seems to be 
missing a few bits and pieces, notably iterate-list and stream-of-integers.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Capturing sets of options in a splicing syntax class?

[Alexis King]

I appreciate the help, but I'll point out that I explicitly said I didn't want 
to use `template` in my original message. ;)

 On May 27, 2015, at 05:18, Spencer Florence spen...@florence.io wrote:
 
 try `syntax/parse/experimental/template`.
 
 It gives you access to `??', which basically says use a if present, else b, 
 and some other cool templates besides. From the docs:
 
  
  (syntax-parse #'(m 1 2 3)
 [(_ (~optional (~seq #:op op:expr)) arg:expr ...)
  (template ((?? op +) arg ...))])
 #syntax:197:0 (+ 1 2 3)
  (syntax-parse #'(m #:op max 1 2 3)
 [(_ (~optional (~seq #:op op:expr)) arg:expr ...)
  (template ((?? op +) arg ...))])
 #syntax:198:0 (max 1 2 3)
 
 
 
 
 
 On Wed, May 27, 2015 at 12:03 AM Alexis King lexi.lam...@gmail.com wrote:
 When using syntax/parse, is there a good way to do something like this?
 
 (define-splicing-syntax-class options
   (pattern (~seq (~or (~optional (~seq (~and #:a a?)))
   (~optional (~seq (~and #:b b?)))
   (~optional (~seq (~and #:c c?)))
   (~optional (~seq (~and #:d d?
  ...)
#:attr a/b #'(a? b?)
#:attr c/d #'(c? d?)))
 
 When using the above syntax class to parse #'(#:a #:d #:b), then the a/b 
 attribute should be #'(#:a #:b) and the c/d attribute should be #'(#:d). 
 However, this doesn't work, of course, because if one of the options isn't 
 defined, the attribute will be #f, and the attribute binding will fail.
 
 I can get around that by doing something like this:
 
 (define-splicing-syntax-class options
   (pattern (~seq (~or (~optional (~seq (~and #:a a?)))
   (~optional (~seq (~and #:b b?)))
   (~optional (~seq (~and #:c c?)))
   (~optional (~seq (~and #:d d?
  ...)
#:attr a/b #`(#,@(if (attribute a?) #'(a?) #'())
  #,@(if (attribute b?) #'(b?) #'()))
#:attr c/d #`(#,@(if (attribute c?) #'(c?) #'())
  #,@(if (attribute d?) #'(d?) #'()
 
 But that's rather long-winded and verbose. Even better would be a way to 
 group the clauses within the pattern, something like this:
 
 (define-splicing-syntax-class options
   (pattern (~seq (~or (~and (~seq (~optional (~seq (~and #:a a?)))
   (~optional (~seq (~and #:b b?
 a/b)
   (~and (~seq (~optional (~seq (~and #:c c?)))
   (~optional (~seq (~and #:d d?
 c/d))
  ...)))
 
 But that obviously doesn't work, and I'm not sure what it would do even if it 
 compiled.
 
 Anyway, is there a more concise way to do this? I know it's relatively easy 
 using `template` from syntax/parse/experimental/template, but this is going 
 into the Typed Racket code, so we're intentionally avoiding a dependency on 
 that.
 
 Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Capturing sets of options in a splicing syntax class?

[Alexis King]

When using syntax/parse, is there a good way to do something like this?

(define-splicing-syntax-class options
  (pattern (~seq (~or (~optional (~seq (~and #:a a?)))
  (~optional (~seq (~and #:b b?)))
  (~optional (~seq (~and #:c c?)))
  (~optional (~seq (~and #:d d?
 ...)
   #:attr a/b #'(a? b?)
   #:attr c/d #'(c? d?)))

When using the above syntax class to parse #'(#:a #:d #:b), then the a/b 
attribute should be #'(#:a #:b) and the c/d attribute should be #'(#:d). 
However, this doesn't work, of course, because if one of the options isn't 
defined, the attribute will be #f, and the attribute binding will fail.

I can get around that by doing something like this:

(define-splicing-syntax-class options
  (pattern (~seq (~or (~optional (~seq (~and #:a a?)))
  (~optional (~seq (~and #:b b?)))
  (~optional (~seq (~and #:c c?)))
  (~optional (~seq (~and #:d d?
 ...)
   #:attr a/b #`(#,@(if (attribute a?) #'(a?) #'())
 #,@(if (attribute b?) #'(b?) #'()))
   #:attr c/d #`(#,@(if (attribute c?) #'(c?) #'())
 #,@(if (attribute d?) #'(d?) #'()

But that's rather long-winded and verbose. Even better would be a way to group 
the clauses within the pattern, something like this:

(define-splicing-syntax-class options
  (pattern (~seq (~or (~and (~seq (~optional (~seq (~and #:a a?)))
  (~optional (~seq (~and #:b b?
a/b)
  (~and (~seq (~optional (~seq (~and #:c c?)))
  (~optional (~seq (~and #:d d?
c/d))
 ...)))

But that obviously doesn't work, and I'm not sure what it would do even if it 
compiled.

Anyway, is there a more concise way to do this? I know it's relatively easy 
using `template` from syntax/parse/experimental/template, but this is going 
into the Typed Racket code, so we're intentionally avoiding a dependency on 
that.

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Persistent vectors: a generic collections proof-of-concept

[Alexis King]

As a followup to my last thread regarding my generic collections library, I 
have now created a package that uses it to define an entirely new data 
structure. I've implemented Clojure's 32-way bitmapped tries to create a 
persistent vector implementation. If you're interested in trying it out, it's 
available as a package under the name ‘alexis-pvector’.

Since my collections library only supports immutable collections, Racket's 
built-in immutable vectors aren't very well-suited to my model. My 
implementation of `conj` for Racket vectors is not exactly efficient:

(define (conj vec item)
  (vector-immutable-vector
   (vector-append vec (vector item

With persistent vectors, the majority of conj operations are truly O(1), and a 
small portion (about 3%) of them are O(log_32 n), so the performance overhead 
should be negligible.

Some initial profiling has proved promising:

(time (void (extend #()   (in-range 10
(time (void (extend (pvector) (in-range 10

;; output:
;; cpu time: 41116 real time: 41336 gc time: 6176
;; cpu time: 124 real time: 124 gc time: 3

(define (random-set seq)
  (define l (length seq))
  (for/fold ([seq seq])
([i (in-range 10)])
(set-nth seq (random l) (random

(time (void (random-set (vector-immutable-vector (make-vector 1)
(time (void (random-set (extend (pvector) (take 1 (in-naturals))

;; output:
;; cpu time: 3674 real time: 3677 gc time: 552
;; cpu time: 194 real time: 193 gc time: 8

Admittedly, these tests (especially the first one) are fairly biased towards 
persistent vectors, but even so, they cover two of the most common vector 
operations, so I think they're still relevant.

Some rudimentary documentation is available, but the vast majority of the 
vectors' interface is through the methods provided by alexis/collection. Try 
them out! Let me know if you find any bugs or if you have any performance 
considerations.

As a final note, there are still some improvements that definitely need to be 
made. Currently vectors print as #pvector, which is not very helpful, so 
implementing a custom write procedure is high on my todo list. Also, this is 
not an implementation of RRB vectors, which are an improved version of this 
implementation but are more complex, so I have yet to look into how I could 
adapt this to use that algorithm.

Let me know what you think!

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Persistent vectors: a generic collections proof-of-concept

[Alexis King]

 My lazy-sequence implementation was exactly following SICP: while 
 theoretically pure and good, might not be the best in practice, so I believe 
 your implementation can be much better.
 
 Major performance boost in stateful implementation compared to lazy-sequence 
 with delay and force comes from removing essentially cancelling each other 
 delays and forces. Haskell has stream-fusion that implements this idea 
 differently and with the help from compiler, but creates absolutely seamless 
 interface to Haskell-lists — they’ve done very clever work.
 
 The disadvantage of stateful streams is their complete opaqueness, as at 
 every stage all they are is just a promise to do the computation.

Yes, I think adding state to streams is probably adding an unnecessary level of 
complexity (and as you've mentioned, opaqueness) to the system, but the points 
you've raised are valid. I think it would be well worth it to look into 
aggressively optimizing the stream implementation I use for my collections 
given that it serves as the basis for a large number of operations.

As for fusion, yes, that's a very neat optimization, though obviously not 
entirely practical in a language like Racket. It might be worth exploring the 
“transducers” approach taken by Clojure 1.7, which generalizes a number of 
sequence operations to avoid creating intermediate streams (and can coexist 
peacefully with the more traditional sequence operations).

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] API function naming

[Alexis King]

Perhaps this isn’t applicable in this case, but may I suggest a less-common 
alternative: no prefixing at all? If you put all the commands into a separate 
module, users of the module can use ‘prefix-in’ to choose whatever prefix they 
prefer.

This can be paired with documentation that uses a particular prefix in all its 
examples, encouraging a standard of sorts, but the choice of any prefix would 
still be available if a user prefers. For an example of this in the wild see 
Racket’s own parser-tools library 
(http://docs.racket-lang.org/parser-tools/Lexers.html). The common matchers are 
provided unprefixed in the parser-tools/lex-sre module, but the docs 
consistently use a ‘:’ prefix to create a standardized usage.

This doesn’t eliminate the problem of needing to choose a prefix entirely, but 
it does give a little more flexibility to avoid the fear of choosing a prefix 
some users really don’t like.

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Using ‘except-in’ to exclude identifiers for a single phase level

[Alexis King]

I ran across some behavior that I find a little bit surprising. Consider the 
following module:

  #lang racket/base

  ; the definition of some-fn
  (module a racket/base
(provide some-fn)
(define (some-fn) (void)))

  ; provides some-fn in multiple phase levels
  (module b racket/base
(require (submod .. a)
 (for-syntax (submod .. a)))
(provide some-fn
 (for-syntax some-fn)))

  ; excludes some-fn in phase 0... and phase 1?!
  (module c racket/base
(require (except-in (submod .. b) some-fn))
(provide (all-from-out (submod .. b

  (require 'c)
  (begin-for-syntax
; not defined!
some-fn)

This demonstrates that except-in appears to remove identifiers from *all* phase 
levels, not just phase 0. Is there any way to restrict except-in to a 
particular phase level, or is there a different way to accomplish that sort of 
behavior?

For context, I ran into this while seeing what it would be like to create an 
“r5rs+” lang that permits things like ‘syntax-case’, so I effectively want to 
provide all the bindings from ‘r5rs’, but I want to exclude the ‘#%top’, 
‘#%datum’, and ‘#%app’ bindings that r5rs exports for phase 1, which restrict 
expressions in phase 1 to only use syntax-rules (I’d replace these with the 
normal bindings exported for phase 0).

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Using ‘except-in’ to exclude identifiers for a single phase level

[Alexis King]

Thanks for your help. I did consider the only-meta-in approach, but then I’d be 
excluding the syntax-rules export as well, which I was trying to avoid if 
possible.

 On Jun 29, 2015, at 7:39 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 
 You're right that there's not a form that's like `except-out` but
 constrained both by name and phase. There's also not an export variant
 of `only-meta-in`, which would get your half-way there. You could
 implement a new provide expander to do that.
 
 Otherwise, in addition to the strategy that you describe, another
 possibility is
 
 (require (only-meta-in 0 r5rs)
  ...)
 
 Then you won't have any conflicts from `r5rs` and `racket/base` at
 phase 1, since there won't be any phase-1 imports from `r5rs`.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Using ‘except-in’ to exclude identifiers for a single phase level

[Alexis King]

Nope, that doesn’t work. If you try it, you’ll see that some-fn is still 
available in phase 1. That’s because the (provide (all-from-out (submod .. 
b))) provides it as well, which is why I’ve been struggling.

 On Jun 28, 2015, at 13:09, Benjamin Greenman bl...@cornell.edu wrote:
 
 No problem, just change the provides around. Maybe the problem is that you're 
 missing the (require (for-syntax ...)) ?
 
 (module c racket/base
   ;; Require  provide everything except `some-fun` at phase 1
   (require (for-syntax (except-in (submod .. b) some-fn)))
   (provide (for-syntax (all-from-out (submod .. b
   ;; Require  provide everything at phase 0
   (require (submod .. b))
   (provide (all-from-out (submod .. b

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Using ‘except-in’ to exclude identifiers for a single phase level

[Alexis King]

I think it might be time for me to disclose what I’m actually trying to do here 
to make it more clear. As mentioned in my original message, I’m trying to make 
a module language just like r5rs but with support for syntax-case macros. This 
was my attempt:

#lang racket/base

(require (except-in r5rs define-syntax)
 (for-syntax (only-in racket/base
  syntax quasisyntax unsyntax unsyntax-splicing
  syntax-case with-syntax)
 r5rs))

(provide (all-from-out r5rs)
 define-syntax
 (for-syntax (all-from-out r5rs)
 (all-from-out racket/base)))

This doesn’t work, though, because #%top, #%datum, and #%app are already 
provided for-syntax by r5rs. I can do (except-in r5rs #%top #%datum #%app 
define-syntax), but then those identifiers aren’t defined in phase 0, which 
obviously causes problems.

While writing this email, I realized I can additionally add (only-meta-in 0 
(only-in r5rs #%top #%datum #%app)), which seems to solve the problem. It’s a 
bit of a roundabout solution, though.

 On Jun 28, 2015, at 15:07, Benjamin Greenman bl...@cornell.edu wrote:
 
 Oops. Then I'd want to change the all-from-outs to something more specific, 
 or (preferably) change b to only provide some-fn at one level and make the 
 requiring module be more specific.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Generic collections in Racket

[Alexis King]

Thanks for the feedback! To start out with, let me address your initial three 
points. With regards to the error messages and tooling, I agree completely, and 
I actually think this is one of the areas where Racket can blow Clojure out of 
the water. Contracts alone are pretty expressive, and I'd absolutely like to 
try and make the system a little less opaque than Clojure's.

As for use of persistent data structures, I think it's a good design decision, 
but as I mentioned above in my response to Greg's email, Racket's data 
structures, mainly its vectors, aren't quite up to snuff to handle that model 
just yet. Getting good persistent vectors is a high priority.

With that said, let me address your other points.

 So I see what you're doing as exciting, but would appreciate a bit more about 
 where you're aiming to take this in your introduction. If you could outline 
 your criteria / aims that would be clarifying. Are you aiming for consistency 
 with Clojure or making a judgement call on an intermediate style (c.f. Greg's 
 #lang rackjure)?

I'm aiming to make a library that would feel at home in Racket if 
backwards-compatibility were not an issue. I want this library to feel like 
Racket, not Clojure, but I'm also willing to override some of Racket's 
primitives to implement those ideas. Consider it an experimental proposal for 
#lang racket2.

I really, really want to maintain the simplicity that the library currently 
provides, especially with the implementation of new user-defined data 
structures. Having a few interfaces with a handful of functions apiece is nice. 
The trick is figuring out how to provide enough capability for optimization 
hints to keep everything fast with such a small interface (something that I 
think is absolutely doable).

  (take 5 (range 10))
 #lazy-sequence
 
  (drop 5 (range 10))
 '(5 6 7 8 9)

Alright, let's talk about this. Consider the producer/consumer point I laid 
out above. This library is heavily optimized with the idea that once you start 
manipulating a sequence, it's better to force it into read-only mode instead of 
performing an expensive copy. For a list, dropping elements from the front 
requires no copying at all, so it just returns a list. On the other hand, 
taking elements from the front would require allocating a new list, so instead, 
you get a special kind of sequence that doesn't need to do any copying.

  (take 5 #(0 1 2 3 4 5 6 7 8 9))
 #lazy-sequence
 
  (drop 5 #(0 1 2 3 4 5 6 7 8 9))
 #random-access-sequence

This is the same sort of idea, but here, even dropping elements would require a 
new vector to be allocated. Slow and unnecessary if you're only reading! So 
instead you get a view on the vector as a sequence. If you want to modify it, 
make sure you have the representation you need first. Do (extend #() (drop 5 
#(0 1 2 3 4 5 6 7 8 9))), then modify.

As for printing these sequences... yes, printing as #lazy-sequence sucks. 
Currently you can always force a sequence with sequence-list, but that's 
annoying. Clojure takes the approach of making printing lazy sequences force 
them. This is okay, but it also can be incredibly confusing when side effects 
get evaluated in the REPL but not in code.

I'm unsure about what to do about that particular problem. I'd like to maybe 
add a nicer printer for sequences, but I'm not completely sure what the best 
way to do that is, yet.

  (take 5 (list-vector (range 10)))
 take: contract violation

Ahh, then there's this. This absolutely needs a better error message. See, 
list-vector gives you a mutable vector, and sequence operations only work on 
immutable vectors. I consider this a flaw with Racket's vectors, also something 
I'd hope could be alleviated by a better vector library, but for now, it would 
make sense to add some special error messages for mutable vectors and mutable 
hashtables, which would otherwise just seem to fail mysteriously.

Just for the sake of that example, though, this works:

 (take 5 (vector-immutable-vector (list-vector (range 10
#lazy-sequence

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Generic collections in Racket

[Alexis King]

Thanks for the detailed response!

 One part I'm not sure about is `conj`. I understand sometimes
 whichever end is optimal matters more than the order. But:

Indeed, you are correct. Order does matter, and currently the only way to do 
that sort of thing is with `append`.

 1. What if you do care about the order? IOW should there also be
 generic cons and snoc?

Having a generic cons is a good idea, and I will consider a good way to 
incorporate it. However, there are lots of tradeoffs in various approaches, so 
let me try and outline those quickly.

1. The smaller the actual interface, the better. Right now, gen:sequence only 
contains five functions in it. This is fantastic for keeping code complexity 
down, and it heavily reduces the burden for implementing new collections.

2. The tradeoff, of course, is that adopting a one size fits all model loses 
possible optimization that can come out of more specific implementations. 
Maintaining efficiency in this case loses accuracy, as you've described.

Clojure's library, and therefore mine as well, draws the line between 
production and consumption of sequences. The idea is that, usually, 
collections are produced in the place that knows what their representation 
should best be, and client code just blindly reads the data without caring how 
it's stored.

Usually, if you care specifically about prepending or appending, you need to 
know about what the data structure is, anyway (that sort of operation wouldn't 
make any sense on sets, for example), so most operations that produce sequences 
and type-specific, while operations on sequences are type-agnostic.

Of course, this is partially because Clojure's data structures are just better 
than Racket's, which brings me to your next point...

 2. With ordinary Racket immutable vectors, is the tail really faster?
 I don't think snoc (vector-append original-vector (vector new-item))
 is faster than cons (vector-append (vector new-item)
 original-vector)?

Nope! You're right, it isn't. Currently, `conj` on vectors copies an entire 
vector, which is pretty awfully slow. Clojure uses 32-way bitmapped tries for 
persistent vectors, and those are far, far more efficient for use as a 
persistent data structure. The whole tree doesn't need to be copied for each 
new vector (in fact, most of it can remain the same), so vectors are fast and 
cheap, while still maintaining effectively O(1) lookup.

Furthermore, Clojure provides an additional optimization on its persistent 
vectors that makes additions to the tail of the vector especially fast. This 
behavior means the appending style of `conj` makes sense.

Racket does not have good persistent vectors. This library is designed with the 
hope that a good persistent vector library will arise. Some work has been done 
on implementing rrb-tree vectors in Racket, but they're not done, and I don't 
believe they're currently being worked on.

(This train of discussion could probably be an entirely new thread, but I'll 
leave it at this for now.)

 Also, in my (admittedly limited) time so far with Clojure, I've
 sometimes been confused when eager collections automagically change
 into lazy sequences. If I add side effects (like debugging printfs) to
 code I don't realize is lazy, I utter many WTFs.  I'm not sure to what
 extent that can happen with your library, but if it can, this might be
 good to point out in margin notes and examples.

Yes, this is something I hope to probe out some more with user feedback. If 
someone uses it and runs into something really WTF-worthy, I'll certainly try 
and figure out what the right way to handle it is. Currently, everything that 
can return lazy sequences is noted in the API reference, but making it more 
prominent is a good idea.

As for why the laziness is required to begin with, it's mostly just because 
lazy sequences are a very effective way of effectively implementing iterators 
without needing iterators. A lazy sequence can be turned into a concrete 
sequence with `extend`, and it doesn't need to allocate an entire intermediate 
sequence, which is quite appealing.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Generic collections in Racket

[Alexis King]

 Depending on other design decisions, it make make sense to consider
 this an IDE issue. That is, maybe the best thing is to have some kind
 of interactive value in the REPL that lets the user have control over
 the effects. (And this doesn't just have to be via some kind of
 simplistic mouse clicking -- I think there is a lot of unexplored UI
 space here).

I'd definitely be curious to see what you have in mind beyond some simplistic 
mouse clicking. It would be cool to convey more information about sequence 
values via DrRacket's capability to render snips.

As for Daniel's point about the contract violation, I've pushed a change that 
makes `sequence?` into a custom flat contract, so that example now gives a more 
useful error message:

   (take 5 (list-vector (range 10)))
  take: contract violation
expected: (and/c immutable? sequence?)
given: '#(0 1 2 3 4 5 6 7 8 9), which is mutable

However, this only works when the contract is used alone in a first-order way. 
It doesn't give a helpful error message when used with `first`, for example:

   (first (vector 0))
  first: contract violation
expected: (and/c sequence? (not/c empty?))
given: '#(0)
which isn't: sequence?

It would be possible in this case, of course, to create a `nonempty-sequence?` 
contract, but it still wouldn't work in other cases. Robby, do you know of any 
way I could provide this extra error reporting in more cases while still 
keeping `sequence?` a flat contract?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] typed/rackunit and test-case

[Alexis King]

Since test-case is a macro, require/typed won't help, and unfortunately, 
test-case doesn't work in Racket v6.1.1 (or earlier). It will be fixed in the 
upcoming release, or you can download a snapshot build from here: 
http://www.cs.utah.edu/plt/snapshots/

Otherwise, I don't think there's much you can do besides avoid test-case in 
earlier Racket versions.

 On May 24, 2015, at 22:59, Lehi Toskin lehi.tos...@gmail.com wrote:
 
 When using typed/rackunit, I find that using test-case doesn't seem to want 
 to work properly. The code
 
 (test-case foo (check-true (string=? foo foo)))
 
 gives me several Type Checker errors that give me information I don't know 
 what to do with.
 
 Is this something I need to require/typed for?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Generic collections in Racket

[Alexis King]

 I recently hacked together a little GUI thingy for showing
 enumerations that just let them scroll by inside what looks like the
 normal enumeration print out and it works by sampling and caching the
 first 200 elements of the enumeration, but being careful about errors
 and to staying the user's side of the world during the cache
 population. It does evaluate things at the point displaying is
 happening, but people generally do not have much expectation about
 when those functions are evaluated, so it seems to work well as long
 as errors that happen are printed sanely.

This sounds neat, although I'm not entirely sure I understand it
properly. Do you have this somewhere I could take a look at?

 I'm not completely sure I'm getting the point, but is this something
 that and/c would need to cooperate with? Like for it to recognize that
 sequence? (which maybe should be called sequence/c instead?) is itself
 and and/c and print nested ones better?
 
 Robby

Let me explain: the sequence? predicate is simply the predicate
generated by define-generics, so it recognizes all things that are
sequences. This includes everything that implements gen:sequence as
well as all the defaults.

This can be a little confusing, though, when it comes to mutable
vectors or mutable hash tables. In the #:defaults clause, the predicate
for recognizing vectors and hash tables are (conjoin vector?
immutable?) and (conjoin hash? immutable?). This is the behavior I
want, but it also means that trying to perform a sequence operation on
a mutable vector gives a confusing error message.

- (take 2 (vector 1 2 3 4))
; take: contract violation
;   expected: sequence?
;   given: '#(1 2 3 4)
;   in: the 2nd argument of
;   (-
;exact-nonnegative-integer?
;sequence?
;sequence?)

In that error message, it's entirely unclear what's wrong, especially
since mutable vectors print the same way as immutable vectors.

I want the actual behavior of sequence? to remain identical, but I'd
like to improve the error reporting in these cases to help avoid
confusion. This is the error message I've come up with.

- (take 2 (vector 1 2 3 4))
; take: contract violation
;   expected: (and/c immutable? sequence?)
;   given: '#(1 2 3 4), which is mutable
;   in: the 2nd argument of
;   (-
;exact-nonnegative-integer?
;sequence?
;sequence?)

Perhaps that printout is misleading. The contract is not actually
(and/c immutable? sequence?), it's just sequence?. Maybe it should
say expected: sequence?, which must be immutable. Either way, this
is an improvement over the opaque error reporting of the unmodified
case. I've implemented this contract like so:

(define sequence?*
  (make-flat-contract
   #:name 'sequence?
   #:first-order sequence?
   #:projection
   (λ (blame)
 (λ (val)
   (cond
 [(sequence? val) val]
 [(disjoin vector? hash?)
  ; raise a custom blame error
  ]
 [else
  ; raise the usual blame error
  ])

I've then provided sequence?* as sequence? via rename-out.

However, and/c only uses the first-order check, which is still just
plain sequence?, so contract errors where sequence? is used within a
combinator are just as opaque as before.

- (first (vector 1 2 3 4))
; first: contract violation
;   expected: (and/c sequence? (not/c empty?))
;   given: '#(1 2 3 4)
;   which isn't: sequence?
;   in: the 1st argument of
;   (- (and/c sequence? (not/c empty?)) any)

I'm not sure what the best solution to this problem is. Perhaps
providing some extra information to and/c would be the right approach?
Sorry for the long-winded explanation, I just need to make it clear
that sequence? is really just a plain old predicate, but I've tacked
a custom projection onto it for nicer blame errors.

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Generic collections in Racket

[Alexis King]

 With fallback methods, you can get the best of both worlds.
 
 You can have a base set of methods that implementers of the interface
 need to write, and from which everything else can be derived. The
 derived methods can also be present in the interface, which allows
 implementers to override them if, e.g., their particular data structure
 can implement them more efficiently.
 
 For example, let's say you're implementing a vector-like data
 structure. You can implement, say, `map` efficiently by allocating a
 vector of the right size at the start, then filling it up. By overriding
 the `map` method, this more efficient version will be used instead of
 the fallback.
 
 The `set` library uses this pattern.

Yes, I agree, and I think another thing that will need to come along
with this is a better set of documentation forms for generic
interfaces. Currently, documenting generic interfaces is fairly ad-
hoc, and expressing which methods are required and which are optional
is unclear.

 FWIW, that's pretty close to what Racket's `sequence` datatype (not the
 interface) does. I haven't seen much code that uses them directly.

I think this is mostly because the only way to create sequences is
make-do-sequence, which is honestly terrible. As far as I can tell, it
is neither more efficient nor more expressive than gen:stream, but the
latter is far simpler and more natural to write.

I don't really see the need for sequences in the racket/base sense,
but streams are a good foundation for most lazy sequences, which is
what I've employed for most of the lazy functionality I've used so
far.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Generic collections in Racket

[Alexis King]

It's no secret that I've been angling to try and implement a generic 
collections library in Racket for a while now. After a few iterations, I think 
I've found a model I'm satisfied with. It's become big enough to now consider 
useful, so I'd like to get some feedback. If you're interested:

$ raco pkg install alexis-collections

I've also made the documentation available online here:
http://lexi-lambda.github.io/racket-alexis-collections/

For those interested, the library itself is largely based on Clojure's approach 
to sequences (as such, it only supports immutable collections, at least for 
now). The documentation includes an introduction to the library's general 
philosophy, a few examples of usage, and a comprehensive API reference.

Please let me know what you think, break it, and send me bug reports and/or 
feature requests! I'd like to see how practical this model is in existing 
Racket code as well, so let me know if you encounter any problems applying it 
to other idioms.

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] test submodules vs tests in separate file

[Alexis King]

You could always do something like (require (prefix-in contracted: (submod 
..))) to get separate bindings for the versions contracted by contract-out.

 On May 22, 2015, at 11:37, Anthony Carrico acarr...@memebeam.org wrote:
 
 Has this been an oversight? Do we need two official test submodules?
 One from the inside, and one from without.
 
 -- 
 Anthony Carrico
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Generic collections in Racket

[Alexis King]

 Alexis, think of a lazy sequence as something that the rest of the program 
 will explore. In addition to a GUI-based exploration, I would love to see a 
 programmatic one. Imagine 
 
  (explore-lazy lazy-sequence:exp strictness-pattern:exp)
 
 where (the value of) strictness-pattern is a function that pokes around 
 lazy-sequence and displays. You could provide default strictness-pattern 
 values and you could even provide strictness-patterns that dump values into a 
 scrollable snip. But others could program their own strictness-patterns. The 
 key would be to keep it simple. 

I've thought about this some more since you sent me this message, and I've come 
up with a few potentially interesting ideas for inspecting sequence types. I 
may try and implement some of them to play with that idea.

To put it simply, I think it would be helpful to allow sequences to expose some 
information about themselves through optional method implementations that would 
be displayed and organized via inspection methods. I've already tried something 
like that in the form of `known-finite?` from gen:countable, and it would 
certainly be possible to include some additional methods for extracting 
sequence metadata. It might even be possible to use some of that metadata to 
produce a sequence-custom-write structure type property for default printing of 
sequence, similar to the property already exposed for contracts.

 Note that contracts for lazy sequences could also check via 
 strictness-patterns and memoize the exploration path. If the rest of the 
 program re-explores it's cached in the proxy and if it goes beyond that 
 exploration, consider it a contract violation.

I will note here that Racket streams automatically perform memoization, so once 
a stream has been evaluated, its elements are automatically cached. This itself 
has its tradeoffs (forcing the same sequence twice for the side-effects won't 
work), but it's probably what would be desired in the large majority of cases.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] API design 2 -- variadic styles

[Alexis King]

I’ll second Stephen’s point about keyword arguments. They’re quite common in 
idiomatic Racket, and they are probably the most direct way to address the 
points you’ve mentioned.

Another tool that Racket gives you to make scripting very easy is the ability 
to create fairly expressive DSLs with little effort. I think the best way to do 
this is to create a macro or set of macros that expands to simple functions 
(e.g. +sound), and then still provide those  functions to the user if they want 
to do more complex things with them than the DSL provides. For a good example 
of this, see racket/cmdline’s `command-line` and `parse-command-line`.

For more details, see the documentation for syntax-parse, which can effectively 
be a DSL for writing DSLs. It can be used for anything from adding a little 
sugar to creating a composable macro for handling whole batches of operations 
to creating a whole #lang as a scripting DSL.

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] eval PSA (was Sending Closures to Places)

[Alexis King]

 I don't know why but at some point in the 20th century people really became 
 afraid of viewing programs as pure data (which they are) and started to call 
 it metacircular (which of course also refers to other properties of a list 
 processor treating each and every start of list, i.e. opening parenthese, as 
 an apply instruction).

*sigh* Okay, I’ll bite.

I think I can understand the appeal of wanting to love eval. It’s a Lisp 
tradition to have it, and indeed, it is still one of the first things that 
people mention when describing how Lisps are different from other languages. 
Turning around and admitting that one of our signature features should be 
avoided is not only confusing, it seems to reduce Lisp back to the level of any 
other language. If eval is out, what makes Lisps special anymore?

So of course it can seem freeing to come to the conclusion that all those 
people warning about eval are just “afraid of its power”, and we have so much 
to gain by “rediscovering” this tool, but that’s not really true. Eval may not 
be evil, but I’d consider it one of the worst possible code smells. I cannot 
think of any good uses for eval in Racket.

 One the one hand I reject any security concerns about eval which is as good 
 or bad as input data as are the key codes from your favorite event handling 
 loop determining your programs actions. A simple (send object message 
 arguments) could be implemented by evaluating message in the environment of 
 object, i.e. applying it to the arguments. The use of eval shouldn't be 
 restricted to proclaimed  designers of algorithmic notations but using it 
 correctly needs some understanding of Scheme and its specifications. That 
 necessary knowledge used to be conveyed in a lecture of one semester at the 
 MIT with SICP (I've read).

The argument that all (interesting) programs are input-driven, but to then draw 
the conclusion that eval is no more dangerous than other methods of input 
processing would be quite the fallacy. But I agree with some other people in 
this thread that it isn’t really explained why eval is bad, and really, I’ve 
never read an explanation that has wholly satisfied me.

I don’t think the real reason for spurning eval is to avoid security problems 
or to handle code evaluation in different contexts (though both of those things 
are highly related to the “core” problem with eval). I’d argue that the problem 
with eval is one of abstraction: eval is barely any better than writing 
directly to the underlying runtime or virtual machine.

Scheme is largely derived from one of the most powerful abstractions in the 
history of computer science, the closure. It goes by plenty of names, but the 
reason I pick “closure” is that it indicates precisely why the construct is far 
superior to eval: it keeps its context with it. When you pass closures around 
in code, they maintain the collection of values from their original scope, and 
when you call a closure, you can’t get at the values in the calling scope. 
Closures are more or less reified eval.

As programmers, it is incredibly important to have the guarantees that closures 
provide because that allows us to abstract upon them. We can go higher-order, 
and in doing so, it is possible to create entire DSLs without even so much as a 
macro system. Doing that with eval is almost impossible because eval is not 
*composable*. The solution is not “an eval that carries around its lexical 
context” because then you have pretty much reinvented closures.

So what was the original title of this thread again? Oh right, “Sending 
Closures to Places”. Obviously in that case, our nice little closure 
abstraction has failed us. Why? Because that context can’t be serialized in the 
general case. Dropping down into eval is throwing *everything* away, which may 
seem simpler, but it also means eschewing any level of abstraction that system 
was already giving you. This is a time when designing a domain-specific 
solution will almost certainly be better than just whipping out eval on a whim 
because our abstraction failed us.

And that, I think, is the problem: eval seems a lot like a “one size fits all” 
approach to problem solving. Need dynamism? Bash it with eval! But we have so 
many tools far better suited to the job without the pitfalls and problems of 
eval (all of which are built on top of it, in a sense). Need dynamic behavior 
at runtime? We have procedures. Need that behavior to be encapsulated into a 
first-class value? We have closures. Need to generate code itself at 
compile-time? We have hygienic macros (and I mention “hygienic” here very 
specifically—I leave figuring out why as an exercise to the reader).

We write in high-level languages for a reason. There’s no reason to stunt their 
ability to abstract by directly calling eval.

Alexis

-- 
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 

Re: [racket-users] Export indentation preferences in a package's info.rkt?

[Alexis King]

IMO, the truly Racket-y way would be to attach a syntax property to the 
exported identifier that has information about how it should be indented. This 
is actually a major improvement over the current way DrRacket handles 
indentation because it would handle forms by their syntactic binding rather 
than by datums. That means that:

  1. Multiple forms could have the same “name” and have different indentation.
  2. Forms imported with rename-in, prefix-in, etc. would be indented properly.
  3. Indentation settings come from the forms themselves rather than some
 unrelated configuration settings.

I think all of those things are big wins over datum-based configuration. 
However, the obvious problem is that it means bindings need to be resolved 
before indentation settings can be retrieved since the binding needs to be 
resolved to access its syntax properties.

In DrRacket, I wonder if this could work similarly to the recent improvement to 
blueboxes: IIUC, they work by binding now, but they perform some 
caching/guessing so that documentation can still be resolved before background 
expansion finishes. Leveraging the same technique would probably work for 
indentation information.

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Getting the "require" syntax arrows to work right

[Alexis King]

Aha, yes, that seems to work. I should have thought of that, but I actually 
didn’t know you can just copy all properties over with datum->syntax, haha. I 
guess I should have read the docs for that more carefully.

This does seem a little bit like cheating because now the macro-generated 
racket/base identifier is considered to be `syntax-original?`, which I guess 
may have been the problem in the first place. Does this mean that 
`syntax-original?` is less meaningful than I initially thought—just because 
it’s a “private” property doesn’t mean macros can’t generate new syntax objects 
that are considered to be “original”?

Anyway, thanks for your quick response! All seems to be well now.

> On Oct 24, 2015, at 12:29 PM, Robby Findler  
> wrote:
> 
> Maybe you need to copy over the properties too? This seems to work:
> 
> #lang racket/base
> (require (for-syntax racket/base))
> (define-syntax (import stx)
>  (syntax-case stx ()
>[(_ (a b))
> #`(require #,(datum->syntax stx
> (string->symbol (format "~a/~a"
> (syntax-e #'a) (syntax-e #'b)))
> #'b
> stx))]))
> 
> (import (racket contract))
> list/c
> 
> Robby

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Getting the "require" syntax arrows to work right

[Alexis King]

I’ve been toying with the idea of making an R7RS implementation in Racket, and 
one of the things I’ve implemented is the R7RS `import` form. It’s very easy to 
implement in Racket, and it works fine as far as I can tell, but I can’t figure 
out how to get the special binding arrows to cooperate with it in DrRacket.

Right now, an import form looks like this:

   (import (racket base))

...and the expansion is this:

   (require racket/base)

I’ve been careful to ensure that the `racket/base` identifier in the expansion 
has the same lexical context and source location as the (racket base) syntax 
object in the original form. I can confirm that this works: after importing 
(racket base), I can use all of the identifiers racket/base provides in my 
module. However, when I hover over them, the binding arrows don’t show up.

What information do I need to include in my custom form so that the arrows 
appear for bindings imported with `import`? How does DrRacket determine where 
bindings are imported at if they’re required from another module?

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Why doesn't syntax/module-reader work with extra-argument read procedures?

[Alexis King]

When discussing custom `read` and `read-syntax` implementations, the Racket 
reference states this in section 1.3.18, Reading via an Extension:

> The arity of the resulting procedure determines whether it accepts extra
> source-location information: a read procedure accepts either one argument
> (an input port) or five, and aread-syntax procedure accepts either two
> arguments (a name value and an input port) or six.

Languages created with syntax/module-reader provide implementations of read and 
read-syntax that accept the extra arguments, as well they should. However, 
custom reader functions passed to the #:read and #:read-syntax options cannot 
accept the extra arguments because syntax/module-reader always only passes 
along one for read or two for read-syntax.

This seems inconvenient to me because I can’t, for example, re-use the R5RS 
reader by supplying read and read-syntax from r5rs/lang/reader to 
syntax/module-reader: there will be an arity mismatch, and reading will fail. 
Is there a reason behind prohibiting languages implemented with 
syntax/module-reader from using these extra arguments? Or could it be enhanced 
to support them?

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] DrRacket indentation adds spaces to empty non-top-level lines?

[Alexis King]

This might be a relevant thread:
https://groups.google.com/d/msg/racket-users/5pxs1pM-8lE/uh0yn9D0QHYJ

(It also might not be. I’m not really sure if it addresses your issue or not.)

> On Oct 21, 2015, at 12:47 PM, Paolo Giarrusso  wrote:
> 
> Hi all!
> 
> Every time I reindent a file with DrRacket in a Git repository, DrRacket and 
> Git fight over whitespace. Git assumes that spaces at the end of lines are 
> whitespace errors, while DrRacket indentation will add spaces to empty lines 
> (including existing ones), if they are inside parens (that is, not at the 
> outermost level).
> 
> What's more, the official coding style says "Don’t pollute your code with 
> spaces at the end of lines", suggesting DrRacket is not behaving well even 
> according to Racket guidelines:
> http://docs.racket-lang.org/style/Textual_Matters.html#%28part._.Spaces%29
> 
>> Don’t pollute your code with spaces at the end of lines.
> 
> I suspect most people don't have these issue because their empty lines are at 
> the outermost level, so they don't need to be indented anyway. But I'm 
> writing module statements, namely (module checker handin-server/checker ...), 
> and switching to `#lang handin-server/checker` fails for me, apparently 
> because that language is defined in a package and not a collection, so I'm 
> stuck.
> 
> ==
> 
> What's more, the style guide continues confusingly:
> 
>> If you find yourself breaking long blocks of code with blank lines to aid 
>> readability, consider refactoring your program to introduce auxiliary 
>> functions so that you can shorten these long blocks of code. If nothing else 
>> helps, consider using (potentially) empty comment lines.
> 
> But I find the discussion confusing: are empty lines at the outermost level 
> fine (as I'd guess), or does the text discourage empty lines everywhere (as 
> the actual text suggests)?
> And what are "(potentially) empty comment lines"? Do you actually mean
> 
> ;
> 
> ? Why's that better?
> 
> Finally, does DrRacket not indent empty lines well because they're 
> discouraged?
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] syntax-original? always returns #f within syntax transformers?

[Alexis King]

I wrote a simple program that determines whether a piece of syntax is original 
in two different ways:

(define-syntax (print-original stx)
  (syntax-case stx ()
[(_ datum)
 (begin
   (displayln (syntax-original? #'datum))
   #'#'datum)]))

(syntax-original? (print-original 'foo))

Running it prints #f, then #t. This seems to imply that #'datum is not 
considered syntax-original? within the syntax transformer, but in the 
expansion, it is. Stepping though the expression within the macro stepper, the 
identifier always seems to be considered original, so I would expect both cases 
to be #t.

Why is the result of syntax-original? different within the two contexts? If 
this is the intended behavior, could it maybe be explained in the documentation?

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] R7RS (small) in Racket

[Alexis King]

I have built a very small, very incomplete implementation of R7RS in Racket. 
You can install the “r7rs” package, or you can find it on GitHub here:
https://github.com/lexi-lambda/racket-r7rs

Most of the standard seems fairly straightforward, but there are two questions 
I have. First of all, do there exist any R7RS libraries or programs out there 
that could be used as test cases? The standard is not always 100% clear, so 
having real code to test against would be ideal. This is probably more 
productive than hopelessly guessing at the meaning behind the fuzzier areas of 
the spec.

Second of all, the only non-trivial problem is how to handle the R7RS library 
system and how to integrate it with Racket’s modules. I’ve been thinking about 
how to handle this, and I’m not sure which path I should take. I think there 
are two different use-cases to having an R7RS implementation inside of Racket, 
and each presents its own needs:

   1. Maintaining full source compatibility with R7RS-compliant programs.
   2. Implementing R7RS as a module language and requiring “#lang r7rs”.

These are not necessarily mutually exclusive. It seems that Racket’s R5RS 
support manages to provide both options by having the “r5rs” lang and module 
language while also including a mode that works by evaluating expressions at 
the top-level. The question becomes: what is the value behind an R7RS 
implementation? I’ve mostly been implementing it as an exercise, and because 
it’s irked me a little that we have R{5,6}RS implementations but not R7RS, but 
it probably isn’t very useful within the Racket ecosystem.

With this context in mind, I ask those have been involved in the Racket R5RS or 
R6RS support to share their experiences regarding these problems. Also, if 
anyone is aware of usages of R7RS (or would be interested in R7RS support in 
Racket, for whatever reason), I’d appreciate thoughts on that as well.

If interest is low, I’ll probably just take option 2 for now and build a 
mostly-compliant implementation that accommodates Racket in a few places, but I 
do have some potential ideas for how to handle source compatibility. Still, I’m 
sure I’d be tackling many of the same problems other people have already 
considered, which is why I ask for information about any prior art.

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: make-readtable with no arguments produces an incompatible readtable?

[Alexis King]

After some investigation, I’ve decided that this behavior is, indeed a bug, and 
I’ve opened a relevant bug report here:
https://github.com/racket/racket/issues/1118

This brings me to a new and different question: how can I work around this? 
Even if the bug is fixed, it will only be fixed on whatever Racket version the 
fix makes it on to, and I’d like to maintain some backwards-compatibility with 
older versions for my library (so far I’ve managed to maintain compatibility 
back to 5.92). I tried adding a dispatch macro to a custom readtable that 
dispatches on #\;, but that doesn’t work because the reader doesn’t get that 
far to actually execute the reader extension.

Is there any feasible way to fix this in a general sense without reimplementing 
the entire list reader? Or will I just have to not support this on current 
versions of Racket?

> On Nov 2, 2015, at 8:36 PM, Alexis King <lexi.lam...@gmail.com> wrote:
> 
> I came across some odd behavior today regarding readtables. Specifically, 
> (make-readtable base) seems to produce a readtable that is operationally 
> different from `base` when reading s-expression comments. Consider the 
> following code:
> 
>   ; this works
>   (read (open-input-string "(1 . 2 #;3)")) ; => '(1 . 2)
> 
>   ; this fails
>   (parameterize ([current-readtable (make-readtable (current-readtable))])
> (read (open-input-string "(1 . 2 #;3)"))) ; => read: illegal use of `.’
> 
> (see http://pasterack.org/pastes/48735 for a working demo)
> 
> Is this a bug, or is it intentional? If it’s the latter, is it documented 
> anywhere?
> 
> Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Changing reader parameters from within a reader extension

[Alexis King]

Hi all,

I’m continuing to implement R7RS in Racket, and I think I’ve gotten most of the 
way aside from the various reader differences. The trickiest thing seems to be 
the #!fold-case and #!no-fold-case directives, which adjust the 
case-sensitivity of the reader as a side-effect. I’ve implemented a readtable 
dispatch macro on the exclamation mark, and I’ve been able to successfully read 
these two directives.

Unfortunately, when I mutate read-case-sensitive by calling 
(read-case-sensitive #f) from within my readtable action, it doesn’t seem to 
persist this change to the next datum. However, the parameter is definitely 
getting set, because I get this error message:

   #!fold-case
   DISPLAY

   => DISPLAY: unbound identifier in module in: |DISPLAY|

The identifier in the error message is being escaped with |vertical bars|, as 
would be the case if case sensitivity were turned off. Unfortunately, it 
doesn’t seem to be affecting the symbols that actually get read.

What’s the “proper” way to adjust this parameter dynamically as I read the 
program?

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] make-readtable with no arguments produces an incompatible readtable?

[Alexis King]

I came across some odd behavior today regarding readtables. Specifically, 
(make-readtable base) seems to produce a readtable that is operationally 
different from `base` when reading s-expression comments. Consider the 
following code:

   ; this works
   (read (open-input-string "(1 . 2 #;3)")) ; => '(1 . 2)
   
   ; this fails
   (parameterize ([current-readtable (make-readtable (current-readtable))])
 (read (open-input-string "(1 . 2 #;3)"))) ; => read: illegal use of `.’

(see http://pasterack.org/pastes/48735 for a working demo)

Is this a bug, or is it intentional? If it’s the latter, is it documented 
anywhere?

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Standardizing the threading macro and organizing packages

[Alexis King]

While in St. Louis, I had a brief conversation with Jay, Alex, and Jack about 
how we all happen to have our own implementation of Clojure’s threading macro. 
That macro is called -> in Clojure, but I believe Greg’s rackjure library set 
the Racket standard of calling it ~>, since the arrow is already used by 
contracts and types (and the FFI, too, for that matter). I have no idea how 
many implementations of this macro exist in the wild, but 5 is already far too 
many.

Duplication is an uncomfortably common problem in Lispy circles, but 
fragmentation is never a good thing, so I’m interested in trying to create a 
standard implementation. It is my understanding that Racket has mostly avoided 
this problem by traditionally absorbing common libraries into the core, but I 
also understand there’s been a push to reverse this trend by spinning these 
things off into packages. I plan to extract my implementation of ~> and all its 
associated friends (I have a lot of them) into their own package, but I’d also 
like to ask some questions first.

First of all, do any people object to this idea in principle? Is this too 
trivial of a thing to try and standardize? Assuming that’s not the case, I’ve 
been wondering what collection to put these in. Currently, Racket packages tend 
to use their own collections, which is even recommended by the documentation. 
However, Jay recently brought to my attention that perhaps this isn’t the best 
way to organize things: it might be better to extend existing collections with 
new modules. For example, he suggested I move my collections library to 
data/collection, which would imply that the lens library should be moved to 
data/lens. I actually like this idea quite a bit, especially for packages that 
are more mature.

This prompts the question asking where a set of utility macros actually belong. 
They don’t belong in data/, certainly, and they don’t belong in syntax/, since 
that collection deals with handling syntax objects themselves. Would it be good 
to create a util/ collection and place this in util/threading? Or would these 
be better in their own, separate collection?

The danger of departing from the one-to-one correlation with package names, of 
course, is the possibility of dramatically increasing the potential for 
conflicts. Personally, I think that grouping collections logically might be a 
good thing, but maybe it isn’t worth the risk? I’m interested in hearing 
people’s thoughts.

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Standardizing the threading macro and organizing packages

[Alexis King]

> If this isn't going to be added to the core (and I don't think it should), 
> then there would need to be some work done on exposure and making sure 
> everyone who wants this functionality knows "look here first and only roll 
> your own if this isn't specific enough”.

This is a good point, and it’s one that I’ve considered. I’m not entirely sure 
what the solution is. The “rings” system in the package manager seems like a 
potential attempt to account for this, but that system is, as of now, unused. 
Clojure has a “Clojure contrib” project, which pulls certain user-created 
packages into the clojure GitHub org, but I’m not sure that’s really much of a 
helpful (or scalable) approach.

> As for the actual package, I'm a strong proponent of a non-macro version 
> that's just the reverse of compose, mostly because it plays very nicely with 
> anonymous macro functions like fancy-app. I'm a bit biased as that's the one 
> I made in my point-free package however. Macro versions are nice too, but I 
> prefer the flexibility of an actual function for most purposes.

I kind of agree with this, even if it isn’t really idiomatic Racket. With good 
lambda shorthand, this is really just as good as any threading macro I’ve seen, 
and it’s more flexible at that. In practice, I haven’t found that added 
flexibility all that important in Racket code, but it is conceptually nicer.

The obvious argument against this is “it’s slow!”, which is true currently. The 
macro version is quite a bit faster than the higher-order function, for obvious 
reasons. That said, I tend to err on the side of conceptual cleanliness over 
speed, and it’s hard to argue using a macro where a function would do.

The real argument is that, well, Racket *doesn’t* have built-in function 
shorthand. Perhaps we should be discussing that package zoo instead? The 
versions I know off the top of my head are:

- fancy-app — Sam’s. Implemented as a module by exporting a customized
  #%app that works at expansion-time.
- rackjure  — Greg’s. Implemented as a full language. Works at read-time
  using readtable dispatch macros with a prefix.
- afl   — Alex’s. Implemented as a meta-language. Works at read-time
  using readtable dispatch macros with a prefix.
- curly-fn  — Mine. Implemented as a meta-language. Works at read-time using
  readtable dispatch macros and curly braces.

(If I’m missing any, please let me know.)

While rackjure is quite cool, it’s much more than just anonymous functions and 
it isn’t composable, so I consider that out. I know fancy-app is somewhat 
appealing because it doesn’t need to be implemented at read-time, but I find 
that it doesn’t have a very strong visual sigil that clues me into the fact 
that something is a lambda expression, not an application. I think the uniform 
syntax works against readability here.

So, in my highly subjective opinion, that leaves afl and curly-fn. I think it 
goes without saying which one I prefer, but I’ll be the first to admit that the 
differences are minor. The only semantic difference is that curly-fn doubles as 
a shorthand for `curry` when no argument placeholders are provided, which I 
think is a nice feature, but it could also be easily added to afl.

I think that summarizes another case in which we have lots of libraries that do 
the same thing in slightly different ways. This example, however, is different: 
it is something that quite likely *should* be in the core. This might be the 
best argument for afl, given that it would be the most seamless to add in a 
backwards-compatible way, but this is probably another thing to hold off until 
racket2, anyway. Until that happens, what are people’s thoughts on this batch 
of conflicting libraries?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Standardizing the threading macro and organizing packages

[Alexis King]

I decided to release my threading implementation as the “threading” package. 
The documentation is here:
http://pkg-build.racket-lang.org/doc/threading/index.html

I’m okay with this because I wanted to pull them out of my utils package, 
anyway, and they’re nice to have, even if we come up with a better solution 
later. I think thrush and thrush+ from point-free might be nice to have in 
racket/function, but point-free is a good package for them, otherwise.

> On Oct 8, 2015, at 5:17 AM, Robby Findler  wrote:
> 

> In addition to agreeing with you and Sam here Alexis, I would like to
> point out another thing that has worked well for Racket in design
> situations such as these: benevolent despotism.

I appreciate the value of this, certainly, but it doesn’t help much if the 
“standard” version is just another implementation that nobody agrees on, since 
that won’t really help the fragmentation much at all.

> On Oct 8, 2015, at 7:56 AM, Greg Hendershott  
> wrote:
> 
> If you do want a Clojure style threading _macro_, rackjure's is the
> best implementation now AFAIK. I say that with no ego because that's
> mostly thanks to help from people like Sam and Christoffer Sawicki.
> Among other things, it's careful to expand using the correct #%app
> (you can use it w/o using #lang rackjure). It could easily be its own
> package, now, if that makes more sense.

I’d be interested to hear what fanciness rackjure’s threading macros provide! 
It would be nice to incorporate those into my package, since I’m sure there are 
a few things I’m missing. Expanding to the right #%app is one of those things, 
to start. My implementation also does some fanciness that Clojure’s does not, 
such as allowing arbitrary position for the arguments, but it would be nice to 
combine the best of them both.

The question about function reader syntax packages is still outstanding. I get 
the sense that those aren’t terribly commonly used... but then I also get the 
sense that packages are very reluctant to depend on anything but the core. Does 
anyone even really use these packages besides their authors?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Alexis King]

> It's not "forking the language", it's turning into an opt-in library. The 
> huge difference between the colon-kw language mixin and that paddle/base 
> language is that the form isn't a language. It can be provided to any 
> language. If your paddle/base language didn't provide colon keywords, you 
> could just as easily get them with #lang colon-kw paddle/base. You're not 
> forking anything, you're simply using a library.

I can’t wait until all of my programs look like this at the top:

#lang at-exp colon-kw curly-fn debug exact-decimal postfix-dot-notation 
sweet-exp racket/base

Okay, so that is perhaps a straw man, but I think the point still stands. I am 
a strong supporter of meta-languages, but I am a stronger supporter of 
standardization. I remain ambivalent about this particular issue—I think there 
are good arguments on both sides—but consider this to be me playing devil’s 
advocate.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Standardizing the threading macro and organizing packages

[Alexis King]

> On Oct 8, 2015, at 1:34 PM, Jay McCarthy  wrote:
> 
> FWIW, I find my threading macro to be very powerful, pretty clear when
> used complicatingly, and at about power-level 9,000:
> 
> https://github.com/jeapostrophe/exp/blob/master/threading-arrow.rkt

I have to agree with Jack and Alex here: I find that a little terrifying, and I 
would not want to need to understand any code that used it.

> My opinion is to include something like this in remix along with some
> nice syntax for cut (what ignorant people call "function literals".)

I admit I can’t really disagree with this point. I’m mostly just interested in 
what syntax you have in mind.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Standardizing the threading macro and organizing packages

[Alexis King]

> My macro and Jack Firth's function both allow that.


Sounds like the solution is to go with a function instead of a macro then. If 
you want that flexibility, I don’t think there’s any reason to stick with a 
macro, anyway. The point-free package is very nice.

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Representing invalid values for non-negative integer variables

[Alexis King]

The Scheme convention for absence of a value, inherited by Racket, is to use #f 
since it is the only falsy value. This make it easy to branch on the presence 
or absence of a value.

Typed Racket reinforces this convention: it has an (Option t) type constructor 
that is an alias for (U t #f), which is a union of `t` and the singleton type 
for the #f value. This cooperates well with Typed Racket’s occurrence typing so 
code that branches on the presence of a value properly typechecks.

> On Oct 11, 2015, at 10:22 PM, Byron Davies  wrote:
> 
> In my state object for 2htdp, I have entries that are normally natural 
> numbers.  When the value of a particular entry is not meaningful during a 
> certain activity, I could just leave the value as whatever it was before, but 
> I would prefer to set it to an invalid value (such as -1 or #f) to indicate 
> that it’s not being used.  Is there any stylistic reason to prefer one over 
> the other, and will the answer be different when I use Typed Racket?
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Long-term Runtime session state

[Alexis King]

Have you taken a look at parameters?

http://docs.racket-lang.org/guide/parameterize.html
http://docs.racket-lang.org/reference/parameters.html

There is also a way to “link units at runtime”, conveniently called “units”.

http://docs.racket-lang.org/guide/units.html?q=unites#%28tech._unit%29
http://docs.racket-lang.org/reference/mzlib_unit.html

Of course, those probably aren’t quite what you’re looking for (they’re mostly 
for linking units of *code* together at runtime). The usual solution to the 
problem you describe is Racket’s parameters.

> On Oct 13, 2015, at 4:36 PM, Nota Poin  wrote:
> 
> How do you deal with long-term state that your programming logic depends on, 
> but is only available at run-time? A persistent connection to a database, or 
> an RPC server for instance, or a logged in user account. Do you use 
> parameters? Session objects? Just raw globals? Or something stranger?
> 
> This might be a crazy idea (probably is) but what I tried doing is 
> initializing state as a local variable, then instead of passing it like an 
> object, passing methods that use it directly as functions. The idea is to 
> have something like a module, but whose code cannot fully compile until the 
> session has been established.
> 
> so like,
> (define (sess cb)
>  (let ((thing (make-session)))
>   (cb
>(lambda (arg)
>  (+ thing 23 arg))
>(lambda ()
>  (do-things-with thing)
> (sess (lambda (foo bar) (foo) (if (bar) ...)))
> 
> Keeping track of the order of these passed functions gets confusing though, 
> when you try to extend one session-aware module-thingy with another. Now you 
> have to write all the functions passed to the “base” wrapper in the extending 
> wrapper, and make sure they’re all in order, and nothing’s missing. Using 
> keywords for everything would fix that, but is there a more elegant way to do 
> it? There's little documentation I can find about linking units at run-time.
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Standardizing the threading macro and organizing packages

[Alexis King]

> On Oct 8, 2015, at 11:08 AM, Alex Knauth  wrote:
> 
> You don't think
> (define-simple-macro (-> var:id expr:expr ...+)
>   (let* ([var expr] ...) var))
> 
> Is better?

No, actually I, I don’t. Threading macros are a convenience, just like 
anonymous functions. I’d rather keep them simple and easy to use than add 
another term that needs to be provided 100% of the time that I’ll only take 
advantage of 5% of the time.

As for compile-time infinite loops: I can’t imagine how that could possibly 
occur, but if you can demonstrate such a problem, that sounds like a bug.

As for simpler to keep in your head: [citation needed]. The original threading 
macro is a simple macro that unwinds nested function application. 
Implementation aside, I find that the most intuitive way to visualize 
it—introducing binding makes that more complicated, not less.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Naming for generalization of find-min and find-max?

[Alexis King]

I’m not completely sold on `most`, but I’m close. I like that it’s terse and 
fairly obvious in what it does. The obvious downside is that it’s a little 
vague. The expression (most < lst) doesn’t read super well, IMO.

I think passing a less-than? argument makes this function much closer 
conceptually to `sort` than anything else, even if it’s really a `fold` in 
reality. In my mind, this function semantically sorts a list and returns the 
first element from the result. I think the name should reflect that.

This is why names like “find-best” and “find-optimal” don’t quite sit with me. 
They might be the best options—I haven’t found anything clearly better yet—but 
these names express an intent that simply isn’t there. It would be like calling 
`append-map` something like `explode` or `permute`: it might describe how the 
behavior is used in 70% of cases, but it does a poor job of explaining what the 
function actually does.

In the same line of thought as `append-map`, the name `first-sort` has crossed 
my mind, but this feels just as opaque. The name `first-by` is very close, but 
it fails: that function has a meaning closer to `findf` to me, not whatever 
this function is. Other names in the same vein are too wordy: 
`first-with-order`, `first-of-sorted`... and none of those convey the meaning 
any better, anyway.

So yes, at this point, the conversation may be little more than bikeshedding. 
It might be best to just pick one of the better solutions and roll with it.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Are there any BDD testing frameworks for Racket?

[Alexis King]

RackUnit is a good tool, but the interface it provides is pretty bare-bones. 
It’s mostly just assertions, with a few grouping utilities like test-case and 
test-suite. The core is solid, but I think it would be nice to have BDD-style 
assertions on top, and I was wondering if such a project already existed in 
some form.

I’d also be rather curious if “spec-style” testing goes against the philosophy 
of Racket in any way. I know some people have strong, negative opinions about 
it, but I don’t think I’ve ever heard the reasons why articulated. If anyone 
expresses similar feelings, I’d be very interested in hearing them (especially 
since I know plenty of people who work on Racket spend a lot of time carefully 
considering language design).

Otherwise, I may consider writing such a library on top of RackUnit, which I’d 
probably call rackunit-spec. Would there be any interest in such a package? I’d 
be curious to know what people’s opinions are on this.

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Are there any BDD testing frameworks for Racket?

[Alexis King]

 Short version: I think it's a good idea. I don't know of anything like
 that, yet. I'm interested in BDD, but not so much a Gherkin style DSL.

Yeah, I currently have no plans to implement something like Gherkin. All I care 
about for the time being is spec-style `describe`, `context`, `it`, and 
similar. I don’t really use Cucumber for much, but it would obviously be 
possible to build a DSL on top of a spec-style framework.

 Out of curiosity, what are you looking to test? If it's an HTTP api, I've got 
 a ton of useful testing tools for that that I was just thinking of making 
 into a package.

It’s nothing HTTP-related, just some plain old Racket code. I’m really just 
interested in having the ability to write spec-style tests in general. That 
said, I’m sure it would be nice to have that sort of thing in a package, 
anyway, so I’d still be interested to see what you have!

Also, since Sam pointed out on IRC that some people might not know what BDD is, 
I’ll include a brief demonstration of what I’d sort of like to build. It’s 
mostly just a different API for writing tests that tries to be a little more 
declarative. For example, testing the `+` function might look like this:

(describe +
  (context when a single argument is provided
(it is the identity
  (expect (+ 1) (to equal? 1))
  (expect (+ -1) (to equal? -1
  (context when multiple arguments are provided
(it adds numbers
  (expect (+ 1 2) (to equal? 3))
  (expect (+ 1 -2) (to equal? -1)

If a test fails, it provides some nicely-formatted information about the test 
and its context. For example, consider adding the following bogus test:

(describe +
  (context when a single argument is provided
(it is the identity
  (expect (+ 1) (to equal? 1))
  (expect (+ -1) (to equal? 1 ; oops, typo
  (context when multiple arguments are provided
(it adds numbers
  (expect (+ 1 2) (to equal 3))
  (expect (+ 1 -2) (to equal -1)))
(it returns a positive number   ; this is just wrong
  (expect (+ 3 -5) (to be positive?)

That might cause the following output:

  +
  ├── when a single argument is provided
  │ ✘ is the identity
  │
  └── when multiple arguments are provided
✔︎ adds numbers
✘ returns a positive number

  Failures:

  1) + is the identity when a single argument is provided 

 Expectation: (expect (+ -1) (to equal? 1))
Expected: 1
 Got: -1

 ; ./sample-spec.rkt:12:6

  2) + returns a positive number when multiple arguments are provided

 Expectation: (expect (+ 3 -5) (to be positive?))
Expected: value that satisfies ‘positive?’
 Got: -2

 ; ./sample-spec.rkt:18:6

  3 examples, 2 failures, 0 pending

The output format and the expectation syntax is entirely theoretical and 
subject to change, but that’s the basic idea. The good news is, I think all the 
basic operations can be defined in terms of existing RackUnit constructs, so 
the only difficulties would be implementing the output format and the 
expectations system. Ideally, though, this would provide some more semantic 
information both in how tests are written and in test failure messages.

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Creating a language that extends typed/racket

[Alexis King]

(Disclaimer: I think this question may have been visited before on this mailing 
list, but I couldn’t find any resolution, so I’m going to ask again.)

I would like to write a language that extends typed/racket or 
typed/racket/base. Specifically, I have a collection, called “envy”. I would 
like to create a `#lang envy` that is just like #lang typed/racket/base, but 
also includes (all-from-out envy). My first instinct was just to create a 
language using syntax/module-reader, along with a simple module language:

   #lang typed/racket/base
   (require envy)
   (provide (all-from-out envy typed/racket/base))

Unfortunately, this doesn’t work. The `envy` module defines a macro called 
`define-environment`, but attempting to use it in this `#lang envy` fails:

   Type Checker: Macro define-environment from typed module used in untyped 
code in: (define-environment)

So that doesn’t work. For some reason, the typechecker thinks `#lang envy` is 
untyped (though it seems to typecheck properly when not using macros). However, 
I realized that `#lang typed/racket` is a module language that obviously 
extends typed/racket/base. It uses typed-racket/minimal, but using that instead 
of typed/racket/base didn’t alleviate my problem.

Is it possible to create a custom language that extends typed/racket/base? How 
does typed/racket itself do it?

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Redirecting Scribble cross-references for non-core packages?

[Alexis King]

I’ve set up a system to automatically build docs for my “envy” package in CI. 
I’m passing the --redirect-main flag to point all the external links to 
http://pkg-build.racket-lang.org/doc/. This works great for all the links that 
point to references in the core distribution, but for some reason, the link to 
the sweet-exp docs isn’t converted: it still generates a link to a local path.

This is the command I’m using to render the docs:
scribble +m --redirect-main http://pkg-build.racket-lang.org/doc/ --html --dest 
./docs ./envy/scribblings/envy.scrbl

The behavior I’m describing is visible here:
https://lexi-lambda.github.io/envy/envy.html#%28part._syntax%29

For some reason, this behavior only seems to happen on CI. When I run that same 
command locally, the link is redirected properly. Are the docs not getting 
properly installed and/or linked into the index when sweet-exp is installed as 
a dependency by raco pkg? Is this a bug, or am I missing something?

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Redirecting Scribble cross-references for non-core packages?

[Alexis King]

Yep, that was it! Thanks a lot for identifying the problem. I’m now explicitly 
installing into installation scope, which solves the problem.

It does seem surprising that --redirect-main doesn’t redirect references to 
documentation in user scope. It would be nice if that were changed so that both 
scopes are included, but if that’s too much work, a note in the docs for the 
`scribble` tool would suffice.

> On Oct 2, 2015, at 4:41 AM, Matthew Flatt  wrote:
> 
> The `--redirect-main` flag redirects links that go to documentation in
> installation scope only.
> 
> Locally, I imagine you're working from a development build out of the
> main repo; in that case, a top-level `make` sets installation scope as
> the default, so "sweep-exp" likely would be in installation scope. When
> building on CI, it looks like you're using a snapshot, which is
> configured (like a release) to have user scope as the default; also, a
> path with
> 
>  .../.racket/snapshot/pkgs/
> 
> looks like a user-scope path.
> 
> I'm not sure that constraining the redirections to installation-scope
> documentation is the right idea --- that flag pre-dates the package
> system --- but hopefully it explains what's happening.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: [racket-dev] Racket Package Server Security Vulnerabilities

[Alexis King]

> * Change your password on the http://pkgs.racket-lang.org site.

For anyone confused about how to do this, I just spent a few minutes trying to 
figure it out, myself. You have to log out, then log back in with your email 
address and intentionally specify an incorrect password. The package server 
will send you an email with a code that you can use to reset your password to 
whatever you’d like.

(It would be nice to have a “change password” button!)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Question about structuring recursive code

[Alexis King]

> Ok. Yeah, if- branches aren't allowed to have definitions, or even sequences 
> of operations. You can get around this with begin

Er, no you can’t... `begin` doesn’t create an internal definition context (or 
even a new scope). You can use an empty `let` instead:

(define (f x)
  (if (even? x)
  (/ x 2)
  (let ()
(define a (* x 2))
(define b (* x 3))
(f (+ a b)

Or you can use `block` from racket/block.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] reducing pauses with incremental GC

[Alexis King]

Wow, this is great. I just tried it with one of my games that I made with 
big-bang, and the pauses I was having are completely gone, as far as I can 
tell. (I was doing quite a bit of copying, so I think the GC was triggering 
fairly often.) Thanks a lot for this; it’s definitely a big improvement.

> On Dec 2, 2015, at 7:44 AM, Matthew Flatt  wrote:
> 
> The development version of Racket now supports an incremental
> garbage-collection mode that can eliminate long pauses in a program.
> For example, incremental mode is useful for avoiding pauses in games
> and animations.
> 
> For more information, see
> 
>  http://goo.gl/rYjTIi
> 
> You can try out incremental mode in a snapshot build:
> 
>  http://pre.racket-lang.org/
> 
> 
> The `2htdp/universe` library has been updated to request incremental
> mode, so a `big-bang` program will automatically use it. The programs
> that I've tried experience GC pauses that are bounded by 10ms or so
> (when run outside of DrRacket). In v6.3, the same programs see a pair
> of 130ms pauses every 2-3 minutes.
> 
> As another example, my son Oliver has a Pict3D-based game that now runs
> without big pauses:
> 
>  https://spaceorbs.weebly.com/
>  https://www.youtube.com/watch?v=mP8ud9Yztz8
> 
> The game uses a fork of Pict3D (github.com/mflatt/pict3d) where I've
> added a `(collect-garbage 'incremental)` call. That changes also makes
> animations in my Pict3D-based talk run without big pauses.
> 
> For Oliver's game, each GC pause is usually below 16ms on his machine,
> but sometimes between 16ms and 32ms. As a result, the game is still
> dropping frames, so it's not yet as good as we want --- but that's much
> better than before, and the game is comfortably playable. Further
> improvement might be just a matter of tuning the implementation of
> incremental mode.
> 
> 
> There's still room for improvement overall, and your mileage may vary.
> If you have an application that needs shorter GC pauses and the current
> implementation of incremental mode doesn't work well enough, I'm
> interested to hear about it.
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] PSA: alexis/collection is dead, long live data/collection

[Alexis King]

The honest answer to your question is that I don’t know (though I’d also be 
interested to hear the answer). Obviously, I’d like to see generic APIs given 
more thought, but they are currently somewhat slow due to how dispatch is 
performed. I don’t think that’s a reason to design APIs in a certain way, but 
it is a practical consideration. I’m guessing that can be optimized, though, 
and I’d be curious to see how generics fare on Pycket.

More generally, I’m not sure multiple dispatch is needed, though it can be a 
neat tool at times. I think part of the problem is that multiple dispatch is 
both hard to reason about and slow to implement in a dynamically-typed 
language. It’s unclear what to use to dispatch on given that values do not have 
“types”. Clojure has multimethods, which could certainly be ported to Racket, 
but it is of note that Clojure protocols are single dispatch and are much 
faster. This is arguably because they leverage features of the JVM rather than 
possessing an inherent speed difference, but that is a much larger discussion.

Generics are already used in a few places, such as Racket dicts, sets, and 
“sequences”, but I certainly think it would be nice if more functions were 
overloadable. At the same time, sometimes that can just be confusing rather 
than helpful. I think that collections are an obvious place where generic APIs 
just make sense, but I’d be open to hearing suggestions for other parts of 
Racket to be “genericized”.

> On Dec 6, 2015, at 10:49, brendan  wrote:
> 
> Great! As an aside, do you know if there are any plans to integrate generics 
> (or, ideally, multiple dispatch) more tightly in later versions of Racket?
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] PSA: alexis/collection is dead, long live data/collection

[Alexis King]

> On Dec 6, 2015, at 10:03 PM, George Neuner  wrote:
> 
> I would disagree that multiple dispatch isn't needed.  The Visitor pattern is 
> used fairly frequently in real programs and it is just a overly complex, 
> error-prone way of doing double dispatch.  Trying to handle more than 2 
> dimensions of dispatch using Visitor involves considerable pain.
> 
> Obviously CLOS combines multiple dispatch with latent typing, so that is one 
> place to look for solutions.  How to do it most efficiently is a fair 
> question.  Various Lisps have used tables and sorting trees for multimethod 
> dispatch.  I think most implementations have settled on using tables now, but 
> my understanding is that this was more to reduce compiler complexity than a 
> determination that tables are more efficient in most cases.
> 
> It is true that dispatch on 3 or more arguments is rarely needed - I read 
> somewhere that in Lisp, dispatch on 2 arguments accounts for 95+% of all 
> multimethod use.  But when it is needed, faking it on top of single dispatch 
> is a royal PITA.

My understanding of the “vistor pattern” is that it’s just a way to emulate 
double dispatch in a single dispatch system, so I’m not sure that’s much of a 
use case. That said, I get the obvious advantages to multiple dispatch for 
modeling certain classes of problems. It would be nice to support multimethods, 
but I don’t think it’s currently clear how to implement multiple dispatch while 
maintaining the guarantees that racket/generic has been carefully designed to 
ensure.

> On Dec 7, 2015, at 9:56 AM, brendan  wrote:
> 
> Does the current implementation use caching? The ideal (I think) would be to 
> do a whole-program transformation that collects all the interface 
> implementations. I'm not sure if Racket even has a mechanism for that, 
> though. Even a per-module system would be handy, though, and that should be 
> doable.

I’m unclear on what you’re specifically referring to here when discussing 
caching, and by extension, I’m not sure what question you’re asking. It sounds 
like an interesting topic, though, so I’d be curious to hear some clarification.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] PSA: alexis/collection is dead, long live data/collection

[Alexis King]

Earlier this year, Jay suggested I move alexis/collection to data/collection 
and claim that namespace. In the past week, I’ve finally done so. Instead of 
using the alexis-collections package, just use the collections package. 
Otherwise, everything still works identically.

The alexis-collections package still exists on the package server for backwards 
compatibility, but I don’t plan on updating it anymore. It is, perhaps, a 
little ungraceful to leave it sitting there, but perhaps it will serve as a 
guidepost to the new version if anyone happens to be looking for it.

To summarize:
- The new package name is just “collections”.
- The new module path is data/collection.
- The new repo is at https://github.com/lexi-lambda/racket-collections.

Thanks to everyone who has used this library and given me feedback.

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] [ANN] trivial 0.1

[Alexis King]

This is pretty neat. Without looking too much into the documentation or 
implementation, could you briefly elaborate on why these changes are in a 
separate package rather than improvements to TR itself?

At a quick glance, you mention doing some sort of static analysis on arguments 
in the normal macro expansion phase: is there any practical reason why TR 
couldn’t export these? Are there any hidden incompatibilities with the core 
Racket forms? Or is this just a philosophical division, deciding that TR 
shouldn’t unnecessarily re-implement forms to perform “magic” typechecking?

Anyway, my curiosity aside, this is a cool idea. I’ll definitely consider 
playing with this a bit if I can get some free time.

Alexis

> On Dec 14, 2015, at 21:40, Benjamin Greenman  
> wrote:
> 
> Have you or someone you know [1] ever thought:
> 
> "Gee, I wish Typed Racket could figure out that ___ has type ___.
> It's pretty obvious to me."
> 
> Then the new "trivial" [2] library is here to help. If you're using basic 
> arithmetic (+, -, *, /), format strings, or regexp-match, just add a colon to 
> the end of your favorite operator.
> 
> When a strong type really is obvious, you win!
> 
> (require trivial/regexp)
> (cond
>  [(regexp-match: #rx"f(o*)" "foobar")
>   =>
>   (lambda ([m : (List String String)]) (cadr m))]
>  [else
>   "no match"])
> 
> Please send bugs & feature requests to the issue tracker [3]. The tracker's 
> also a good place to complain about the choice of the name "trivial" or the 
> colon notation.
> 
> [1] https://groups.google.com/forum/#!topic/racket-users/BfA0jsXrioo
> [2] http://pkg-build.racket-lang.org/doc/trivial/index.html
> [3] https://github.com/bennn/trivial/issues
> 
> 
> ;; --- More Examples
> 
> Before:
> (+ 1 (if (= 0 (- 2 2)) 1 "x"))
> ;; expected: Number, given: (U String One)
> 
> (printf "hello ~a")
> ;; raises runtime error
> 
> (ann (regexp-match "f(o*)" "foobar")
>  (U #f (List String String)))
> ;; Type Error, got type
> ;;   (U #f (Pairof String (Listof (U False String
> 
> 
> After adding (require trivial):
> 
> (+ 1 (if (= 0 (-: 2 2)) 1 "x"))
> ;; Success!
> 
> (printf: "hello ~a")
> ;; Compile-time error
> 
> (ann (regexp-match "f(o*)" "foobar")
>  (U #f (List String String)))
> ;; Success!
> 
> 
> If a strong type isn't clear from the call site, you get standard Typed 
> Racket types.
> 
> (let ([n 2]) (-: n 2))
> ;; Type: Integer
> 
> ((lambda ([f : (-> String Void)]) (f "~b" 'NaN))
>  printf:)
> ;; Runtime error
> 
> (regexp-match: "f(o*)|bar" "foo")
> ;; Type: (U #f (Pairof String (Listof (U #f String
> 
> 
> One more thing: there's a special form for compiling regular expression 
> patterns:
> 
> (define-regexp: my-pat #rx"f(o*)")
> ;; Also supports pregexp, byte-regexp, byte-pregexp
> 
> (ann (regexp-match: my-pat "")
>  (U #f (List String String)))
> ;; Success!
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] about rackjure

[Alexis King]

Oft-forgotten feature about the curly-fn package: if you don’t include any 
arguments, it works as a shorthand for curry. So really, the idiomatic curly-fn 
solution would just be #{map sqr}, the shortest of the four. (Disclaimer: I 
wrote the curly-fn package.)

Tongue-in-cheek comments aside, the point-free package really is great, and any 
one of the crazy function shorthands should work just fine. You can also avoid 
needing special function syntax entirely by just using `curry` from 
racket/function directly, like (curry map sqr). And obviously you could also 
always just use the full lambda syntax, but brevity is nice.

This is an area in which there are probably too many options, but opinions are 
strong, and we have not standardized (yet). Feedback is welcome!

> On Dec 12, 2015, at 4:33 PM, Jack Firth  wrote:
> 
> There's also the fancy-app, curly-fn, and afl packages for different ways of 
> writing anonymous functions (cut and cute from srfi/26 always seemed awkward 
> to me).
> 
> cut:
> (cut map sqr <>)
> 
> fancy-app:
> (map sqr _)
> 
> curly-fn
> #{map sqr %}
> 
> afl:
> #λ(map sqr %)
> 
> point-free doesn't give you special syntax for writing functions, ~> is just 
> a regular procedure. So it works with all of them. (Disclaimer: I wrote the 
> point-free package)
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Ligatures for monospace fonts in editors?

[Alexis King]

This is well-timed, as I was wondering precisely the same thing myself just
yesterday. Atom recently gained support for ligatures, and I was trying out
Hasklig, since I normally use Source Code Pro as my monospace font. I tried it
out in DrRacket as well, and I was disappointed (though not surprised) to find
that the ligatures were ignored.

I don’t know how much effort it would take to add support for this in Racket’s
text rendering engine, but I think it would be a welcome addition, probably
for a lot more than just rendering pretty code ligatures.

Alexis

> On Jan 2, 2016, at 4:13 PM, David Christiansen  
> wrote:
> 
> Hello all,
> 
> I'm using the font Pragmata Pro to display code samples in Slideshow. In
> particular, I've developed a sort of mini-IDE for Idris that can be
> embedded in a slide, using the `interactive' procedure to show it.
> 
> Pragmata Pro has some very nice ligatures for code punctuation. In
> particular, it displays => as a fat arrow, -> as a thin arrow, and /= as
> a slashed-out equals sign. I'd like to display these in my editor, but
> it seems to disable ligatures. I've attempted manually setting the
> family to 'swiss and the face to "PragmataPro", in the hope of avoiding
> the 'modern family (which at least the `text' procedure in pict ignores
> ligatures for), but this hasn't helped.
> 
> I know that Racket can display the ligatures, because evaluating (text
> "->" "PragmataPro") at the REPL displays the ligature.
> 
> Does anyone have a suggestion?
> 
> Thanks!
> 
> /David
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] How can I group optional attributes captured with syntax-parse?

[Alexis King]

I have created a splicing syntax class that captures keyword options that may be
provided in any order. Using the ~optional ellipsis head pattern makes this
easy enough:

(define-splicing-syntax-class opts
  (pattern (~seq (~or (~optional (~seq #:a a))
  (~optional (~seq #:b b))
  (~optional (~seq #:x x))
  (~optional (~seq #:y y)))
 ...))

However, there is a catch: I want to be able to *group* these options into two
sets: the group containing `a` and `b`, and the group containing `x` and `y`.
However, the user may still specify the options in any order, so for this
example input:

(foobar #:b 3 #:y 7 #:a 2)

I want to be able to produce the following attributes:

first-opts:  (#:a 2 #:b 3)
second-opts: (#:y 7)

So far, I’ve managed to do this manually using #:with, but it isn’t pretty:

(define-splicing-syntax-class opts
  #:attributes ([first-opts 1] [second-opts 1])
  (pattern (~seq (~or (~optional (~seq #:a a))
  (~optional (~seq #:b b))
  (~optional (~seq #:x x))
  (~optional (~seq #:y y)))
 ...)
   #`(#,@(if (attribute a) #'(#:a a) #'())
  #,@(if (attribute b) #'(#:b b) #'()))
   #:with (second-opts ...)
   #`(#,@(if (attribute x) #'(#:x x) #'())
  #,@(if (attribute y) #'(#:y y) #'()

This can be simplified a little bit using `template` from
syntax/parse/experimental/template:

(define-splicing-syntax-class opts
  #:attributes ([first-opts 1] [second-opts 1])
  (pattern (~seq (~or (~optional (~seq #:a a))
  (~optional (~seq #:b b))
  (~optional (~seq #:x x))
  (~optional (~seq #:y y)))
 ...)
   #:with (first-opts ...)
   (template ((?? (?@ #:a a))
  (?? (?@ #:b b
   #:with (second-opts ...)
   (template ((?? (?@ #:a x))
  (?? (?@ #:b y))

However, this is really just some sugar for the above, and it doesn’t actually
address the problem of having to enumerate each option in each clause. If I, for
example, added a #:c option, I would need to remember to add it to the
`first-opts` group, otherwise it would be completely ignored.

What I *really* want is some declarative way to group these sets of optional
values. For example, I’d like a syntax like this:

(define-splicing-syntax-class opts
  #:attributes ([first-opts 1] [second-opts 1])
  (pattern (~seq (~or (~group first-opts
  (~optional (~seq #:a a))
  (~optional (~seq #:b b)))
  (~group second-opts
  (~optional (~seq #:x x))
  (~optional (~seq #:y y
 ...)))

Or, even better, it would be nice if I could use existing primitives, something
like this:

(define-splicing-syntax-class opts
  #:attributes ([first-opts 1] [second-opts 1])
  (pattern (~seq (~or (~and first-opts
(~seq (~optional (~seq #:a a))
  (~optional (~seq #:b b
  (~and second-opts
(~seq (~optional (~seq #:x x))
  (~optional (~seq #:y y)
 ...)))

However, neither of those work. Is there any way to do this using the builtins
provided by syntax/parse? If not, is there any simple way to define something
like ~group myself?

Thanks,
Alexis

(also asked as http://stackoverflow.com/q/34551203/465378)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Simple regex question. How to match this: "[X] foo"

[Alexis King]

> You could make a Racket reader that did this.  Or you can find some of the 
> interesting s-expression regular expression languages (I think Olin Shivers 
> did one).  Or just not use regexps so much 
> ("http://regex.info/blog/2006-09-15/247”).

When telling someone to avoid something useful, it is nice to also point to a 
superior replacement. I agree that many uses of regular expressions could be 
better served by something more robust, but what does Racket have to offer in 
this department?

The first thing that comes to my mind is Stephen Chang’s parsack[1], a Racket 
implementation of Haskell’s parsec. There’s also Danny Yoo’s ragg[2] for 
parsing grammars described with extended BNF. I’ve also found a GLL[3] 
“implementation” of sorts, which looks very interesting, but isn’t a package 
and seems to present itself mostly as a tutorial. Finally, there’s the old 
parser-tools[4] package, but that’s pretty heavyweight.

For a system with such a powerful ability to extend the language in arbitrary 
ways, it seems odd that Racket would provide so few tools for parsing simple 
text.

[1]: http://pkg-build.racket-lang.org/doc/parsack/index.html
[2]: http://pkg-build.racket-lang.org/doc/ragg/index.html
[3]: https://github.com/epsil/gll
[4]: http://docs.racket-lang.org/parser-tools/index.html

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] [newbie] Help with streams

[Alexis King]

My “collections” package makes fairly heavy use of streams, so it provides a
number of utilities to help with what you want to do. The obvious function here
would be `generate-sequence`[1], which creates a stream from a generator. You
can call `take` on the resulting sequence, since my generic implementation of
`take` works on any collection type.

There are other ways to accomplish what you’re looking for in data/collection
that don’t use generators. For example, you could use `for/sequence`[2] to
create an infinite stream using for loop syntax. I’ve been planning to add a
`build-sequence` function, too, which would be ideal for this, but I haven’t
done that yet.

Alexis

[1]: 
http://pkg-build.racket-lang.org/doc/collections/collections-api.html#%28def._%28%28lib._data%2Fcollection..rkt%29._generate-sequence%29%29
[2]: 
http://pkg-build.racket-lang.org/doc/collections/collections-api.html#%28form._%28%28lib._data%2Fcollection..rkt%29._for%2Fsequence%29%29

> On Dec 20, 2015, at 18:48, mark  wrote:
> 
> 
> Hi, there.  I have just started playing with Racket and would like some help 
> with using streams/generators (I am not particularly versed in programming in 
> a functional style and am attempting to learn :-))
> 
> So I have a function called (new-name) that creates a random name, like "Bob 
> Brown" or "Jill Xi".  It looks something like
> 
> (define (new-name ethnicity sex)
>  ; return a string like "First LAST" based on ethnicity and sex)
> 
> This is all good and dandy and works well.  What I would like to do now is 
> something like 
> 
>  (define name-gen
>(infinite-generator
>   (yield (new-name ethnicity sex  ; won't work...
> 
>  (get-some-names (name-gen "anglo" "male") 10) ; not sure about this...
> 
> Which would, from a generated list or stream, return ten names.  I can do 
> this using something like
> 
> (for/list ([i 10])
>   (new-name "anglo" "male"))
> 
> but that seems to miss out on the goodness of streams/generators.
> 
> Any help/tips appreciated.
> 
> TIA, .. mark.
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Error reporting with missing head patterns in syntax/parse

[Alexis King]

Consider a macro that works just like `define`, but only allows function
definitions. Here’s a simple implementation using the function-header syntax
class from syntax/parse/lib:

  (define-syntax (defn stx)
(syntax-parse stx
  [(_ header:function-header body ...+)
   #'(define header body ...)]))

This works, but the error reporting isn’t very good when the body is empty:

  (defn (f a b))
  ; defn: bad syntax in: (defn (f a b))

However, if I manually adjust the form to use ... instead of ...+, the error
is much nicer:

  (define-syntax (defn stx)
(syntax-parse stx
  [(_ header:function-header body0 body ...)
   #'(define header body0 body ...)]))
  
  (defn (f a b))
  ; defn: expected more terms starting with any term

This gets much nicer if I include a ~describe form:

  (define-syntax (defn stx)
(syntax-parse stx
  [(_ header:function-header
  (~describe "expression or internal definition" body0) body ...)
   #'(define header body0 body ...)]))
  
  (defn (f a b))
  ; defn: expected more terms starting with expression or internal definition 

Is there any trick to get this kind of error reporting when using ...+? Would
it makes sense to improve the reporting for ...+ to do something like this,
or are there edge cases I have no anticipated that would make this invalid?

Thanks,
Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Help updating racket/function

[Alexis King]

Ah, that’s my package, and that issue is my mistake. I had a version exception 
for 6.2, but I was missing a version exception for 6.2.1. It should work on 
6.2.1 now. Try updating alexis-collections (or uninstalling/reinstalling it), 
and it pull the right version. Thanks for the report!

Alexis

> On Nov 19, 2015, at 10:44 AM, brendan  wrote:
> 
> I installed the package alexis-collections via DrRacket. The build process 
> reported problems with an unbound identifier, and after investigating I found 
> that my installation's racket/function module is missing a couple of things 
> that are in the current version on GitHub. However, DrRacket reports that 
> Racket is up-to-date and so are all of the packages. I still feel pretty lost 
> with respect to the whole Racket ecosystem (packages, collections, catalogs, 
> etc) so I'm not sure what I'm doing wrong. Any help would be greatly 
> appreciated.
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Proper handling for a custom current-read-interaction?

[Alexis King]

I am trying to write a custom current-read-interaction for a language
with non-s-expression syntax, and I’m not sure I completely understand
the protocol for how to detect the end of input across both the command
line and DrRacket. I first wrote an implementation for DrRacket, which
appears to continually call current-read-interaction until it returns
#, at which point it presents the user a new prompt. Therefore, I
simply decided to check char-available? on the provided port and return
# whenever the port returned #f. This seems to work fine in
DrRacket.

On the other hand, I found it does not work at all on the command line.
Returning # on the command line just seems to kill the entire REPL.
Furthermore, unlike DrRacket, the CLI does not seem to produce an EOF at
the end of each expression, just a newline, re-using the same port each
time. Checking for a newline in DrRacket would not work at all, though,
because DrRacket permits entering multiline expressions in its REPL.

This would lead me to believe that there are two completely different
protocols for how the two different REPLs work:

  1. In DrRacket, read all the contents in the port provided to
 current-read-interaction. Check the port against char-available?
 each call, and return # when it returns #f.

  2. At the command line, read all contents up until a newline. Check
 the port against peek-char each call, and return # when it
 returns # to support exiting the REPL by sending ^D.

These seem totally different, frustratingly so, since it seems like it
would not be too hard for the CLI to use the same behavior as DrRacket.
My guess is that I’m overcomplicating things at least a little, but I
wasn’t able to locate anything about what exactly is expected of the
function provided to current-read-interaction. Is there a way to
implement it that can gracefully handle both scenarios? If not, what is
the proper way to check if code is running in the CLI REPL or the
DrRacket REPL and adjust behavior accordingly?

Alexis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Proper handling for a custom current-read-interaction?

[Alexis King]

Ah, ok, that (mostly) makes sense to me. I think this might be a
little bit complicated, though: in this language, definitions can
span multiple lines without necessarily any direct indication that
they continue. Think Haskell-style pattern matching:

  fib 0 = 0
  fib 1 = 1
  fib n = fib (n - 1) + fib (n - 2)

In this case, I actually need to read the whole input to know what
a single form should be in the output. Therefore, I’d much rather
be handed a user’s entire input, lex the whole thing, parse it, and
produce top-level expressions Racket can understand. I’m not sure
how to elegantly implement that given the current behavior, since
I definitely want to consume multiple lines at a time when possible
(i.e. in DrRacket) but if I try and read until an EOF I will block
in the REPL.

Is there some way around this? It seems like it would be nice for
a REPL to communicate if it is operating in multiline mode, in which
case input is separated by EOFs, or single line mode, in which case
input is separated by newlines. Of course, at that point, it seems
like it would likely make sense to simply always send EOFs to avoid
the need to check.

> On Jun 7, 2016, at 4:56 AM, Robby Findler  wrote:
> 
> The intention here is that you should have a notion of an expression
> that is itself consistent and you should read until you get a whole
> one of those and then just return that. The different behavior you see
> in DrRacket and at the terminal window prompt will, yes, cause
> different behavior, but it isn't supposed to be something that you
> would explicitly check for and respond to.
> 
> In the case of the DrRacket window, DrRacket makes the assumption that
> your expressions will be terminated by an EOF and puts those into the
> port between each submission that the user makes in order to support
> things like typing alt-return (something that doesn't happen at the
> terminal window).
> 
> Robby

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] R7RS implementation

[Alexis King]

Hey, I’m the maintainer of the R7RS library. I’d appreciate it if
you filed those issues as bugs on the GitHub repository here:

  https://github.com/lexi-lambda/racket-r7rs

I’m glad you found value in the library, and I’d love to try and
fix some of the problems you mentioned, especially since a number
of them are probably low-hanging fruit.

Alexis

> On Jun 9, 2016, at 3:09 AM, Jean-Michel HUFFLEN  wrote:
> 
>   Dear Racket developers and users,
> 
>   I've just tried the non-official implementation of R7RS in Racket. Three 
> points:
> 
>   - if you define a library, you can write something like:
> 
> (define-library (something)
>  (export ...) (import ...)
>  (define another-thing ...)
>  (define year-another ...)
>  ...)
> 
> although R7RS makes precise that definitions must be grouped under "begin":
> 
> (define-library (something)
>  (export ...) (import ...)
>  (begin
>(define another-thing ...)
>(define year-another ...)
>...))
> 
>   - the second point is already present for "#lang racket". I personally 
> think that it is a pity that the output form of a bytevector is not itself, 
> from my point of view, that complicates debugging. But in R7RS, bytevectors 
> are self-evaluating:
> 
> #u8(48) ==> #u8(48)
> 
> whereas Racket implementation tries to display corresponding characters as 
> far as possible:
> 
> #u8(48) ==> #"0"
> 
> but we already have the function "utf8->string" for such use.
> 
>   - The function "features" results in:
> 
> (r7rs racket exact-closed exact-complex ieee-float full-unicode ratios)
> 
> these informations are ok, but should be include items about operating system 
> and encoding for 16-bit words (little/big-endian). Such information could be 
> successfully used by the "cond-expand" form.
> 
>   Anyway, thanks for this new implementation; I tried it with great pleasure.
> 
> J.-M. Hufflen
> 
> 
> 
> This message was sent using IMP, the Internet Messaging Program.
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Custom color lexer for DrRacket that requires lookahead

[Alexis King]

> On May 30, 2016, at 12:23, Alexis King <lexi.lam...@gmail.com> wrote:
> 
> Now the colorer attempts to lex the slash alone as a new token without
> attempting to re-lex “foo”. Since a forward slash is not valid at the
> beginning of an identifier, it is colored as an error.
> 
> Basically, when I type a forward slash, I want the preceding token to be
> re-lexed. I don’t need anything more than that... just a single
> character of lookahead is necessary, effectively.

Actually, I realized just after sending this that my description is not
the full picture. I think the confusion probably stems from that the
colorer does, in fact attempt to re-lex “foo” once the forward slash is
typed. However, since a trailing slash is illegal at the end of an
identifier as well, it’s still lexed as an error. Now, I keep typing:

  foo/bar
 ^

This presumably causes the slash to be re-lexed, but since it’s still
illegal at the beginning of a token, the lexer still fails. My guess
here was that I needed to include a backup-distance on the error token,
but that doesn’t seem to help, so I’m unsure how to properly indicate
the need to re-lex the entire “foo/bar” token once “bar” is added.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Custom color lexer for DrRacket that requires lookahead

[Alexis King]

I’ve created a custom language with non-s-expression syntax, so I’ve
written a lexer and connected it to the DrRacket syntax highlighter.
This works pretty well, but I have a small problem: when modifying text
that would cause earlier tokens in the stream to lex differently, I am
unsure how to properly communicate that need to the highlighter.

Specifically, this language allows forward slashes within identifiers,
like foo/bar/baz, but they cannot be leading or trailing slashes.
Therefore, something like “/foo” on its own is a lexer error, so the “/”
gets highlighted in red.

Normally that’s ok, but when a user types a valid identifier, like
“foo/bar”, the highlighter treats “/bar” separately and attempts to lex
it in isolation, which produces an error. What I actually want is for
typing the forward slash in “foo/bar” to re-lex the entire symbol,
producing the correct token.

As far as I can tell, there are two mechanisms for this sort of
re-lexing, both using the 3-argument get-token function with
color:text<%>:

  - Providing a backup distance, which causes re-lexing when a token
is internally modified.

  - Returning a dont-stop struct as the mode, which prevents the
highlighter from being interrupted as long as get-token continues
to return dont-stop.

I don’t think the backup distance applies here because the token is not
being internally modified, it is being appended to. I thought that
returning dont-stop when lexing identifiers would solve my problem, but
it didn’t seem to affect anything, so I am likely misunderstanding how
it works.

What is the solution to this sort of problem? What mechanism do I need
to use to properly communicate the need to re-lex from the beginning of
each identifier when appending text to the end?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Store value with unsupported type in Postgres?

[Alexis King]

The DB docs for SQL type conversions[1] note that not all Postgres types
are supported by Racket, and it recommends using a cast to work around
this. It even uses the inet type as an example right at the start of the
page. However, I want to store an inet value in my database, not query
an inet value out, and I can’t figure out what set of casts I need for
the right coercion to take place.

My query looks like this:

  (query-exec conn "INSERT INTO some_table (ip) VALUES ($1)" client-ip)

Attempting to execute that query gives me the following error:

  query-exec: unsupported type
type: inet
typeid: 869

Is there any way to annotate this so that I can insert into that table?

[1]: http://docs.racket-lang.org/db/sql-types.html

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Store value with unsupported type in Postgres?

[Alexis King]

Perfect, that works great, thank you! It looks like the precedence works
out such that I could do $1::text::inet and have it work properly, which
is clean enough for my needs.

> On Jan 17, 2016, at 16:39, Marc Burns  wrote:
> 
> You can cast first to a supported type:
> 
> (query-exec conn "INSERT INTO some_table (ip) VALUES (inet ($1 ::text))" 
> client-ip)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Store value with unsupported type in Postgres?

[Alexis King]

I would like to avoid interpolating into a query if at all possible,
given that this string is not something I control. I could be very
careful about validating or sanitizing it, but this is a pretty textbook
use case for parameterized queries.

> On Jan 17, 2016, at 16:19, Jon Zeppieri  wrote:
> 
> How about: (query-exec conn (format "INSERT INTO some_table (ip) VALUES (inet 
> '~a')" client-ip))

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Expression-style printing and quotation: helpful or harmful?

[Alexis King]

It is my understanding that “expression-style” printing was introduced
to Racket v5.0, which alters how values are printed in the REPL to
permit many printed expressions to be evaluated to produce the same
value. In contrast to the traditional Scheme write procedure, this tends
to manifest itself as additional quotes. That is, (list 1 2) will print
as '(1 2) instead of (1 2). As I understand it, the struct form was also
introduced to use the name of the struct as the constructor to make
struct printing align more with the expressions that produce them.

But everyone already knows all that. I only bring it up because I
monitor the [racket] tag on Stack Overflow[1] relatively closely, and a
whole lot of questions come up due to how people misunderstand the quote
form. I recently wrote up a relatively long answer[2] about how quote
works in the hope to create a canonical duplicate to point people to,
but someone mentioned in the comments that they found the Racket
behavior confusing, and while I was writing the answer, I found myself
questioning it a little bit, too.

There seems to be an overwhelming amount of confusion about how quote
works, especially since plenty of people seem to initially see it as
nothing more than a shorthand for the list function when really its
semantics are more (or less, depending on your perspective) complicated.
This seems to be compounded by Racket’s printing style, which puts
quotes in places where quotes traditionally would not be, and new users
unfamiliar with quotation are likely develop a misunderstanding about
how it works and what it means, since they will see quotes in the
printed representation for simple lists, even ones created with list.

I do not know how many Racket learners actually encounter this problem,
nor do I know how they actually respond. I do not know that many.
However, given how much Racket is used in education, I would imagine
that HtDP can provide some insight into how quotation should be treated
and how students react to it. HtDP itself seems to treat quote with
great care, taking pains to avoid printing it out at all until it is
introduced, but this is obviously not suitable for a full programming
environment, given that the verbose notation would be incredibly
annoying in serious programming.

I am not advocating for a change of printing style, but I would be
interested to hear others’ opinions. I like to think that Racket is
relatively accessible, but this seems to be a frequent point of
confusion (I even recently saw a newcomer to the language describe
Racket as seeming “incredibly complicated”), and I wonder if the
printing style is a sticking point or if it’s just a symptom of a more
general confusion.

Alexis

P.S. One of my absolute favorite Racket-related papers is “Mind Your
Language”[3], which describes with considerable detail how students
interact with error messages. That care and attention to the
programmer—even if not technically complex!—has recently done Elm very
well. I am personally very interested in exploring more of that.

[1]: http://stackoverflow.com/questions/tagged/racket
[2]: http://stackoverflow.com/q/34984552/465378
[3]: 
https://cs.brown.edu/~sk/Publications/Papers/Published/mfk-mind-lang-novice-inter-error-msg/paper.pdf

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Expression-style printing and quotation: helpful or harmful?

[Alexis King]

I appreciate your input, Matthew, but the location of the documentation
is a separate conversation—the point seems to be that the current
documentation is insufficient. Throwing a whole book at someone who is
confused about apostrophes in their programs’ output is not an ideal
answer, in my opinion. Remember: users don’t read.

> On Feb 7, 2016, at 15:35, Matthew Butterick  wrote:
> 
> BTW, as further evidence of Racket's comparative longevity and tenacity: the 
> current pairs & lists explainer has been part of the online docs since v4.0, 
> which was released — fact-checkers, you can correct me — before Stack 
> Overflow even existed. So really, one canonical RTFM on the first day 
> should've sufficed for all time. But the reputation-points economy wants what 
> it wants.
> 
> Then:
> http://download.plt-scheme.org/doc/4.0/html/guide/Pairs__Lists__and_Scheme_Syntax.html
> 
> Now:
> http://docs.racket-lang.org/guide/Pairs__Lists__and_Racket_Syntax.html

-- 
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.
For more options, visit https://groups.google.com/d/optout.