[racket-users] [ANN] megaparsack 1.4 — support for user-defined parser state

[Alexis King]

Hi all,

As some of you may know, I am the maintainer of the Megaparsack
 package, a
Parsec-style parser combinator library. Though it’s mostly been in
maintenance mode for some time, the latest release adds a significant new
feature: *user-defined parser state*. This closes the main expressivity gap
Megaparsack has historically had relative to Parsack (though Parsack
continues to be more performant).

As a quick overview to pique your interest, Megaparsack 1.4 provides a new
abstraction called a *parser parameter*. Parser parameters are similar to
ordinary Racket parameters, but their state is associated with a parsing
context rather than with a thread. Their interface should already look
familiar to Racketeers, so here is an example that uses parser parameters
to implement an indentation-sensitive syntax:

(define current-indent (make-parser-parameter 0))

(define skip-current-indent/p
  (do [cols <- (current-indent)]
  (repeat/p cols (char/p #\space

(define markdown-like-list/p
  (do (string/p "* ")
  [blk <- block/p]
  [cols <- (current-indent)]
  [blks <- (parameterize/p ([current-indent (+ cols 2)])
 (many/p block/p))]
  (pure (cons blk blks

Modifications to parser parameters are automatically reverted when the
parser backtracks past the point of modification, which allows them to be
used for accumulating information during parsing even if the current parse
branch is tentative. To illustrate, note that this example results in 10
rather than 15:

(define current-count (make-parser-parameter 0))

(define (increment/p n)
  (do [count <- (current-count)]
  (current-count (+ count n

> (parse-string
   (do (or/p (try/p (do (string/p "!") (increment/p 5) eof/p))
 (do (string/p "!!") (increment/p 10) eof/p))
   (current-count))
   "!!")
(success 10)

I generally don’t post about releases to this list, but I happen to know
Megaparsack has at least a few active users, and this is the first major
update in a long while, so I figured I’d give a heads-up. If you’ve counted
the library out in the past for missing this feature, consider giving it
another look. And if you’re interested in learning more, the gory details
are described in the documentation, along with some additional examples (at
the time of this writing, pkg-build hasn’t rebuilt the docs just yet, but
that should be resolved with tomorrow’s daily refresh).

Happy parsing,
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAA8dsaf1%2B%2BSwHiuEr0zd4iFutb5tK2UAgMmXShk%2B20p4W3kaag%40mail.gmail.com.

[racket-users] Re: [ANN] megaparsack 1.4 — support for user-defined parser state

[Alexis King]

Addendum: the docs are now built, so you can read more at these two links:

   - https://docs.racket-lang.org/megaparsack/state.html
   -
   
https://docs.racket-lang.org/megaparsack/reference.html#%28part._parser-parameters%29


On Sun, Jul 4, 2021 at 2:21 AM Alexis King  wrote:

> Hi all,
>
> As some of you may know, I am the maintainer of the Megaparsack
> <https://docs.racket-lang.org/megaparsack/index.html> package, a
> Parsec-style parser combinator library. Though it’s mostly been in
> maintenance mode for some time, the latest release adds a significant new
> feature: *user-defined parser state*. This closes the main expressivity
> gap Megaparsack has historically had relative to Parsack (though Parsack
> continues to be more performant).
>
> As a quick overview to pique your interest, Megaparsack 1.4 provides a new
> abstraction called a *parser parameter*. Parser parameters are similar to
> ordinary Racket parameters, but their state is associated with a parsing
> context rather than with a thread. Their interface should already look
> familiar to Racketeers, so here is an example that uses parser parameters
> to implement an indentation-sensitive syntax:
>
> (define current-indent (make-parser-parameter 0))
>
> (define skip-current-indent/p
>   (do [cols <- (current-indent)]
>   (repeat/p cols (char/p #\space
>
> (define markdown-like-list/p
>   (do (string/p "* ")
>   [blk <- block/p]
>   [cols <- (current-indent)]
>   [blks <- (parameterize/p ([current-indent (+ cols 2)])
>  (many/p block/p))]
>   (pure (cons blk blks
>
> Modifications to parser parameters are automatically reverted when the
> parser backtracks past the point of modification, which allows them to be
> used for accumulating information during parsing even if the current parse
> branch is tentative. To illustrate, note that this example results in 10
> rather than 15:
>
> (define current-count (make-parser-parameter 0))
>
> (define (increment/p n)
>   (do [count <- (current-count)]
>   (current-count (+ count n
>
> > (parse-string
>(do (or/p (try/p (do (string/p "!") (increment/p 5) eof/p))
>  (do (string/p "!!") (increment/p 10) eof/p))
>(current-count))
>"!!")
> (success 10)
>
> I generally don’t post about releases to this list, but I happen to know
> Megaparsack has at least a few active users, and this is the first major
> update in a long while, so I figured I’d give a heads-up. If you’ve counted
> the library out in the past for missing this feature, consider giving it
> another look. And if you’re interested in learning more, the gory details
> are described in the documentation, along with some additional examples (at
> the time of this writing, pkg-build hasn’t rebuilt the docs just yet, but
> that should be resolved with tomorrow’s daily refresh).
>
> Happy parsing,
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAA8dsafQt%2BCtXPVFKuTYC1ZShC3%3DZgzNBEzfe7_bH67sYCJMCg%40mail.gmail.com.

[racket-users] Can I get the behavior of `overment` followed by `augride` with a single class?

[Alexis King]

Hello,

While doing some OOP in Racket today, I found myself in a situation that
would benefit from two seemingly contradictory things:

   1.

   I want to be able to override a superclass method, and I want to be
   certain that I get to handle the method before any of my subclasses do.
   This suggests I want to use inner.
   2.

   At the same time, I want my subclasses to be able to override this
   method, not augment it. If I call inner and my subclass calls super,
   control should jump to *my superclass*.

In other words, I want to get a sort of “first try” at handling the method
so that if I choose to, I can neglect to call my subclass’s implementation
altogether. But if I decide *not* to handle it, then I want super-style
dispatch to proceed as if my class were never there at all.

At first, I thought this wasn’t possible using Racket’s class system, since
if I override my superclass’s method using overment, the subclass
necessarily cannot use super, violating requirement 2. Yet if I use override,
I don’t get the “first try” I want, violating requirement 1. However, after
some thought, I realized it’s possible if I’m willing to use *two* classes
rather than one:

(define my-superclass%
  (class object%
(define/public (m x) `(foo ,x))
(super-new)))

(define my-class%
  (let ()
(define-local-member-name super-m)
(class (class my-superclass%
 (define/public (super-m x)
   (super m x))
 (define/overment (m x)
   (if (not x)
   'skip
   (inner (error "impossible") m x)))
 (super-new))
  (inherit super-m)
  (define/augride (m x)
(super-m x))
  (super-new

The trick here is twofold:

   1.

   First, I override m using overment, which ensures method dispatch will
   call my implementation first.
   2.

   Next, I augment my own implementation of m using augride, which makes
   the method overridable again in subclasses. To satisfy the other half of
   requirement 2, my augmentation calls my-superclass%’s implementation of m
   via a sort of secret “side channel,” kept private using
   define-local-member-name.

Using this trick, subclasses of my-class% can still override m, and as long
as x is non-#f, my sneaky interposition doesn’t seem to have any effect.
But if x *is* #f, I can short-circuit the computation immediately:

(define my-subclass%
  (class my-class%
(define/override (m x)
  `(baz ,(super m x)))
(super-new)))

(define obj (new my-subclass%))
(send obj m #t) ; => '(baz (foo #t))
(send obj m #f) ; => 'skip

I think this is kind of cute, since it makes it possible to effectively
conditionally interpose on method dispatch. However, it’s rather awkward to
write. This brings me to my question: is there any simpler way to do this?
And are there any hidden gotchas to my technique?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAA8dsae1HR2CVUNq3aC4nc2vpPU6L9f-ENor-074LyZnWXgKYg%40mail.gmail.com.

Re: [racket-users] Can I get the behavior of `overment` followed by `augride` with a single class?

[Alexis King]

On Mon, Jul 19, 2021 at 11:08 AM Matthew Flatt  wrote:

> Are there other useful variants that are not currently supported (at least
> directly)?
>

I think the answer to this is “no.” My reasoning follows.

>From the perspective of subclasses, superclass methods come in three sorts:
overridable, augmentable, and final. The existing method declaration
keywords support all possible transitions between these sorts, which
suggests the current set is complete. However, my original email shows that
compositions of these transitions can affect *dispatch* in different ways
from the existing keywords, even if they result in methods belonging to the
same sort.

This fundamentally hinges on the fact that overment has an unusually
significant impact on dispatch behavior. overment switches from
subclass-first dispatch to superclass-first dispatch, which means overment
followed by augride effectively breaks a chain of Java-style methods into
two sub-chains. In contrast, the other keywords provide no such utility:

   -

   override and augment on their own do not change dispatch characteristics
   at all from the perspective of other classes.
   -

   augride followed by overment creates a local chain of Java-style methods
   before switching back to Beta-style inheritance. Since this chain is wholly
   self-contained, it does not change the overall dispatch structure in any
   way, and it could be replaced by completely static dispatch with no loss of
   expressiveness.

The main interesting thing about overment followed by augride is that it
allows something reminiscent of the CLOS :around method combination, since
it allows a class to receive control on both the way down *and* the way up
through method dispatch. Since override already provides the “on the way
up” part, a hypothetical interface for this would make most sense as
something that could be present on its own *or in addition to* an ordinary
override declaration, like

(define/override (m x)
  (super m x))
(define/around (m x)
  (inner/around m x))

where inner/around is like inner, but it doesn’t take a default-expr, since
it always has a Java-style method to dispatch to. I don’t know if these
names are the best—around doesn’t really seem right to me—but I don’t know
what else to call 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAA8dsadsniyVBv%3De2NGFEUgk3EGzNmzvBcsECw8xFgAizOSUiA%40mail.gmail.com.

[racket-users] The history of hygiene for definition contexts

[Alexis King]

Hi all,

I recently posted two tricky hygiene puzzles on Twitter
, reproduced
below for completeness:

(let ([x 'outer])
  (define-syntax-rule (m a)
(let ([a 'inner]) x))
  (m x))

(let ([x 'outer])
  (define-syntax-rule (m a)
(begin
  (define a 'inner)
  x))
  (m x))

The puzzle is to guess what these expressions evaluate to. I have
discovered that people find the “correct” answer *remarkably*
unintuitive—at the time of this writing, it is the single least popular
choice in the poll!

Despite this confusion, the Scheme implementations I’ve tried are
unwaveringly consistent in their interpretation of these expressions:
Racket, Chez, and Guile all agree on what the answers should be. This has
led me to wonder where the original justification for these answers comes
from, but I have been struggling to hunt down a source.

Matthew’s 2016 paper, “Bindings as Sets of Scopes”, discusses examples like
these ones in gory detail, but it gives no justification for *why* these
results are the right ones, it simply takes their meaning for granted.
Earlier papers on macro technology I have found do not discuss internal
definitions, and no Scheme standard specifies the macro system, not even R6RS.
Obviously, something at some point must have set the precedent for the
handling of such macros, but I cannot figure out what it is.

So, my question: when was hygiene for internal definitions first worked
out, and did it make it into any papers, specifications, or documentation?
Hopefully someone (probably Matthew) can provide some insight.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAA8dsac6XUYpcMzf5dG5oSWKw30jZGOgqCPFMiEOTcq1KAh1Bw%40mail.gmail.com.

Re: [racket-users] Re: The history of hygiene for definition contexts

[Alexis King]

On Thu, Jul 29, 2021 at 12:53 PM Michael Ballantyne <
michael.ballant...@gmail.com> wrote:

> The second example you give becomes more natural if you've considered
> simpler cases of macros in definition contexts first
>

I agree that breaking the macro into two parts—one of which inserts a
binder and one of which inserts a reference—is the most compelling way to
intuitively explain the behavior of the second expression. (And Shu-Hung
previously posted the same observation
 on Twitter.)
Still, it is interesting how many people find the result deeply
unintuitive.

To understand why, it seems helpful to start from Clinger and Rees’ *strong
hygiene condition*, which provides a high-level definition of what hygiene
is supposed to mean:


>1.
>
>It is impossible to write a high-level macro that inserts a binding
>that can capture references other than those inserted by the macro.
>2.
>
>It is impossible to write a high-level macro that inserts a reference
>that can be captured by bindings other than those inserted by the macro.
>
> The precise meaning of these criteria is not completely obvious, because
the intended interpretation of the phrase “inserted by the macro” is not
perfectly clear. However, the intended interpretation seems to be that a
“macro-inserted” reference or binding is one for which the reference or
binding identifier itself does not come from the macro’s inputs.

This naturally justifies the interpretation of the first expression, since
by the above definition, the reference to x is macro-inserted, but the
binder for x is not. This lines up with the results of the survey:
programmers generally agree that the result of the first example ought to
be 'outer.

The second example is trickier, as at first blush it clearly violates the
second criterion of the hygiene condition: the macro-inserted reference to x
is captured by the non-macro-inserted binder. However, I don’t think the
applying the condition is quite so straightforward when recursive
definition contexts are involved.

My reasoning starts with contemplating the meaning of a macro like

(define-syntax-rule (define-false x)
  (define x #f))

in isolation. What makes macros like this unusual is that they introduce
what one might call *free binders* by analogy to the notion of a free
reference. The first criterion of the strong hygiene condition clearly
always applies to macro-inserted *bound binders*, but it doesn’t always
seem apply to free ones. Why?

Intuitively, this is because the scope of a bound binder fundamentally
never contains the macro definition, which is the lexical location of any
macro-inserted reference. This invariant is broken by definition contexts,
where a free binder can eventually become bound in a scope that *does*
contain the macro definition. It is precisely this ability for a macro’s
use site to “retroactively” affect its definition’s scope that allows the
macro-inserted reference to be captured.

In other words, I don’t think this is actually a violation of the hygiene
condition because the macro-inserted reference is not actually “captured.”
Rather, the nature of recursive definition contexts necessarily allows
future definitions to affect earlier ones, and in this case, the future
definition of x is in scope at the macro’s *definition site*, which means
it must be in scope in the context of the macro-inserted x.

I think what’s so intuitively surprising about this essentially stems from
two things:

   1.

   After expansion, the macro-inserted reference to x appears *after* the
   internal definition, which means the binding structure of the expanded
   expression does not need to be recursive. A completely sequential structure
   would suffice, a la let*.
   2.

   If definition contexts were in fact sequential, not recursive, the
   result of the second expression would in fact be 'outer. This is because
   the internal definition of x would not be in scope at the macro’s
   definition, so the macro-inserted x should not be able to see it.

It is this bait-and-switch that seems to trip people up. The fact that the
macro-inserted reference appears after the internal definition in the
expansion makes it seem as though the macro-inserted reference is being
captured, but in fact it is not the structure of the expansion that
matters, but rather the structure of the original program. Indeed, there is
nothing special, magical, or broken about define itself, which introducing
a scope between macro definition and macro use site cleanly illustrates:

> (let ([x 'outer])
(define-syntax-rule (m a)
  (begin
(define a 'inner)
x))
(let ()
  (m x)))
'outer

Anyway, this email has ended up rather long, so perhaps it would be better
moved to a small blog post. But an explicit statement of the above
reasoning is precisely the sort of thing I have been looking for but have
n

[racket-users] Combining contract checking with normalization?

[Alexis King]

Hello,

As a user of the Racket contract system, I sometimes find myself thinking
about the potential utility of “coercing” or “canonicalizing” contracts. In
Racket programs, we often idiomatically allow values to be provided to a
function in a non-canonical form for the sake of convenience. One example
is the commonly-used path-string? contract, which is morally equivalent to
using path? but allows the caller to omit an explicit use of string->path.
Another example is the commonly-used failure-result/c contract, which
allows the caller to omit wrapping non-procedures in a thunk.

While this idiom does make life easier for one party to the contract, it
ultimately just transfers the burden of canonicalizing the value to the
other party. This is unfortunate, because it results in a duplication of
both logic and work:

   -

   Code to canonicalize the value must be written separately and kept in
   sync with the contract, which is error-prone.
   -

   The value ends up being inspected twice: once to determine if it
   satisfies the contract, and a second time to convert it to canonical form.

(In the nomenclature of a popular blog post I wrote a few years ago, these
contracts are validating, not parsing
.)

In theory, it is perfectly possible to implement a canonicalizing contract
using the current contract system. However, such a contract has several
practical downsides:

   -

   It is necessarily an impersonator contract, not a chaperone contract.
   This prevents its use in places that demand a chaperone contract, such as
   the *key* argument to hash/c.
   -

   It moves actual logic into the contract itself, which means using the
   uncontracted value directly is less convenient. This encourages placing the
   contract boundary close to the value’s definition to create a very small
   contracted region (e.g. via define/contract), even though blame is
   generally more useful when the contract boundary corresponds to a boundary
   between higher-level components (e.g. via contract-out).
   -

   There is no way to write such contracts using the combinators provided
   by racket/contract, so they must be implemented via the lower level
   make-contract/build-contract-property API. This can be subtle to use
   correctly, and it makes it unlikely that contract violations made by the
   contract itself will be blamed properly according to the “indy” blame
   semantics used by ->i.

All this is to say that the current contract system clearly discourages
this use of contracts, which suggests this would be considered an abuse of
the contract system. Nevertheless, the coupling between validating values
and converting them to a normal form is so enormously tight that allowing
them to be specified together remains incredibly compelling. I therefore
have two questions:

   1.

   Has this notion of “canonicalizing” contracts been discussed before,
   whether in informal discussions or in literature?
   2.

   Is there any existing work that explores what adding such contracts to a
   Racket-style, higher-order contract system in a principled fashion might
   look like?

Thanks in advance,
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAA8dsad%2BZHLQTBK-oa5UZJfV7t33Fk0Q0L5rTG-CBnzMqH3haA%40mail.gmail.com.

Re: [racket] Inconsistency of `in-range` and numerical issues

[Alexis King]

I think that’s precisely what Alexander’s exact-decimal-lang does. It’s a 
meta-language just like at-exp.

> On Feb 26, 2015, at 08:38, Eric Dong  wrote:
> 
> I feel like swapping out flonums by default to rationals by default would 
> cause unexpected slowness in a large number of programs though. Would it be 
> possible to make it a reader extension like at-exp is currently? So I can say 
> "#lang exact-decimals racket", and the reader would read the decimals as 
> rationals?
> 
> On Thu, Feb 26, 2015 at 9:13 AM, Neil Toronto  > wrote:
> On 02/24/2015 01:11 PM, Konrad Hinsen wrote:
> On 24/02/2015 16:41, Laurent wrote:
> 
> I've discovered a rather troubling behaviour when using `in-range` with
> floating point numbers, which I think is worth knowing in case you
> hadn't consider the issue before:
> 
> On my machine, I get the following:
> 
> (length (for/list ([i (in-range .1 .7 .1)]) i)) ; 6
> (length (for/list ([i (in-range .1 .8 .1)]) i)) ; 8 (!)
> 
> But:
> (length (for/list ([i (in-range 1/10 7/10 1/10)]) i)) ; 6
> (length (for/list ([i (in-range 1/10 8/10 1/10)]) i)) ; 7
> 
> 
> Would it be a good idea to safe-guard these kinds of cases directly in
> `in-range`?
> 
> The problem is an old one that already troubled programmers in the age
> of Fortran. I suspect there is no reasonable safe-guard, with
> "reasonable" meaning that it does what people expect in all situations.
> 
> The only way to stay out of trouble is to avoid loops defined by an
> accumulating floating-point value. This means either don't use floats
> (write the loop over integers or rationals and convert to floats when
> using the loop index), or don't use accumulation (define your range by
> two points and the number of subdivisions, rather than the width of
> subintervals).
> 
> I should have chimed in to support this two days ago, but this is exactly the 
> right answer. Here's what Konrad means by his first alternative (write the 
> loop over integers or rationals):
> 
>   (length
>(for*/list ([i  (in-range 1 8 1)]
>[i  (in-value (* i 0.1))])
>  i))
> 
> The second alternative is a little harder to get right because of fencepost 
> errors [1]. Fortunately, Racket has a library function for it. Unfortunately, 
> it's buried in `plot/utils`. Here it is in action:
> 
> > (require (only-in plot/utils linear-seq))
> 
> > (linear-seq 0.0 1.0 4)
> '(0.0 0. 0. 1.0)
> 
> > (linear-seq 0.0 1.0 4 #:start? #f)
> '(0.14285714285714285 0.42857142857142855 0.7142857142857142 1.0)
> 
> > (linear-seq 0.0 1.0 4 #:start? #f #:end? #f)
> '(0.125 0.375 0.625 0.875)
> 
> I should really move this function into `math/base`.
> 
> If you must use a flonum step size, do something like this:
> 
>   (define (flonum-range start end step)
> (define n (exact-ceiling (/ (- end start) step)))
> (for/list ([i  (in-range 0 n)])
>   (+ start (* i step
> 
> To get points with 0.5 ulp error each, which is the best you can do, add 
> (require math/flonum) to your program and change the loop body to (flfma step 
> (fl i) start).
> 
> Arguably, `in-range` should do something like the above when given 
> floating-point step lengths. I don't know how feasible that is, though.
> 
> Neil ⊥
> 
> [1] http://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error 
> 
> 
> 
> 
>  Racket Users list:
>  http://lists.racket-lang.org/users 
> 
> 
>  Racket Users list:
>  http://lists.racket-lang.org/users


  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] TLS "atom?" definition for Scheme does not work in DrRacket

[Alexis King]

> That's how I found the problem, although I had to chase it down off the
> bottom of the pane.

If the arrow goes off-screen, you can right-click the identifier and select 
“Jump to Binding Occurrence” to automatically scroll to where the identifier is 
bound. You can also select “Tack/Untack Arrows” to make the arrows persist even 
after you move the cursor off the identifier.

Definitely a helpful feature overall.

  Racket Users list:
  http://lists.racket-lang.org/users

[racket] Is this function typeable in Typed Racket?

[Alexis King]

Disclaimer: this question is both a real question and me trying to push the 
type system to its limits, so I’m not really expecting to get a satisfactory 
answer.

I posted a question on Stack Overflow here 
, but I’m guessing that this is 
unfortunately far too localized to be answered there, so I’m posting it here as 
well. The original question is as follows:

I can write a simple function in untyped Racket called curry-all that takes a 
list of functions, all of which accept the same kind of value for their first 
argument, and produces a list of functions with their first arguments curried.

(define (curry-all fs arg)
  (map (λ (f) (curry f arg)) fs))
For a running example of the above function, see this snippet on pasterack 
.

This is a valid function, but I'm not sure if it's even possible to type in 
Typed Racket given its polymorphic typing constructs. The type of curry itself 
is already fairly complex, and obviously the type of curry-all would need to be 
necessarily more complex.

I made a relatively simple attempt at typing this function, though I was quite 
aware that it would not function as I liked:

(: curry-all
   (All [a c b ...]
(Listof (-> a b ... b c)) a
 -> (Listof (-> b ... b c
(define (curry-all fs arg)
  (map (λ ([f : (-> a b ... b c)])
 (curry f arg))
   fs))
Obviously, this works if all the functions have identical types (which isn’t 
worthless!), but it fails if they have different arities, even if their first 
arguments’ types are shared.

Is there any way to specify this function’s type so that it will work in a more 
general case?
  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] Problem with response/output

[Alexis King]

I do sort of agree that the void? requirement is strange and unneeded. It’s 
usually only used to indicate that a function provided by some module returns 
#, but callback functions are usually specified with any as the return 
value to allow precisely this sort of thing.

> On Mar 6, 2015, at 16:26, Matthew Butterick  wrote:
> 
> From the error message, I changed the lambda to return (void) and then it 
> worked.
> I think maybe the contract is wrong but frankly I don't understand much about 
> contracts.
> 
> The contract, by definition, is always right ;)
> 
> In this case, `response/output` takes as its first argument a procedure that 
> accepts an output-port and returns void. [1] In contract-speak this is 
> commonly written with dot notation as:
> 
> (output-port? . -> . void?) 
> 
> but it appears in error messages, like the one above, with the equivalent 
> notation:
> 
> (-> output-port? void?)
> 
> Note also that the error says the contract violation was "in the range of the 
> 1st argument of" ... [giant contract follows]. That helps track down the 
> error. The contract for the first argument is '(-> output-port? void?)'. This 
> is a procedure contract. And "the range of" a procedure contract means the 
> contract on the return value. Which in this case is `void?`. So the complaint 
> is that the procedure given in the first argument is returning '11' when it 
> should be returning void.
> 
> Why is (-> output-port? void?) the contract for the first arg of 
> `response/output`? The idea is that you write to the output-port directly 
> rather than returning a value to the caller. Insisting on void as a return 
> value imposes an extra measure of discipline, and sets an expectation.
> 
> The reason your 'not-working' dispatcher is not working is that `write-bytes` 
> does two things: it sends bytes to the output port, but then also returns the 
> number of bytes written. [2] So this procedure:
> 
> (λ (op) (write-bytes #"Hello world" op))
> 
> is defective because it returns the number of bytes. Meaning, it breaks the 
> contract, which demands void. (That's also why your error is '11': that's the 
> number of bytes in "Hello world"). 
> 
> But your revised procedure:
> 
> (λ (op) (write-bytes #"Hello world" op) (void))
> 
> Meets the contract because it ignores the return value from `write-bytes` and 
> returns (void) instead.
> 
> You should repeat this technique whenever you use `response/output`.
> 
> You can also look into `response/full` and `response/xexpr`, which can be a 
> more convenient way of making simple HTML or text responses.
> 
> 
> 
> [1] 
> http://docs.racket-lang.org/web-server/http.html?q=response%2Foutput#%28def._%28%28lib._web-server%2Fhttp%2Fresponse-structs..rkt%29._response%2Foutput%29%29
>  
> 
> 
> which cross-references
> 
> http://docs.racket-lang.org/web-server/http.html?q=response%2Foutput#%28def._%28%28lib._web-server%2Fhttp%2Fresponse-structs..rkt%29._response%29%29
>  
> 
> 
> [2] 
> http://docs.racket-lang.org/reference/Byte_and_String_Output.html?q=write-bytes#%28def._%28%28quote._~23~25kernel%29._write-bytes%29%29
>  
> 
> 
> which cross-references
> 
> http://docs.racket-lang.org/reference/Byte_and_String_Output.html?q=write-bytes#%28def._%28%28quote._~23~25kernel%29._write-string%29%29
>  
> 
> 
> 
> 
> On Fri, Mar 6, 2015 at 3:48 PM, André Matheus  > wrote:
> Hi, starting a project of mine, I've setup a dispatch rule and a function to 
> return the response.
> To make things simple, I've used response/output, with a lambda writing to 
> the output-port.
> However, I've got the error:
> 
> response/output: contract violation
>   expected: void?
>   given: 11
>   in: the range of
>   the 1st argument of
>   (->*
>((-> output-port? void?))
>(#:code
> number?
> #:headers
> (listof header?)
> #:message
> bytes?
> #:mime-type
> (or/c bytes? #f)
> #:seconds
> number?)
>response?)
>   contract from: 
>   /web-server-lib/web-server/http/response-structs.rkt
>   blaming: /home/amatheus/Dropbox/focus/todagendas/teste.rkt
>(assuming the contract is correct)
>   at: /web-server-lib/web-server/http/response-structs.rkt:41.2
>   context...:
>/usr/share/racket/collects/racket/contract/private/blame.rkt:143:0: 
> raise-blame-error16
>/usr/share/racket/pkg

Re: [racket] Looking for better designs to learn principles.

[Alexis King]

There’s also the thrush function from the point-free package, which uses the 
argument order of the threading macro while providing the functional style of 
compose.

http://pkg-build.racket-lang.org/doc/point-free/index.html?q=thrush#%28def._%28%28lib._point-free%2Fmain..rkt%29._thrush%29%29
 

> On Mar 14, 2015, at 15:35, Sean Kanaley  wrote:
> 
> If "thread-through macro" refers to 
> "http://www.greghendershott.com/2013/05/the-threading-macro.html 
> " then I 
> recommend a functional alternative called "compose":
> 
> (define print/cdr
>   (match-lambda
> [(cons x xs) (print x) xs]))
> 
> (define print-two
>   (compose print/cdr print/cdr))
> 
> The result is chained through naturally since the input and output type of 
> the lower level function are equal.
> 
> For any number of printings
> 
> (define (print-n n)
>   (for/fold ([print-n identity])
> ([i n])
> (compose print/cdr print-n)))
> 
> (define print-two (print-n 2))
> 
> And for any number of anythings
> 
> (define (iterate f n)
>   (for/fold ([chain identity])
> ([i n])
> (compose f chain)))
> 
> (define print-two (iterate print/cdr 2))
> 
> 
> On Thu, Mar 12, 2015 at 2:25 PM, Don Green  > wrote:
> ;Design A:
> ;Rating: 1 out of 10
> ;Poor because it uses set!
> (define print-two 
>   (lambda (f)
>(print (first f))
>(set! f (rest f))
>(print (first f))
>(set! f (rest f))
>f))
> 
> (void (print-two '(1 2))) ;=> 12
> ;-
> ;Design B:
> ;Rating: 2 out of 10
> ;Better because it nests expressions to avoid using set!
> ;Poor because it less readable.
> (define print-two
>   (lambda (f)
> (print (first f))
> (print (first (rest f)))
> f))
> 
> (void (print-two '(1 2))) ;=> 12
> When called in situations that allow one expression only, enclose call within 
> a 'begin' expression.
> ;-
> ;Design C:
> ;Rating: 3 out of 10
> ;Is this an even better design because it is more readable than nesting 
> expressions as in Design B above?
> (define (print-two f)
>   (let* ([_ (print (first f))]
>  [f (rest f)]
>  [_ (print (first f))]
>  [f (rest f)])
> f))
> (void (print-two '(1 2))) ;=> 12
> ;-
> My questions are: 
> "Can you recommend a better method?"
> "Can you recommend a better method using 'define with lambda'?"
> "Does your better method use a macro?"
> "Does your better method use a thread-through macro?"  If so, could you 
> please provide the definition of the thread-through macro.
> THANKS!
> 
> 
> 
>   Racket Users list:
>   http://lists.racket-lang.org/users 
> 
> 
> 
>  Racket Users list:
>  http://lists.racket-lang.org/users


  Racket Users list:
  http://lists.racket-lang.org/users

[racket] Nearly all of the functionality from the 2htdp teachpacks is now available in 2htdp-typed

[Alexis King]

I’ve had the 2htdp-typed package 
 available for a little 
while now, which is a Typed Racket wrapper for the HtDP/2e teachpacks. It was 
missing big-bang, since it is implemented as a macro, but I have now added 
support for big-bang in Typed Racket.

The syntax of big-bang is identical to its untyped equivalent except for one 
thing: it requires an annotation that specifies what the type of the WorldState 
parameter should be. The exact syntax for big-bang is provided in the 
documentation.

There are still a couple of unsupported features:

The universe/networked worlds (“The World is Not Enough”) are not supported. 
This actually shouldn’t be terribly difficult to add, I just have absolutely no 
experience working with universe programs, so I haven’t tried.

The 2htdp/planetcute collection of sprites is not yet available in Typed 
Racket. This also shouldn’t be terribly difficult to add, but my first attempt 
ran into some complexities in how the identifiers are provided that I did not 
anticipate, and I haven’t taken the time to look into it since. (See 
https://github.com/racket/htdp/issues/2 
 for some limited information about 
that.)

Otherwise, I think everything should work just fine. I don’t have many programs 
that use these libraries sitting around, but I’d love to know if this wrapper 
works with existing world/universe programs.

Feedback and bug reports much appreciated, pull requests welcome!

Alexis King
  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] Nearly all of the functionality from the 2htdp teachpacks is now available in 2htdp-typed

[Alexis King]

Yeah, I’ve definitely noticed the amount of effort put into sending good error 
messages from misuses of the htdp functions. I did attempt the bare minimum of 
supplying reasonable error messages: the identifiers are the same as the ones 
used in 2htdp/universe, so the “out of context” messages are still signaled, 
and I’ve added some basic descriptions to the syntax-parse fields to make the 
error messages give a little more context.

At the same time, I’ve noticed that big-bang itself has some obviously very 
sophisticated mechanics for detecting subtle mistakes. The “this identifier 
appears to have been used as a variable” error messages are pretty advanced, 
though at that point I guess I’m not sure why you didn’t just detect for the 
datums instead of identifiers.

Anyway, as for those and the stepper, the stepper obviously doesn’t work with 
TR, anyway, and I’d imagine that people able to read Typed Racket’s error 
messages would probably be able to handle these ones. I’m not discounting your 
point—you’re right that this is probably less accessible for students—but I 
guess using it would be out of their grasp, anyway, at least for now.

> On Mar 15, 2015, at 09:04, Matthias Felleisen  wrote:
> 
> 
> Thanks. That's awesome. FWIW, we have had several attempts at typing world, 
> and I think certain instructors may wish to give this a spin. I really like 
> it that you converted it all to syntax-parse and didn't sacrifice the 
> faux-keyword approach. But do understand that the kind of students we imagine 
> may have a hard time with the error messages signaled from syntax-parse. [The 
> complications of the existing implementation are partly about sending good 
> error messages and partly about making sure that the stepper works, which my 
> first and second implementation of the current world package did not.] -- 
> Matthias
> 
> 
> 
> 
> 
> On Mar 14, 2015, at 8:39 PM, Alexis King wrote:
> 
>> I’ve had the 2htdp-typed package 
>> <https://github.com/lexi-lambda/racket-2htdp-typed> available for a little 
>> while now, which is a Typed Racket wrapper for the HtDP/2e teachpacks. It 
>> was missing big-bang, since it is implemented as a macro, but I have now 
>> added support for big-bang in Typed Racket.
>> 
>> The syntax of big-bang is identical to its untyped equivalent except for one 
>> thing: it requires an annotation that specifies what the type of the 
>> WorldState parameter should be. The exact syntax for big-bang is provided in 
>> the documentation.
>> 
>> There are still a couple of unsupported features:
>> 
>> The universe/networked worlds (“The World is Not Enough”) are not supported. 
>> This actually shouldn’t be terribly difficult to add, I just have absolutely 
>> no experience working with universe programs, so I haven’t tried.
>> 
>> The 2htdp/planetcute collection of sprites is not yet available in Typed 
>> Racket. This also shouldn’t be terribly difficult to add, but my first 
>> attempt ran into some complexities in how the identifiers are provided that 
>> I did not anticipate, and I haven’t taken the time to look into it since. 
>> (See https://github.com/racket/htdp/issues/2 
>> <https://github.com/racket/htdp/issues/2> for some limited information about 
>> that.)
>> 
>> Otherwise, I think everything should work just fine. I don’t have many 
>> programs that use these libraries sitting around, but I’d love to know if 
>> this wrapper works with existing world/universe programs.
>> 
>> Feedback and bug reports much appreciated, pull requests welcome!
>> 
>> Alexis King
>> 
>>  Racket Users list:
>>  http://lists.racket-lang.org/users <http://lists.racket-lang.org/users>
> 


  Racket Users list:
  http://lists.racket-lang.org/users

[racket] Can I get some feedback / a code review for some simple game code?

[Alexis King]

I wrote a “game” (in quotes because it’s a WIP and barely qualifies as a game 
in its current state) using Typed Racket and big-bang. You can find it here:

https://github.com/lexi-lambda/racket-pipe-game-clone 


I’ve been wanting to try my hand at writing a very simple game in Racket using 
pure functional programming, and this was my first attempt at doing so. I think 
it’s turned out rather nice thus far, but I’d love to get some advice or 
feedback from more seasoned programmers.

My design philosophy for this project along with other information is included 
in the project’s README.

I’ve also decided to post this on the r/Racket subreddit 
,
 just for fun, though I get the sense it’s relatively dormant. Anyway, any 
method of feedback would be much appreciated—whether it be via email, comment 
on Reddit, or even inline comments on GitHub.

Thanks,
Alexis

P.S. Also, a big shoutout to all the people who contributed in some way, 
however small, to all the awesome tools that went into making this little 
project! I’m pitifully incompetent when it comes to graphics programming and 
game development, but working with pict and big-bang in Typed Racket was 
stunningly easy. Thanks for making that all possible.
  Racket Users list:
  http://lists.racket-lang.org/users

[racket] Submodule tests vs separate-file tests

[Alexis King]

Is there any preferred convention for location of tests in libraries? Using a 
test submodule is convenient, but does keeping all the tests in separate files 
reduce loading costs? Does using submodules bloat the .zo size, or are they 
compiled separately a la Java inner classes?

Alexis
  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] Submodule tests vs separate-file tests

[Alexis King]

Neat, thanks.

> On Mar 17, 2015, at 04:58, Matthew Flatt  wrote:
> 
> Using a submodule does increase the ".zo" file size, but the submodule
> portion of the ".zo" file is not loaded when the main module is loaded,
> so it's as good as a separate bytecode file.
> 
> At Tue, 17 Mar 2015 01:38:25 -0700, Alexis King wrote:
>> Is there any preferred convention for location of tests in libraries? Using 
>> a 
>> test submodule is convenient, but does keeping all the tests in separate 
>> files 
>> reduce loading costs? Does using submodules bloat the .zo size, or are they 
>> compiled separately a la Java inner classes?
>> 
>> Alexis
>>  Racket Users list:
>>  http://lists.racket-lang.org/users



  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] Can I get some feedback / a code review for some simple game code?

[Alexis King]

That’s probably a good idea. I’m not quite sure what you’re referring to by 
“zippers”, though—could you elaborate?

> On Mar 17, 2015, at 06:44, Matthias Felleisen  wrote:
> 
> 
> This is indeed exemplary. One thing I'd like to request in the README file is 
> a description of the "game's" idea. As for inefficiencies, consider using 
> zippers to lower the syntactic overhead; it may also help with allocation. -- 
> Matthias
> 
> 
> 
> 
> 
> On Mar 17, 2015, at 12:17 AM, Benjamin Greenman  wrote:
> 
>> This was fun, and the code was easy to read.
>> Besides that I don't have much constructive criticism. Figure out why it's 
>> lagging and finish the game!
>> 
>> 
>> On Mon, Mar 16, 2015 at 4:01 AM, Alexis King  wrote:
>> I wrote a “game” (in quotes because it’s a WIP and barely qualifies as a 
>> game in its current state) using Typed Racket and big-bang. You can find it 
>> here:
>> 
>> https://github.com/lexi-lambda/racket-pipe-game-clone
>> 
>> I’ve been wanting to try my hand at writing a very simple game in Racket 
>> using pure functional programming, and this was my first attempt at doing 
>> so. I think it’s turned out rather nice thus far, but I’d love to get some 
>> advice or feedback from more seasoned programmers.
>> 
>> My design philosophy for this project along with other information is 
>> included in the project’s README.
>> 
>> I’ve also decided to post this on the r/Racket subreddit, just for fun, 
>> though I get the sense it’s relatively dormant. Anyway, any method of 
>> feedback would be much appreciated—whether it be via email, comment on 
>> Reddit, or even inline comments on GitHub.
>> 
>> Thanks,
>> Alexis
>> 
>> P.S. Also, a big shoutout to all the people who contributed in some way, 
>> however small, to all the awesome tools that went into making this little 
>> project! I’m pitifully incompetent when it comes to graphics programming and 
>> game development, but working with pict and big-bang in Typed Racket was 
>> stunningly easy. Thanks for making that all possible.
>> 
>> 
>>  Racket Users list:
>>  http://lists.racket-lang.org/users
>> 
>> 
>> 
>> Racket Users list:
>> http://lists.racket-lang.org/users
> 



  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] the typed Values restriction

[Alexis King]

It might be a good idea to have a special case for Values when producing error 
messages. Currently, even though the documentation mentions that Values is only 
valid as the return type of a function, the error messages can be a little 
confusing. For example, using Values as an expression produces the error “type 
name used out of context,” but it isn’t really a type.

> On Mar 18, 2015, at 14:01, Sam Tobin-Hochstadt  wrote:
> 
> Type variables range only over types, and `(Values A B)` isn't a type.
> If your program type checked, then the following program would too:
> 
> (: my-force : (All (A) (-> A) -> A))
> (define (my-force f)
>  (let ([tmp : A (f)]) tmp))
> 
> (my-force (lambda () (values (void) (void)))
> 
> but this program has a runtime error with the wrong number of values.
> 
> Sam
> 
> On Wed, Mar 18, 2015 at 4:48 PM, Benjamin Greenman  wrote:
>> Today I got a surprising type error that I think is worth sharing.
>> 
>> (: my-force (All (A) (-> (-> A) A))
>> (define (my-force x) (x))
>> 
>> (my-force (lambda () (values (void) (void)))
>> ;; ERROR! 'my-force' cannot be applied to argument.
>> ;; expected "(-> A)", got "(-> (values Void Void))"
>> ;; result type "A", expected result "AnyValues"
>> 
>> (inst my-force (Values Void Void))
>> ;; Parse Error in type: "Values" is unbound
>> 
>> That is all. I see now that Values is only allowed in result positions, but
>> I'd still expected this to work.
>> 
>> 
>> 
>>  Racket Users list:
>>  http://lists.racket-lang.org/users
>> 
> 
>  Racket Users list:
>  http://lists.racket-lang.org/users



  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] Can I get some feedback / a code review for some simple game code?

[Alexis King]

I’ve now looked into zippers, and while they do seem useful, I’m unsure how 
they could be applied in this particular case. Could you explain where you saw 
potential for their use?

> On Mar 17, 2015, at 10:18, Matthias Felleisen  wrote:
> 
> 
> http://en.wikipedia.org/wiki/Zipper_(data_structure)
> 
> 
> On Mar 17, 2015, at 1:14 PM, Alexis King  wrote:
> 
>> That’s probably a good idea. I’m not quite sure what you’re referring to by 
>> “zippers”, though—could you elaborate?
>> 
>>> On Mar 17, 2015, at 06:44, Matthias Felleisen  wrote:
>>> 
>>> 
>>> This is indeed exemplary. One thing I'd like to request in the README file 
>>> is a description of the "game's" idea. As for inefficiencies, consider 
>>> using zippers to lower the syntactic overhead; it may also help with 
>>> allocation. -- Matthias
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Mar 17, 2015, at 12:17 AM, Benjamin Greenman  wrote:
>>> 
>>>> This was fun, and the code was easy to read.
>>>> Besides that I don't have much constructive criticism. Figure out why it's 
>>>> lagging and finish the game!
>>>> 
>>>> 
>>>> On Mon, Mar 16, 2015 at 4:01 AM, Alexis King  wrote:
>>>> I wrote a “game” (in quotes because it’s a WIP and barely qualifies as a 
>>>> game in its current state) using Typed Racket and big-bang. You can find 
>>>> it here:
>>>> 
>>>> https://github.com/lexi-lambda/racket-pipe-game-clone
>>>> 
>>>> I’ve been wanting to try my hand at writing a very simple game in Racket 
>>>> using pure functional programming, and this was my first attempt at doing 
>>>> so. I think it’s turned out rather nice thus far, but I’d love to get some 
>>>> advice or feedback from more seasoned programmers.
>>>> 
>>>> My design philosophy for this project along with other information is 
>>>> included in the project’s README.
>>>> 
>>>> I’ve also decided to post this on the r/Racket subreddit, just for fun, 
>>>> though I get the sense it’s relatively dormant. Anyway, any method of 
>>>> feedback would be much appreciated—whether it be via email, comment on 
>>>> Reddit, or even inline comments on GitHub.
>>>> 
>>>> Thanks,
>>>> Alexis
>>>> 
>>>> P.S. Also, a big shoutout to all the people who contributed in some way, 
>>>> however small, to all the awesome tools that went into making this little 
>>>> project! I’m pitifully incompetent when it comes to graphics programming 
>>>> and game development, but working with pict and big-bang in Typed Racket 
>>>> was stunningly easy. Thanks for making that all possible.
>>>> 
>>>> 
>>>> Racket Users list:
>>>> http://lists.racket-lang.org/users
>>>> 
>>>> 
>>>> 
>>>> Racket Users list:
>>>> http://lists.racket-lang.org/users
>>> 
>> 
> 



  Racket Users list:
  http://lists.racket-lang.org/users

[racket] Serving static content

[Alexis King]

I’m interested in creating a web application, and I plan to write the front-end 
in ordinary JavaScript and HTML. A large portion of the content served will 
just be static HTML, JavaScript, and CSS.

I plan to interact with the server via a standard JSON API and WebSockets, both 
of which I’m interested in developing in Racket. That said, does it make any 
sense to use the Racket web server to serve purely static content? Would it be 
more worth my time to use a more traditional server infrastructure for the 
caching and content handling?

Either way, is there a good method for serving static content via the Racket 
web server? Is there anything I should know to get the best performance if I 
did plan to go that route?

Thanks,
Alexis

  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] Unsafe version of require/typed?

[Alexis King]

This has been discussed before, and I think it’s a good idea, but I also think 
any such feature should be well-hidden. I’m sure that new users would use it 
frequently just to make the typechecker “shut up” when really their programs 
are unsound.

> On Mar 20, 2015, at 12:30, Hendrik Boom  wrote:
> 
> On Fri, Mar 20, 2015 at 03:20:38PM -0400, Eric Dong wrote:
>> It would be nice if we could have an unsafe version of require/typed, which
>> doesn't generate a contract, but simply "lies" to the type system about the
>> type. This, of course, breaks the type system's guarantees, and causes UB
>> if optimizations are one, but in some cases contracts cannot be generated
>> (for example, for the "object-name" function), but one can create a safe
>> type for it.
>> 
>> Why can't there be a "require/typed/unsafe" form? It could save a lot of
>> unnecessary asserts and casts, and unnecessary contract overhead.
> 
> Perhaps this model can provide guidance:
> 
> If I recall correctly, Modula 3, another garbage-collected, strongly 
> typed language, has unsafe interfaces and, separately, unsafe 
> implementations.
> 
> You can implement a safe (i.e., ordinary) interface with an unsafe 
> implementation.  This means that it is the implementer's 
> (not  the compiler's) responsibility to make sure that the the module 
> will perform all necessary run-time checks to make sure that it can 
> only be used safely, but the implementation can use unsafe language 
> features.
> 
> An unsafe interface, on the other hand, can only be used in an unsafe 
> implementation.
> 
> -- hendrik
> 
>  Racket Users list:
>  http://lists.racket-lang.org/users



  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] Unsafe version of require/typed?

[Alexis King]

The difference is that avoiding TR entirely means (1) you can’t break the 
soundness of other things in Typed Racket and (2) all unsafe operations need to 
be explicitly marked as such.

Allowing people to bypass the typechecker means all unsoundness could lead to 
segfaults (due to the optimizer) and malicious (or just shoddy) code could 
actually make other TR programs that depend on them unstable.

> On Mar 20, 2015, at 13:45, Robby Findler  wrote:
> 
> I think we should think the best of our users and not assume that we
> know better than they do about what they need to do their work.
> 
> In this particular case, they can always opt out of tr entirely, lets
> not forget.
> 
> Robby
> 
> On Fri, Mar 20, 2015 at 3:41 PM, Alexis King  wrote:
>> This has been discussed before, and I think it’s a good idea, but I also 
>> think any such feature should be well-hidden. I’m sure that new users would 
>> use it frequently just to make the typechecker “shut up” when really their 
>> programs are unsound.
>> 
>>> On Mar 20, 2015, at 12:30, Hendrik Boom  wrote:
>>> 
>>> On Fri, Mar 20, 2015 at 03:20:38PM -0400, Eric Dong wrote:
>>>> It would be nice if we could have an unsafe version of require/typed, which
>>>> doesn't generate a contract, but simply "lies" to the type system about the
>>>> type. This, of course, breaks the type system's guarantees, and causes UB
>>>> if optimizations are one, but in some cases contracts cannot be generated
>>>> (for example, for the "object-name" function), but one can create a safe
>>>> type for it.
>>>> 
>>>> Why can't there be a "require/typed/unsafe" form? It could save a lot of
>>>> unnecessary asserts and casts, and unnecessary contract overhead.
>>> 
>>> Perhaps this model can provide guidance:
>>> 
>>> If I recall correctly, Modula 3, another garbage-collected, strongly
>>> typed language, has unsafe interfaces and, separately, unsafe
>>> implementations.
>>> 
>>> You can implement a safe (i.e., ordinary) interface with an unsafe
>>> implementation.  This means that it is the implementer's
>>> (not  the compiler's) responsibility to make sure that the the module
>>> will perform all necessary run-time checks to make sure that it can
>>> only be used safely, but the implementation can use unsafe language
>>> features.
>>> 
>>> An unsafe interface, on the other hand, can only be used in an unsafe
>>> implementation.
>>> 
>>> -- hendrik
>>> 
>>> Racket Users list:
>>> http://lists.racket-lang.org/users
>> 
>> 
>> 
>>  Racket Users list:
>>  http://lists.racket-lang.org/users



  Racket Users list:
  http://lists.racket-lang.org/users

Re: [racket] making libraries work natively with both Racket & Typed Racket

[Alexis King]

Sorry for my misunderstanding, but what’s the point of this? Why not just 
require the typed code in untyped code directly (as you’re doing in 'violator)? 
As far as I can tell, it looks like you’re just manually rewriting the 
generated contracts, so I’m not really sure what this achieves.

> On Mar 21, 2015, at 11:09, Matthew Butterick  wrote:
> 
> Is there an approved way of using #lang typed/racket/base/no-check (or maybe 
> `with-type`) to create libraries that have both a typed and untyped 
> interface? (The goal being to avoid use of `require/typed`)
> 
> For instance, the following works, but maybe it's a bad idea for other 
> reasons:
> 
> ;;;
> 
> ;; adder.rkt = write typed code, but leave off #lang line & `provide`
> 
> (: fladd (Flonum Flonum . -> . Flonum))
> (define (fladd f1 f2)
>  (+ f1 f2))
> ;;;
> 
> 
> ;;;
> 
> ;; typed.rkt = compile in typed context
> 
> #lang typed/racket/base
> (require racket/include)
> (provide fladd)
> (include "adder.rkt")
> ;;;
> 
> 
> ;;;
> 
> ;; untyped.rkt = compile in untyped context with contract
> 
> #lang typed/racket/base/no-check
> (require racket/include racket/contract racket/math)
> (provide (contract-out [fladd (flonum? flonum? . -> . flonum?)]))
> (include "adder.rkt")
> ;;;
> 
> 
> ;;;
> 
> ;; test.rkt
> 
> #lang racket/base
> 
> (module typed typed/racket/base
>  (require "typed.rkt")
>  (require typed/rackunit)
>  (check-equal? (fladd 1.0 2.0) 3.0)) ; typechecks correctly
> 
> (module untyped racket/base
>  (require "untyped.rkt")
>  (require rackunit)
>  (check-equal? (fladd 1.0 2.0) 3.0) ; meets `provide` contract
>  (check-exn exn:fail:contract? (λ () (fladd 1 2 ; violates `provide` 
> contract
> 
> (module violator racket/base
>  (require "typed.rkt")
>  (require rackunit)
>  (check-exn exn:fail:contract? (λ () (fladd 1 2 ; violates typed/untyped 
> contract barrier
> 
> (require 'typed)
> (require 'untyped)
> (require 'violator)
> ;;;
> 
> 
> 
>  Racket Users list:
>  http://lists.racket-lang.org/users



  Racket Users list:
  http://lists.racket-lang.org/users

[racket] Intercepting WebSocket connections to the Racket web server?

[Alexis King]

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

Re: [racket] TR: mystery behavior with optional-argument types

[Alexis King]

This feels eerily familiar to a very similar bug I found just yesterday, which 
I’ve reported here:
https://github.com/racket/typed-racket/issues/56 


Something about this is definitely very broken. For the first function, f1, it 
“typechecks” even if you change the Boolean type to, for example, String, so it 
seems the type is just being completely ignored. I’m not sure why.

> On Mar 21, 2015, at 19:29, Matthew Butterick  wrote:
> 
> I want to typecheck a function that looks like f1. But it doesn't work. The 
> types of 'bool' and 'syms' are reported as Any.
> 
> However, if I add a dummy keyword argument, as in f2, then everything 
> typechecks fine: 'bool' is reported as a Boolean and 'syms' is (Listof 
> Symbol).
> 
> Feature? Bug?
> 
> ;;;
> 
> #lang typed/racket
> 
> (: f1 (() (Boolean) #:rest Symbol . ->* . Any))
> (define (f1 [bool #t] . syms)
>  bool
>  syms)
> 
> (: f2 (() (Boolean #:x Integer) #:rest Symbol . ->* . Any))
> (define (f2 [bool #t] #:x [x 42] . syms)
>  bool
>  syms)
> 
>  Racket Users list:
>  http://lists.racket-lang.org/users


  Racket Users list:
  http://lists.racket-lang.org/users

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  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  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  <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  > 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  > > 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 
> > .
> > 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 
> .
> 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 
> .
> 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."
>   - D&C 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  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  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  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."
>  - D&C 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] 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 
>  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] the Racket manifesto

[Alexis King]

I think Greg Hendershott’s 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  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] 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  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] "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  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.

Re: [racket-users] syntax-parse and optional keywords

[Alexis King]

You can use ~and to bind it to an attribute.

(syntax-parse #'(foo)
  [(_ (~optional (~and #:kw kw)))
   (attribute kw)])
; => #f

> On Apr 17, 2015, at 05:38, Konrad Hinsen  wrote:
> 
> Hi everyone,
> 
> my question looks like something straightforward, but I have been
> reading through the documentation for a while without finding anything
> clearly helpful.
> 
> I want to define some syntax with an optional keyword but no arguments
> behind it. Something like #:mutable in struct. The pattern seems
> obvious:
> 
>   (~optional #:my-keyword)
> 
> but I don't see how I can detect the presence or absence of the
> keyword in the code that I generate. There is no attribute for
> which I could define a default.
> 
> 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.

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

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

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

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

[Alexis King]

I’ve gotten my curly-fn meta-language 
 working, and it works great 
within a module. However, evaluating #{+ 2} within the REPL just evaluates as a 
plain old vector, ignoring my readtable extension.

What gives? Using @-expression syntax in the REPL works just fine when using 
the at-exp meta-language, which seems pretty similar to my approach.

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

[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  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] 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  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.

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

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

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))
> #
> 
> > (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))
> #
> 
> > (drop 5 #(0 1 2 3 4 5 6 7 8 9))
> #

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

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

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.

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

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  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-parse #'(m #:op max 1 2 3)
> [(_ (~optional (~seq #:op op:expr)) arg:expr ...)
>  (template ((?? op +) arg ...))])
> #
> 
> 
> 
> 
> 
> On Wed, May 27, 2015 at 12:03 AM Alexis King  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] 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 #, 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] 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] 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] 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] 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  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.
> 

-- 
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] 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] 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//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//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] 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] 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  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.

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

You're right, that works for including some-fn in phase 1 but not phase 0. The 
trouble is that I actually want the inverse of that: some-fn should be defined 
in phase 0 but not phase 1.

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

I haven't figured out exactly how to make that particular configuration work.

> On Jun 28, 2015, at 01:21, Benjamin Greenman  wrote:
> 
> Sure, you just need to require and provide b at your favorite phase level in 
> c. Replacing module c with the following makes the rest compile for me:
> 
> 
> (module c racket/base
>   ;; Require & provide everything except `some-fun` at phase 0
>   (require (except-in (submod ".." b) some-fn))
>   (provide (all-from-out (submod ".." b)))
>   ;; Require & provide everything at phase 1
>   (require (for-syntax (submod ".." b)))
>   (provide (for-syntax (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]

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

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.

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

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 receiv

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.

[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] 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.

[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] 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] 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] 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] 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] Naming for generalization of find-min and find-max?

[Alexis King]

> You will be far more confusing for people who know the old names (from 
> 1960foobar) and can’t find the new ones. 

I have been looking into how to add index aliases for Scribble docs to address 
this problem. This may lead to another mailing list thread.

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

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

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

[Alexis King]

> And I'm surprised how many people claim to love #:keyword.  (The engineering 
> opposition to any non-backward-compatible change was entirely predictable, 
> but I assumed only a small percentage would actually prefer #:keyword, due to 
> familiarity or different aesthetic wiring, and that around half the people 
> would be indifferent to the change.)

I was going to refrain from saying anything more on this subject (I didn’t 
respond to the survey at all), but this point interested me. I realized that 
I’ve grown fond of #:keyword, and I didn’t have any idea why. There have been 
many times that I’ve found it clunky, or that I’ve missed Clojure or Ruby’s 
:keywords.

That’s when I realized: Racket doesn’t use its keywords like those languages 
do. Clojure uses them constantly—it uses them wherever Racket would usually use 
symbols—and Rails has elevated Ruby’s symbols above literal strings in pure 
frequency (for better or for worse).

In Ruby, I can do `x = :kw`. In Clojure, I can do (def x :kw). In Racket, I 
have to do (define x '#:kw), and that is really awful. I need not one but 
three(!) symbols in front of my raw identifier, and the level of syntactic 
noise is pretty atrocious. As a side effect of both this and the traditional 
use of symbols in scheme for this purpose, Racket pretty much only uses 
keywords for one thing: keyword arguments.

In Racket, a bare #:keyword used as an expression is not just useless, it is a 
syntax error. A Racket programmer is trained to see keywords in function 
application alone, so (foo #:kw bar) looks fine, but (foo #:kw) looks weird. 
They always need to be paired with a value. With keywords so integrally 
associated with function application syntax, I’ve grown to think of keywords as 
syntax, never as runtime values, and the hash prefix reinforces this. Heck, 
even syntax/parse’s :expr syntax class rules out keywords! They are little 
syntactic tags, nothing more.

For me, this is actually fine. I don’t really mind the verbosity, though making 
keyword arguments prettier would be nice to have. However, if you are arguing 
for using keywords as runtime values, that’s an entirely different story... 
though it does raise the question of how they should be special-cased in 
function application for keyword arguments (both Ruby and Clojure effectively 
transform keyword arguments into a single hash argument, rather than making 
“keyword procedures” that have some special magic).

Basically: keywords are very different in Racket. I don’t know much CL, so I 
can’t speak to that, but I think there’s more going on here than syntax. If 
that’s the case, omitting a hash would only solve a portion of the problem... 
and Racket programmers might not view their keywords in the same light as those 
from other languages. I certainly didn’t.

Sorry for the rambling... but maybe some food for thought.

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.