> http://docs.racket-lang.org/txexpr/
Hoo-ray! splitf-xexpr is *exactly* what I needed. Thank you for your help!
--
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
> On Dec 13, 2016, at 17:17, Robby Findler wrote:
>
> The phase1/phase2 stuff isn't really for preference initialization.
> You should be able to just do it when the module require'd (ie at its
> toplevl) or when the tool@ unit is invoked. Either phase would also be
At Wed, 14 Dec 2016 18:12:52 -0800 (PST), Dupéron Georges wrote:
> Hello!
>
> This is a follow-up to the excellent answer by Alex Knauth on StackOverflow
> here: http://stackoverflow.com/a/38032107/324969 and this mailing-list
> thread:
>
On Wed, Dec 14, 2016 at 03:50:28PM -0800, Alexis King wrote:
> What are the implications of this for the Types as Macros/Turnstile
...
>
> (Obviously, I have a personal motive for asking this question, since
Based on the names of functions in my example, you'd never guess how I ran into
this
Hello!
This is a follow-up to the excellent answer by Alex Knauth on StackOverflow
here: http://stackoverflow.com/a/38032107/324969 and this mailing-list thread:
https://groups.google.com/forum/#!topic/racket-users/sS-pUUGp9o4
I'm trying to write a module meta-language mylang, which accepts a
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
> 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
I think it could be possible to avoid those printfs but only because
the contracts used here are flat, but the implementation of ->i
doesn't do that specialization. In the general case, the contract on
each of the depended on arguments (x and y in this case) have to be
applied twice, once to catch
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
On Thursday, December 15, 2016 at 12:04:23 AM UTC+1, Lehi Toskin wrote:
> I have some XML - rather, XMP data from an image - that I'd like to mess
> around with. I've investigated the xml library and found that I can turn the
> XML into an XEXPR so I can play around with it like that and even
I have some XML - rather, XMP data from an image - that I'd like to mess around
with. I've investigated the xml library and found that I can turn the XML into
an XEXPR so I can play around with it like that and even search through it with
se-path*/list, but how would I go from there to
On Wednesday, December 14, 2016 at 12:19:51 PM UTC-5, Prabhakar Ragde wrote:
>
> I am developing such a course for a spring term (May-August) offering at
> the University of Waterloo (though it will probably use OCaml). There
> does not appear to be an ideal textbook; I plan to synthesize
At Wed, 14 Dec 2016 10:43:34 -0700, Matthew Flatt wrote:
> But right now, as Sam well knows
I'd like to clarify that this is because Sam has been very helpful in
making things better --- not that he's been asking for new things.
--
You received this message because you are subscribed to the
Yes, it's obviously easier to implement this new feature with the new
expander.
But right now, as Sam well knows, I'm open to patches only as long as
they make things no slower and no bigger. :) The current implementation
is reliably within a factor of 2 of the old one, but we're still
working to
> On Dec 14, 2016, at 9:19 AM, Prabhakar Ragde wrote:
>
> Lawrence Bottorff wrote:
>
>> Can someone suggest a good text for data structures that would
>> compatible with Racket? All I see are treatments using C/C++, Java,
>> Python, i.e., the usual suspects. Or, how do
Lawrence Bottorff wrote:
Can someone suggest a good text for data structures that would
compatible with Racket? All I see are treatments using C/C++, Java,
Python, i.e., the usual suspects. Or, how do you people at
Racket-friendly/based universities teach undergrad data structures?
I am
> On Dec 14, 2016, at 10:23 AM, Sam Tobin-Hochstadt
> wrote:
>
> On Wed, Dec 14, 2016 at 10:14 AM, Matthew Flatt wrote:
>> More generally, changes to the scope of a
>> syntax object are not propagated to property values that happen to be
>> themselves
On Wed, Dec 14, 2016 at 10:14 AM, Matthew Flatt wrote:
> 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
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
Hello group,
I have inspected things.
And upon careful println debugging (around mzssl.rkt:760), ended up running:
mkdir -p home/mflatt/build/bl/l64/dest/ssl/
wget -O /home/mflatt/build/bl/l64/dest/ssl/cert.pem
http://curl.haxx.se/ca/cacert.pem
Which actually fixed the raco install. I guess
"Pearls of Functional Algorithm Design"
https://www.amazon.com/Pearls-Functional-Algorithm-Design-Richard/dp/0521513383/ref=sr_1_1
The functional "programming pearls" in Haskell, but the author prefers the
term "algorithm design".
On Wed, Dec 14, 2016 at 2:48 AM, Ben Greenman
21 matches
Mail list logo