[racket-users] "Contracts can have significant overhead" but Typed Racket cannot?
I'm not sure what the qualitative distinction is between contracts and Typed Racket. They seem like two syntaxes for what mostly amount to the same thing. Is it just a matter of implementation, or perhaps what their developers focus on? You could in theory read through a list of contracts, and of the contracts that guarantee the operation you want on the data you have, pick the most efficient one. And that's what Typed Racket does for the most part, I thought. Is it just that the algorithm for doing that with contracts hasn't been written, so Typed Racket can't take advantage of it? Is it that contracts are more general, not always necessarily contracts of functions that operate on types? /Does/ Typed Racket actually have significant overhead, when compiling perhaps? If not, would that overhead they mentioned about contracts be eliminated if those contracts were only utilized to decide what function to use, and not checked every time that function is called? Just something that was puzzling me in the documentation. -- You 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: how to transform syntax post-expansion?
On Monday, February 15, 2016 at 5:43:38 PM UTC, Ryan Culpepper wrote: > The macro should use `local-expand` rather than `expand`. See the docs > for `local-expand`, since it takes more arguments. I would guess you > probably want to pass along `(syntax-local-context)` and use an empty > stop list. Oh, awesome! I'll look into that, thanks! -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] (eqv? Racket-land Wonderland) -> #t
On Monday, February 15, 2016 at 8:50:31 PM UTC, Matthew Butterick wrote: > https://en.wikipedia.org/wiki/Blue_Flame_(automobile) Oh, that's beautiful. -- You 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: (eqv? Racket-land Wonderland) -> #t
On Monday, February 15, 2016 at 3:29:23 PM UTC, Neil Van Dyke wrote: > Nota Poin wrote on 02/15/2016 05:40 AM: > You seem to be itemizing complaints that come to your mind, Sorry, I shouldn't have been complaining. > but I don't > see how all of them are responding to the question you quoted, of "how > is it that such Wonderland is not discovered by much more people?" I was trying to help him empathize with why people might be turned off to the language. I know I've spent many nights in ear bleeding frustration trying to deal with some of these problems. > For example, this sounds like you're arguing against high-level > languages in general, Languages in general suck, it's true. I was arguing against them as a way to show that the answer to the question why "nobody" knows about Racket has not a simple answer. "Racket has problem A, which people don't like. Except everything else does too, so I dunno." > It's abstract, optimized at runtime, > inscrutable, not what you think it is, rewritten, transformed magic? Uh > huh, I'm just gonna go call a function in C thanks." java bytecode is anything but inscrutable. There have even been decompilers written for it, as much as developers have tried to push them out of existence. It's basically assembly language, with instructions that need translation for a given platform. If you want to claim that Racket isn't the only language with crazy underlying runtime optimization that nobody really understands, pypy is a good example of that. It translates every possible python statement into C, compiles them, and then uses those bits of machine code to JIT new python code as loaded, which is freaking insane. You know how long it takes to compile C code for every possible logical pathway in python code? > In language forums, people have mixed feelings about posts that are a > laundry list of complaints. Sorry if I upset you. I'm not always in the most pleasant of moods. > Someone more industrious than me might later today try to address the > complaints one-by-one Oh, please don't. They're poorly thought out opinions, and even if any manage to be valid and vitally important to address, you can rationalize anything, so people will address them just to show us all why bad is actually good, and we're the ones who are wrong, not the language or implementation. https://www.youtube.com/watch?v=rbfd75YRG34 (Don't blame the controller!) -- You 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: (eqv? Racket-land Wonderland) -> #t
On Saturday, February 13, 2016 at 5:35:09 PM UTC, Saša Janiška wrote: > So, at the end I just wonder how is it that such Wonderland is not > discovered by much more people? Startup is slow. Intractable problem, JIT compiling just takes time, and can't be cached beforehand. Like with pypy vs cpython, efficient JIT means more number crunching at startup. When people are willing to throw out optimal code for fast startup, maybe racket can support that, but it isn't exactly a high priority. Complex flexible syntax means even compiled code takes longer to JIT than say for instance java bytecode. Big requirements. Lots of memory, lots of CPU. Not a viable target for embedded systems or mobile devices. Takes forever to compile. At least it's not spending 80% of the compilation anymore, creating that massive javascript blob that they call "documentation". Not such a problem on systems where it's already compiled, but some people actually like open source. Too many ways to do core things. Do you want to use the foof-loop macro? cl-loop? for? for/fold? foldl? (let loop ([arg arg]))? ((lambda (boing arg) (boing boing arg)) (lambda (next arg) ...) arg)? (define (recurse arg) (recurse arg arg))? When you take a simple example and try to customize it to your needs, more often than not (I at least) end up buried in pages of fiddling with the guts of the algorithm, because as soon as you depart from the norm it quickly becomes overwhelmingly complex as you expose the innards of whatever system you're trying to adapt to your needs. Too pedantic. This isn't hygenic! That's not allowed! More often than not it's saving you from screwing up, but with errors like "permission denied" and "bad syntax" it feels like you're being chided by a 70 year old librarian. At least it's not as bad as java. Lots of full on phrases, when typing abbreviations would be easier. (require (only-in a b)) vs "from a import b" or "import a: b" Racket is a _lot_ better at that lately. It used to have things like (eval) didn't work, because there was no %app syntax transformer by default, because that would be correct, as opposed to what anybody actually wants. You can actually throw away hygiene without a lot of horrible overrides, and it's better at intuiting just what you mean by turning datum into syntax. Not bare metal enough. Not because of speed, but because of barriers to understanding. Okay, so a computer is a bunch of switches, and some switches turn others on or off. Cool, and that's how you make an adder circuit. Now what switches will make a lambda? It's abstract, optimized at runtime, inscrutable, not what you think it is, rewritten, transformed magic? Uh huh, I'm just gonna go call a function in C thanks. Too meta. Flexible syntax is awesome for simplifying and compartmentalizing logic, but when you have syntax that produces syntax it gets harder to understand just what you're doing. People don't realize this, so write lots of crazy racket code that throws away first order functions for the "faster" syntax transformations when the former would work fine and not leave people at a loss to figure what the letters you typed are supposed to do. Too powerful. It's a language that can define new languages from whole cloth. It's a compiler of compilers. It's like trying to use a jet engine to propel your tricycle. Too interdependent. Writer of cool module A sees cool module B, uses that, which uses cool module C, which uses D, E and F, etc. It's not as bad as perl, and not nearly as bad as C++, but reducing module interdependency, at the cost of redundant code, is a slow process to get right. Continuations are slower than jumps. Can't implement the latter with the former, since you always have to be ready to capture the current continuation. Racket's one of the best schemes at fast continuations, but every scheme except bigloo (which cops out by disabling continuations) faces the problem that "create a closure, and jump" is more expensive than "jump." -- You 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: how to transform syntax post-expansion?
On Monday, February 15, 2016 at 4:07:53 AM UTC, Nota Poin wrote: > (define-syntax (transform-post-expansion stx) > (syntax-case (expand stx) () > (...))) Right, expand the syntax to expand the syntax... that'll work out great... -- You 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: how to transform syntax post-expansion?
I suppose I could do something like this: (define-syntax (transform-post-expansion stx) (syntax-case (expand stx) () (...))) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] how to transform syntax post-expansion?
I was trying to transform the syntax produced by an (include/...) statement, specifically (include/text) from scribble/text. But when I did this: (transform (include "somefile.scribble")) it transformed the syntax #'(include "somefile.scribble"), not the syntax produced from its expansion. I'm really hoping I don't have to do this: (eval #`(transform #,@(include/text "somefile.scribble")) Should I do like... (transform (expand (include/text "somefile.scribble"))) or... how would I transform what some syntax expanded into, rather than what it started out as? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] splicing conditional results in the surrounding block?
On Thursday, February 11, 2016 at 12:29:04 PM UTC, Neil Van Dyke wrote: > http://www.neilvandyke.org/racket-html-template/ This does almost exactly what I was thinking about! Looking at the code makes me go cross-eyed, but if you (expand-once #'(html-template ...)) enough, it turns the SXML tree structure into a linear sequence of (write-bytes) statements. It would definitely be possible to instead generate a linear sequence of strings, that could be cached and then possibly written with one single (write-bytes). Certainly not worth the trouble, but possible. And very fascinating! -- You 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] splicing conditional results in the surrounding block?
On Friday, February 12, 2016 at 1:26:05 AM UTC, Matthew Butterick wrote:
> Of course, you can also use the `at-exp` metalanguage from Scribble to
> simplify text-heavy constructions like these, with variables interpolated
> into strings:
> #lang at-exp racket
>
> (define (query condA condB (limit #f) (offset #f))
> @~a{SELECT something FROM table WHERE @condA AND @condB @(if limit
>@~a{LIMIT
> @limit @(if offset
>
>@~a{OFFSET @offset}
>
>"")}
>"")})
I could also do this:
(define (query condA condB (limit #f) (offset #f))
(flatten
(list "SELECT something FROM table WHERE "
condA
" AND "
condB
(if limit
(list "LIMIT " limit
(if offset
(list "OFFSET " offset)
'()))
'(
at-exp really is a fascinating language, but if a (flatten) isn't any more
computationally expensive, you can just splice all the lists at the end and use
the regular racket language. Either way would work fine, I suspect.
--
You 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] splicing conditional results in the surrounding block?
I run into this problem a lot whenever I'm generating some text. I'll be making what amounts to a sequence of strings being appended, and do something like this: (apply string-append (list "" something "")) Compared to un-parsing a representation of a document tree every single time, simplifying document production down to a bunch of string concatenations is pretty efficient. The problem happens when I introduce conditionals, like this: (list "" (if prev (list "Prev") '()) (if next (list "Next") '()) "") Now I no longer have a sequence of strings, but instead a nested list of strings. Then I usually call (apply string-append (flatten list-of-strings)) and don't worry about it, but it'd be even cooler if I could proactively flatten it. (if prev (if next (list "" "Prev" "next" "") (list "" "Prev" "")) (if next (list "" "next" "") (list "" ""))) Obviously that's horrible code, since I don't want to type the surrounding stuff for every possible logic pathway in my code. But it'd be relatively simple to concatenate whatever the result is! I guess what I'm asking is how would I take code like this: (list "" (splicing-if prev (splicing-list "Prev") nada) (splicing-if next (splicing-list "Next") nada) "") ...and have the result inherently be a flat list of strings? Not a complex tree that I then have to walk with (flatten), but genuinely just a list of strings? Something with (reset) and (shift) maybe? Something with (and-let)? To make this happen, would I have to instrument the conditionals like (if)? Would I have to instrument the (list) forms that they result in? Obviously if my conditionals produce simple strings it's easy: (list "things: " (if thing1 thing1 "") (if (and thing1 thing2) " and " "") (if thing2 thing2 "")) Even that is kind of cludgy though, because the "" fallthrough results in lists like (list "things: " thing1 "" "") instead of the ideal: (list "things: " thing1) One possible solution is to use mutable variables and shared state. (ugh) (write "") (when prev (write "Prev")) (when next (write "Next")) (write "") Another thing I've tried is concatenations of concatenations: (apply string-append "" (if prev (string-append "Prev") "") (if next (string-append "Next") "") "") That of course scatters fallthrough "" strings in the calculation, and since it calls string-append multiple times, the implementation can't exactly allocate the result all at once, and must spend more time fooling around with memory. Creating strings, only to destroy them as soon as they've been appended to the larger string. But there's no way I've ever been able to figure to produce generated text that is just a flat list of strings, if I ever want to have conditional decisions about what to go in that list. -- You 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] splicing conditional results in the surrounding block?
On Thursday, February 11, 2016 at 9:08:33 AM UTC-8, Matthew Butterick wrote: > I'm supposing you know that Racket has at least two native representations > (X-expression and SXML) for HTML-like structures, so hacking HTML tags by > hand is unnecessary. Yes, thank you for mentioning them. I was actually thinking of starting with SXML, but then turning it into a list of string fragments (with spaces left for the dynamically generated parts) as a simplification step once I've figured out where everything goes. But there are other languages besides HTML this is relevant for. (define (query condA condB (limit #f) (offset #f)) (list "SELECT something FROM table WHERE " condA " AND " condB (if limit (list "LIMIT " limit (if offset (list "OFFSET " offset) '())) '( for instance. > But if you must, there's a #lang for that: I'll look at scribble/text, but I don't think a whole new language is necessary just to factor if-statements inside out. I suspect it does a (flatten) operation though, after having constructed a complex tree, since this problem seems like a difficult one, and (flatten) really isn't all that much trouble. I was just curious if it was possible to do this, but if I had to get scribble/text ready to release to the masses I'd just throw a (flatten) in there to splice the lists. > Enjoy. No problem! -- You 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: splicing conditional results in the surrounding block?
I guess this transformation is what I'm looking for: (transform (list stuff ... (if test (list yes ...) (list no ...)) more ...)) => (if test (transform (list stuff ... yes ... more ...)) (transform (list stuff ... no ... more ...))) but of course you can't put anything after the ... in the same list in a syntax-rules pattern, not to mention there's no indication which ellipses correspond to what. I don't know how flattening using syntax-rules is even possible... -- You 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] send-generic vs send
I don't really get what generics are. What is the difference between this: (define show (generic window<%> show)) (send-generic a-window show #t) and this: (send a-window show #t) If the former re...uses the (generic window<%> show) method to be "more" efficient, then why isn't show already a generic, and why don't we have (send) always use generics? Is it just that (send) existed before generics? -- You 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] cannot produce units from syntax transformers
I'm not sure why, but this works: (unit (import foo^) (export bar^) (+ foo bar))) while this fails: (define-syntax-rule (asyn body ...) (unit (import foo^) (export bar^) body ...)) (asyn (+ foo bar)) with the error "unit: undefined export" for any imported variables. Somehow the (unit...) form is tied to the physical source location that it's written in, so if a syntax transformer tries to introduce a unit syntax, when the new syntax is used, the unit will consider the body spliced into it to be outside of it, since the body has a different source location than the actual definition of the syntax transformer itself. Is there any way to work around this? I don't necessarily want to rely on units, so I made a general syntax that would let me swap them out according to my specific use of them, like (with-that-stuff etc ...) instead of (unit (import that-stuff^) (export) etc ...). But that doesn't work, because for no reason I can fathom, the etc... part gets evaluated before it gets spliced in, even though define-syntax says it gets spliced in before evaluation. -- You 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] cannot produce units from syntax transformers
On Saturday, November 28, 2015 at 11:24:28 PM UTC, Matthew Flatt wrote: > That is, `import` is a binding form, just like `let`. Oh, that makes sense. So it gets swapped in the macro for a hygenic named variable, and the ones I pass by that name don't get swapped in the same fashion, thus aren't bound. Maybe I'll try your non-hygenic thing. I could also just (define-syntax-rule (asyn imp^ body ...) (unit (import imp^) (export) body ...)) ...or something. Probably not be very useful, since you might as well use the unit syntax if you're going to be specifying imports and exports with every invocation. I like your non-hygenic solution better. Which is to say I don't like it, but heck if I know a better way to make things that create a unit of one single specific signature. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] How to get information about where an error occurs, in a stack trace context?
I'll have code like this: #lang racket/base (define (baz foo) (error 'whoops)) (define (bar ber) (baz ber)) (define (foo ber) (let ((a 3)) (if (and (= a 3) (= (* a 9) 27) (bar ber) (list? (list 1 2 3 4))) ber (not ber (foo 42) And I get an error message like this: error: whoops context...: /extra/user/code/racket-stack.rkt: [running body] That doesn't show the line number on which the error occurred, or even the location of the expression being evaluated. For a custom error, I could just grep through the code for "whoops", but for say an error like "string-append: contract violation" I may have many uses of string-append, and I might not be able to debug them if I can't tell what context they're being being evaluated in. How do I enable uh, "working" stack traces? --no-jit just removes stack traces entirely. -W debug says the functions are being inlined, but doesn't debug info for the inlining specify what function was inlined? racket has no debug flag that I can find. Setting --disable-inline in raco and running the bytecode produces no information in the stack trace either. Sometimes (unpredictably AFAIK) I do get /some/ line information, but it's at most the function that the error happened in, not the error itself which could be anywhere inside it or any inlined function. $ racket -V Welcome to Racket v6.2.1. Please tell me I'm not gonna have to say Guido was right... -- You 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] How to get information about where an error occurs, in a stack trace context?
On Monday, November 9, 2015 at 1:38:56 AM UTC, Matthias Felleisen wrote: > Use drracket. Yeah, I would, but it takes about 30 seconds to start up if I disable all the extensions, add another 10 or 20 for the debugger, and then when I type it lags behind at about 0.25s per character. Also it consumes huge amounts of memory, and that seems to increase without bounds if you leave it open. > Or if you insist on command line usage, use error trace. What's wrong with command line usage? Anyway, I was going to say this: http://docs.racket-lang.org/errortrace/using-errortrace.html That seems to enable stack traces that work. -- You 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: racket users fight for their right to colon keywords
On Monday, November 9, 2015 at 3:17:59 AM UTC, Neil Van Dyke wrote: > Note that, unlike some languages, I *don't* want `x` and `y` to be > optionally positional -- only keyworded. In my opinion, supplying a default value should make an argument implicitly keywordable. So (define (a b c (d 3) (e 4)) ...) would have 2 required positional arguments, and d and e could be present or omitted. If an argument has a default, it means it should be possible to omit it, and if you cannot specify keywords for the arguments after it (with defaults) then you cannot omit it. That leads to things like this: (define (foo a b (c #f) (d null) (e null))) (list a b c d e)) (let ((e '(1 2 3))) (list (foo 1 2 #f null e) (foo 1 2 #f null '(2 3 4)) (foo 1 2 #f e e) (foo 1 2 #f e))) Notice how in all cases the "optional" argument c had to be explicitly specified with its own default value. That is confusing because people can't tell if you mean "just ignore this and use the default" or "I really do think it important that c have this value." So, optional /non-keywordable/ arguments are a bad idea, in my opinion. Being able to do something like this is very important for clarity: (let ((e '(1 2 3))) (list (foo 1 2 :e e) (foo 1 2 :e '(2 3 4)) (foo 1 2 :d e :e e) (foo 1 2 :d e))) I don't have a real preference whether d and e should be allowed to be /positional/ though. It seems reasonable that it might be confusing to go (a 1 2 3 4) where either 3 or 4 are optional arguments with defaults if omitted. A case-lambda would be the best form if you really want (a 1 2) (a 1 2 3) and (a 1 2 3 4). But on the other hand, it doesn't seem too bad, as long as I have the option of specifying those optional arguments as keywords. But I don't have that option, because I have to say "#:keyword-argument (keyword-argument default)" or it doesn't /let/ me use a keyword to specify that argument's value. That leads to me being forced to boilerplate in defaults for intermediary optional variables. So, that's my big beef with the lambda/define syntax. -- You 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
On Wednesday, October 14, 2015 at 12:30:54 AM UTC, Daniel Feltey wrote: > Some of the verbosity of units can be reduced using the "inference" features > that Racket's unit system provides. Hmm, I gave it a shot, and this seems to work. Not sure if it'd be especially useful. But fwiw -- You 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-dynamic-unit-oops.scm Description: Binary data
Re: [racket-users] Long-term Runtime session state
On Tuesday, October 13, 2015 at 11:40:12 PM UTC, Alexis King wrote: > Have you taken a look at parameters? Short answer: yes. Long answer: they're convenient thread-local globals, but still feel like globals to me. (define a (make-parameter 0)) (define (called-at-hopefully-regular-intervals) (a (+ (a) 1)) (define (something-stupid) (let ((b (a))) (totally-innocuous-event-loop) (+ 3 b b b))) A local variable session doesn't require me to for the internal implementation, write a bunch of abstraction-rich difficult-to-optimize inscrutable state code, whereas with parameters I always have to (call) them just in case their value just changed. It's like parameters force the internal stuff to use the careful, externally exposed interface to access their own internal data. -- You 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
On Tuesday, October 13, 2015 at 11:40:12 PM UTC, Alexis King wrote: > units Oh uh, conceivably you could have "code" that provided a live session object on linking, and handled session refreshing internally, then just link that with units that have session dependant code. I just never found any good docs on how to do that. Near as I can tell, runtime linking of a unit is even MORE verbose and persnickety than just manually typing in all the procedures you want to pass to a callback. -- You 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.
