Re: [racket-users] Re: Advent of Code 2016

[Daniel Prager]

Hi Matthew

Really nice work, with Wires tutorial and all those AoC DSLs!


Dan

On 14 Dec 2016 14:34, "Matthew Butterick"  wrote:

I liked last year's Day 7 problem so much, I licensed it from the author
for a Racket DSL tutorial:

http://beautifulracket.com/wires/

This year I’m solving every problem as a DSL. Like cookies for Santa, I
will leave at least one for Benjamin Greenman.

https://github.com/mbutterick/aoc-racket/tree/2016/2016


On Monday, December 12, 2016 at 8:39:48 PM UTC-8, Daniel Prager wrote:
> Is anyone else Racketing their way through www.adventofcode.com this year?
>
> It's worth checking out.
>
> We could even do a "private" leaderboard for Racketeers.
>
> Last year's problems (2015) are still available, and the awesome Matthew
Butterick wrote up his Racket solutions: https://docs.
racket-lang.org/aoc-racket/index.html

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Operations that create objects

[George Neuner]

On Thu, 15 Dec 2016 06:03:54 -0800 (PST), NeverTooOldToCode
 wrote:

>Racket Reference section 1.1.5 states: "Operations that create
>objects, such as vector, add to the set of objects" followed
>by a nice and instructive step-by-step evaluation example.
>Further on, lambda is used as another example of an operation
>creating an object.
>
>How can I tell which operations create objects?

It is safe to assume that most operations will create new objects.  If
you're just beginning to learn the language, it isn't something you
need to worry about yet.


Racket is in the Lisp family of languages: most types of data are
"boxed".  Boxed data is stored in an object on the heap, together with
a "tag" that describes the type of the data.  Variables in your
program will contain references (pointers) to boxed values.

Racket does not distinguish between the boxed object and the reference
to it.  Any time you try to look at the reference, you see the data
inside the box instead.  In this way Racket is _not_ like other
languages in which pointers and/or references can examined and/or
manipulated separately.

The above is a bit simplistic: some types like characters and small
integers are "immediate" - stored directly in variables (or list
nodes, array slots, structure fields, etc.).  But it is safe to assume
that *most* types of data will be an object on the heap.


When you get to the point of needing to optimize programs for speed,
Racket does offer typed vectors and arrays which store numeric values
unboxed.  There is also a typed version of Racket which tries to
eliminate boxing data as much as is possible.



Explaining why lambda creates an object is a bit more complicated.

Lisp family languages, including Racket, support the concept of
"nested" functions: in other words, they permit functions to be
declared inside the scope of other functions.
[If you're familar with Algol or Pascal, etc., in general the nested
functions in Racket will act very similarly.]

Inner functions can access local variables of the outer functions that
enclose them.  This type of access is known as "non-global,
non-local", usually shortened in the literature to just "non-local".
It requires having a way to locate the variables that belong to the
enclosing functions.

Now, Racket also is in the Scheme language family.  In Scheme,
functions are "1st class", which means that they may create and return
new functions, be stored in data structures, be passed as arguments to
other functions, etc.

In particular, Scheme - and Racket - allows the creation of inner
functions that persist and can be called *after* their outer functions
have completed.  

Executing a function requires not just its code, but also external
data needed by the function: it's so-called "environment".  In many
languages, the environment consists only of global data and arguments
passed directly to the function - but the environment of an inner
function includes local variables of enclosing outer functions.

If an inner function is to persist after its enclosing outer function
has completed, the local variables of the outer function must *also*
persist.

To accomplish this, lambda creates an object called a "closure".  The
closure contains data defined by the outer function(s) that is needed
by the inner function, together with a pointer to the code of the
inner function.  The closure, being an object itself, can be
referenced by other data structures, passed as an argument, etc.

Closures permit functions to have persistent private data.  By sharing
closures, multiple functions can share data without the data being
defined globally.


If this sounds quite like the objects in your favorite OO language ...
well, it *is*.  The major difference is that closures are more general
than objects in most OO lanuages.   Lambda permits ad hoc associations
of data and code, without having to define classes, or clone a
"prototype" object, or worry about inheritence hierarchies.


Hope this helps,
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.

Re: [racket-users] ->i applies contract projections multiple times?

[Robby Findler]

Perhaps the contract implementation could notice that the indy blame
parties and the normal blame parties are the same and thus avoid the
second contract. Given today's experience I'm not sure it is worth
bothering, at least until other things improve in the contract
implementation.

But if you want to know more about how they could be different, you
might want to consider this example from section 1 of the paper. It
will (randomly) assign blame to any of the three submodules.

#lang racket
(module m1 racket
  (provide
   (contract-out
[deriv-contract
 contract?]))

  (define n 100)
  (define δ 0.01)

  (define deriv-contract
(->i ([f (-> real? real?)][ε real?])
 (fp (-> real? real?))
 #:post (f ε fp)
 (for/and ([i (in-range 0 n)])
   (define x (random-number))
   (define slope
 (/ (- (f (- x ε)) (f (+ x ε)))
(* 2 ε)))
   (<= (abs (- slope (fp x))) δ

  (define (random-number)
(case (random 10)
  [(0) 1+1i]
  [(1) 100]
  [else (random)])))

(module m2 racket
  (require (submod ".." m1))
  (provide (contract-out [deriv deriv-contract]))
  (define (deriv f ε)
(λ (x)
  (if (> x 1)
  (f #f)
  (f x)

(module m3 racket
  (require (submod ".." m2))
  (deriv (λ (x) (if (<= x 1) x #f)) 0.))

(require 'm3)


Robby


On Thu, Dec 15, 2016 at 4:05 PM, Alexis King  wrote:
> Many thanks to both of you for the explanation and examples. I admit
> I’ve seen that paper before, but I haven’t really taken the time
> to understand it. I haven’t spent the effort to understand all the
> notation being used, so much of the paper is pretty opaque to me.
> Maybe once I get some time I’ll sift through it more carefully, but
> in the meantime, Scott’s example helps a lot to demonstrate what
> indy dependent contracts actually do.
>
> However, from a practical implementation perspective, I’m still a
> little confused about why the contract needs to be applied twice.
> Given that Racket uses the +indy semantics, it seems like the blame
> provided is identical for both cases, so it seems like the contracts
> should only need to be applied once. For Scott’s example, the
> contract for the y argument needs to be applied such that if it is
> misused within the function body, then it blames foo, and if it is
> misused within the contract itself, it also blames foo.
>
> If ->i used the indy or -indy semantics (though admittedly I don’t
> get why the -indy semantics would ever be useful), I would understand
> why the contract would need to be applied twice, since the blame
> would be different. Given the way Racket handles things, though, I
> don’t really understand what I’m missing.
>
> --
> 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] ->i applies contract projections multiple times?

[Ben Greenman]

There are 3 parties that could be blamed:
1. the context that calls `foo`
2. the function `foo`
3. the contract on `foo`

On Thu, Dec 15, 2016 at 5:05 PM, Alexis King  wrote:

> Many thanks to both of you for the explanation and examples. I admit
> I’ve seen that paper before, but I haven’t really taken the time
> to understand it. I haven’t spent the effort to understand all the
> notation being used, so much of the paper is pretty opaque to me.
> Maybe once I get some time I’ll sift through it more carefully, but
> in the meantime, Scott’s example helps a lot to demonstrate what
> indy dependent contracts actually do.
>
> However, from a practical implementation perspective, I’m still a
> little confused about why the contract needs to be applied twice.
> Given that Racket uses the +indy semantics, it seems like the blame
> provided is identical for both cases, so it seems like the contracts
> should only need to be applied once. For Scott’s example, the
> contract for the y argument needs to be applied such that if it is
> misused within the function body, then it blames foo, and if it is
> misused within the contract itself, it also blames foo.
>
> If ->i used the indy or -indy semantics (though admittedly I don’t
> get why the -indy semantics would ever be useful), I would understand
> why the contract would need to be applied twice, since the blame
> would be different. Given the way Racket handles things, though, I
> don’t really understand what I’m missing.
>
> --
> 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-property lost across module boundary (WAS: format-id doesn't preserve preserved?-edness of syntax-property?)

['William J. Bowman' via Racket Users]

All,

Thanks for help debugging and explaining this.

FYI, with Matthew's bug fix merged, and help from Alexis, I've managed to work 
around my issue. It was pretty much the same issue described in thread linked 
to by Dupéron, 
https://groups.google.com/forum/#!topic/racket-users/TGax2h8dVxs, and also in 
the Racket GitHub issue https://github.com/racket/racket/issues/1495.

The workaround seems to be: if you want to stash an identifier in a 
syntax-property, expand into syntax that attaches the syntax-property. That is, 
don't do (define x (syntax-property #'id 'prop #'stx)) and then use x in a 
syntax object, but generate #`(... (syntax-property #'id 'prop #'stx ...))

In my example, the identifier that caused issues was generated by define^, 
which directly called syntax-property in a for-syntax helper function. The 
identifier that worked fine was generated by define^^, which generated syntax 
that included a syntax-property.

Maybe we shouldn't be stashing identifiers in syntax-properties at all, but in 
practice this workaround seems to work (in the implementations of Alexis' 
Rascal and my Cur).

--
William J. Bowman

On Wed, Dec 14, 2016 at 08:14:49AM -0700, Matthew Flatt wrote:
> I think there are two problems in this example.
> 
> 
> The first problem is that preserved syntax properties were not actually
> preserved in bytecode for a syntax object that has no source location.
> (I'm assuming that Alexis's tests were run in DrRacket in it's default
> mode of compiling bytecode for `require`d files.) I'll push a repair
> for that bug.
> 
> 
> The second problem is that syntax objects as property values don't work
> the way that you want. That limitation is why, even with the
> property-presevation bug fixed, the `free-identifier=?` test fails.
> Unfortunately, that's a limitation of syntax objects and properties
> that's difficult to resolve.
> 
> To explain a little more, consider the program
> 
>  https://gist.github.com/mflatt/d569d8f3a89e6815cf18df26adc11053
> 
> For now, look at just the `property` submodule. The
> `quote-syntax/add-example-property` macro is like `quote-syntax`,
> except that it adds an 'example property that holds the current time at
> compile time.
> 
> An expression like
> 
>  (syntax-property (quote-syntax/add-example-property id) 'example)
> 
> accesses that compile-time value at run time. If you compile the
> program to bytecode, the value shown by running the module later still
> reports the time that the module was compiled.
> 
> Now consider the enclosing module, which uses the `property` submodule
> and accesses the time for both a freshly quoted term and the value of
> `id` as exported by the submodule:
> 
>  (require 'property)
>  (syntax-property (quote-syntax/add-example-property new-id) 'example)
>  (syntax-property id 'example)
> 
> I think you won't be too surprised that the freshly quoted identifier
> has a newer time than the one reported for `id`. Even though both
> values were obtained from the same `compile-time` variable, each module
> compilation (submodule and enclosing module) gets a fresh instance of
> `compile-time`.
> 
> 
> In "format-id1.rkt", instead of `compile-time` bound to a timestamp,
> you have a quoted syntax object that you can image being implicitly
> lifted as
> 
>   (define-for-syntax compile-time #'id^)
> 
> In much the same way that `(current-inexact-milliseconds)` in
> 
>   (define-for-syntax compile-time (current-inexact-milliseconds))
> 
> produces a different result for each subsequent compile-time use of the
> modules, `#'id^` produces a different syntax object depending on how
> its enclosing module is instantiated. Imagine taking the compiled
> bytecode, saving it in two places, and loading it as a module from each
> place; the `#'id` evaluations for the copies will produce identifiers
> that claim to be from different modules relative to the filesystem.
> 
> So, here's the limitation: the implicit lifting that happens for a
> quoted syntax object, which enables a kind of re-evaluation of that
> syntax object in each module instance, doesn't happen for
> syntax-property values. More generally, changes to the scope of a
> syntax object are not propagated to property values that happen to be
> themselves syntax objects. When you put a syntax object into a
> property, then you get whatever that syntax object meant at the time it
> was attached as a property.
> 
> That might still sound ok for your case, because you compile and use
> "format-id1.rkt" in-place. Still, the information attached to `#'id^`
> changes. While compiling the module, the attached binding information
> says "the current module being compiled". When compiling
> "format-id2.rkt", the attached binding information for that `#'id^`
> says "format-id1.rkt".
> 
> 
> To summarize, don't try to attach syntax objects as property values
> like that. I know this advice sounds ironic, given that the original
> use of properties was for syntax-valued keys like 'origin. 

Re: [racket-users] ->i applies contract projections multiple times?

[Alexis King]

Many thanks to both of you for the explanation and examples. I admit
I’ve seen that paper before, but I haven’t really taken the time
to understand it. I haven’t spent the effort to understand all the
notation being used, so much of the paper is pretty opaque to me.
Maybe once I get some time I’ll sift through it more carefully, but
in the meantime, Scott’s example helps a lot to demonstrate what
indy dependent contracts actually do.

However, from a practical implementation perspective, I’m still a
little confused about why the contract needs to be applied twice.
Given that Racket uses the +indy semantics, it seems like the blame
provided is identical for both cases, so it seems like the contracts
should only need to be applied once. For Scott’s example, the
contract for the y argument needs to be applied such that if it is
misused within the function body, then it blames foo, and if it is
misused within the contract itself, it also blames foo.

If ->i used the indy or -indy semantics (though admittedly I don’t
get why the -indy semantics would ever be useful), I would understand
why the contract would need to be applied twice, since the blame
would be different. Given the way Racket handles things, though, I
don’t really understand what I’m missing.

-- 
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] ->i applies contract projections multiple times?

[Robby Findler]

I've pushed a fix for this and the related bug that I mentioned in
this thread. No important performance improvements, however (I believe
most of the time in ->i microbenchmarks is spent in just piping things
around, not doing the actual contract checking).

Robby


On Wed, Dec 14, 2016 at 5:33 PM, Alexis King  wrote:
> This question comes from someone else on Stack Overflow, which they
> asked here: http://stackoverflow.com/q/41144374/465378
>
> I think it’s likely that the people who can answer this are probably
> only on the mailing list, though, so I figured I’d ask it here.
>
> Basically, the ->i contract applies contract projections more than
> once, despite the fact that it seems unnecessary. Here’s the example
> provided in the question:
>
>   (define/contract (foo x y z)
> (->i ([x   (λ (x) (begin (displayln 0) #t))]
>   [y (x)   (λ (y) (begin (displayln 1) #t))]
>   [z (x y) (λ (z) (begin (displayln 2) #t))])
>  any)
> #t)
>
>   (foo 1 2 3)
>
> The above example prints the following when run:
>
>   0
>   0
>   1
>   1
>   2
>   #t
>
> This indicates that values used dependently for determining other
> contracts cause their contracts to be applied more than once. The
> above example only uses flat contracts, but I tested with a
> side-effectful impersonator contract and got the same result.
>
> After some very simple pondering, I couldn’t come up with a situation
> in which applying the contracts more than once would be necessary,
> and this could obviously have a performance penalty given that ->i
> is already a fairly slow contract. Is this a bug in ->i, or is it
> necessary or intentional behavior? If the latter, why is it necessary?
>
> 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.

-- 
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] ->i applies contract projections multiple times?

['John Clements' via users-redirect]

> On Dec 14, 2016, at 3:56 PM, Scott Moore  wrote:
> 
> Robby beat me to it. For a longer discussion, see Christos, Robby, Cormac and 
> Matthias’ paper: http://www.ccs.neu.edu/racket/pubs/popl11-dfff.pdf on the 
> difference between dependent (->d) and indy-dependent contracts (->i).
> 
> A contrived example of why this is better is:
> (define/contract (foo x y)
>   (->d ([x (λ (x) (y ‘evil) #t)]
> [y (-> integer? integer?)])
>[result any/c])
>   void)
> 
> (foo 0 (λ (x) (+ x 1)))
> 
> > +: contract violation   !!! Whoops, but I promised to only call y with 
> > integers!
>   expected: number?
>   given: 'evil
>   argument position: 1st
>   other arguments…:
> vs:
> 
> (define/contract (foo x y)
>   (->i ([x (y) (λ (x) (y 'evil) #t)]
> [y (-> integer? integer?)])
>[result any/c])
>   void)
> 
> (foo 0 (λ (x) (+ x 1)))
> 
> foo: broke its own contract  !!! Much better :)
>   promised: integer?
>   produced: 'evil
>   in: the 1st argument of
>   the y argument of
>   (->i
>((x (y) (λ (x) (y 'evil) #t))
> (y (-> integer? integer?)))
>(result any/c))
>   contract from: anonymous-module
>   blaming: anonymous-module
>(assuming the contract is correct)
>   at: unsaved-editor:3.18

Nice example. Just the right size to read and understand. Many thanks!

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.

Re: [racket-users] syntax-property lost across module boundary (WAS: format-id doesn't preserve preserved?-edness of syntax-property?)

[Stephen Chang]

> What are the implications of this for the Types as Macros/Turnstile
stuff?

As William mentioned, he's also working on a language using the Types
as Macros approach. Alex and I have run into the same issue, but it's
always with compiled files (without compiling, requires and provides
appear to behave as expected). Unfortunately, we have not figured out
a good solution either. Could we borrow any ideas from Typed Racket
here?

> but I’d like to know if I’m relying on some sort of undefined behavior

In some sense, the entire Types as Macros approach is "undefined
behavior" :/ because we are using the expander for unintended
purposes. So thank you (and William and everyone else that has tried
it out) for diving in and helping us figure out what works and what
needs more work.

But now that we've shown that such an approach is both viable and
wanted by Racket programmers, for the rough parts where we cannot find
a good solution, the next step might be to address these issues with
contributions to the expander itself.

Just to throw them out there, other issues that I'm working on (in
addition to scopes on stx props) are:
- Better support (over stop lists) for "delimited" expansion. For
example, I often want to "fully expand an expression, but not past a
specified language".
- Better support for expanding expressions with free identifiers in a context.
- Better support for mapping stx objs back to the surface stx, in a
hygienic way.

On Wed, Dec 14, 2016 at 6:50 PM, Alexis King  wrote:
>> On Dec 14, 2016, at 7:14 AM, Matthew Flatt  wrote:
>>
>> To summarize, don't try to attach syntax objects as property values
>> like that. I know this advice sounds ironic, given that the original
>> use of properties was for syntax-valued keys like 'origin. Properties
>> like 'origin are meant to be extracted from just-expanded programs,
>> though, as opposed to used in a later compilation step. At the same
>> time, those uses of properties are why we can't just make
>> `syntax-property` reject property values that are syntax objects.
>
> What are the implications of this for the Types as Macros/Turnstile
> stuff that Stephen and Alex have been working on, given that they
> use heavily use syntax objects in syntax properties as part of
> attaching type information to identifiers? Are they doing something
> to work around this and/or using properties in a way that avoids
> this issue? Or is it likely that they’ll run into this for programs
> that span multiple modules?
>
> (Obviously, I have a personal motive for asking this question, since
> I’ve been playing with Turnstile and the techniques it uses myself.
> So far I’ve been able to write programs that span multiple modules
> without much issue, modulo an issue I asked about on this mailing
> list a month or two back, but I’d like to know if I’m relying on
> some sort of undefined behavior.)
>
> --
> 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] Operations that create objects

[NeverTooOldToCode]

Racket Reference section 1.1.5 states: "Operations that create objects, such as 
vector, add to the set of objects" followed by a nice and instructive 
step-by-step evaluation example. Further on, lambda is used as another example 
of an operation creating an object.

How can I tell which operations create objects?

-- 
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-property lost across module boundary (WAS: format-id doesn't preserve preserved?-edness of syntax-property?)

[Dupéron Georges]

Le jeudi 15 décembre 2016 00:48:13 UTC+1, Alexis King a écrit :
> without much issue, modulo an issue I asked about on this mailing
> list a month or two back

Here's (what I suspect is) the thread Alexis mentions, for those who feel 
curious: https://groups.google.com/forum/#!topic/racket-users/TGax2h8dVxs 
(Identifier equality of identifiers stashed in preserved syntax properties).

-- 
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] Extracting the body of a fully-expanded module (with submodules)

[Dupéron Georges]

Thanks Matthew!

Your solution seems to work fine, the trampoline idea is a very neat trick. I 
like how it's safe to use require and begin because the continue macro returns 
fully-expanded syntax which won't be affected by the code injected around (for 
some reason I thought it was necessary to only inject fully-expanded forms like 
#%require, but that assumption was wrong).

I'd like to read more about the shifting of "relative" module references, is 
there anything in the docs about it (I vaguely remember seeing something, but 
couldn't find it again)?

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