gmane.lisp.scheme.plt

Re: Cleanup on Servlet Timeout (Again)

Noel Welsh — 2008-08-21T16:20:11

We've had bad experiences with timeout based servlets. I would use the LRU manager, and implement my own timeouts. This way you can send a "timeout" events to your database process and tell it to release all locks. Hopefully that help; I'm not sure I'm fully understood your problem. N. _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Re: Cleanup on Servlet Timeout (Again)

Matthew Flatt — 2008-08-21T15:58:54

Forget locks. Make a process that's in charge of the resource. [The process is effectively an implementation of a readers+writer lock, but this characterization is probably useful only if you're trained to think in terms of locks instead of processes. The key is that you get to implement the "lock" instead of trying to juggle primitive locks.] The process representing the resource accepts reader requests and lets them run them in parallel; when a reader asks to become a writer, then the managing process waits for all the other readers to finish before granting the conversion; if there's already a pending writer, then all new writer-conversion requests are rejected. The process can see when a reader/writer terminates, and it can adjust accordingly. The enclosed "rwlock.ss" illustrates this implementation. Depending on the domain, though, there's one more problem beyond granting read and write access in a kill-safe way. What if a thread is terminated while it's in write mode? The "rwlock.ss" implemen

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Eli Barzilay — 2008-08-21T05:26:31

Yes. And I still prefer the implicit side-effect over the explicit one. Even back in the days where we were happily mutating pairs, I still considered (define foo* (set-cdr! (last-pair foo) foo)) to be a hack. A slightly better way to achieve this would be (define foo* (append! foo foo)) becuase it's clearer what kind of short-circuiting it makes, and the actual side-effect that is needed to implement it is not for me to worry. A better way, when possible, is (define foo* '#0=(1 2 3 . #0#)) except that it's very rare to need a circular list of literals, so it's almost never useful. But what beats all of these by an order of magnitude is: (define foo* (letrec ([foo* (append foo foo*)]) foo*)) I can get *some* of that functionality with `shared', but not everything. The best I can do is: (require lazy/force) (define (cycle l) (!! (letrec ([c (lazy (append l c))]) c))) The bottom line is that there are certain kinds of well-behaved circular references that the language can do by its

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Woodhouse Gregory — 2008-08-21T04:27:14

_________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Joe Marshall — 2008-08-21T04:25:43

Eli, what's wrong with you?! Are you sure you're feeling ok? The thing I *really* want is for there to be a subset of Scheme that supports pure functional programming where it is obvious, by cursory inspection, that there are no side effects. No explicit calls to SET! (or set-car!, rplaca, etc.) means no side effects period. R5RS didn't have this because it required letrec to expand into let + set! whether it needed it or not. I was hoping that R6RS would improve on this by at least *allowing* an implementation to use a fixed-point if possible. The more I program, the more I get the feeling that the case against side effects is vastly understated even by the people that object the most to them.

Re: Define-scope

Woodhouse Gregory — 2008-08-21T02:52:06

_________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Cleanup on Servlet Timeout (Again)

Henk Boom — 2008-08-21T02:48:55

A while ago I started a thread on the automatic releasing of resource locks on servlet termination in the web server: http://list.cs.brown.edu/pipermail/plt-scheme/2008-July/026121.html The problem is that individual threads acquire read/write locks on the database, but they may be terminated at any time due to timeout. In the worst case, a thread with a write lock is terminated, and then no other threads can get a read lock until the web server is restarted. Robby pointed me to a paper on implementing kill-safe shared resources: http://www.cs.utah.edu/plt/kill-safe/ Now that I finally have time to devote to this, I've taken a look. lock lasts only for the duration of your call to the resource. In my case, my database monitor has the following interface: (call-as-retryable-job thunk) Waits to acquire a read lock and runs the thunk. Returns the result of the thunk. Releases any read/write locks obtained when returning. (aquire-write-lock) Called only within a thunk given to call-as-retryable-job. Tries

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Eli Barzilay — 2008-08-21T02:41:03

(negated Amen). Not only do I like not doing an explicit side effect -- I'd go further and merge the `shared' functionality into `letrec', just to make it *really* usable for data too.

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Eli Barzilay — 2008-08-21T02:32:54

At least in PLT, internal definitions were always done with a `letrec*', or more accurately, mzscheme's `letrec' is actually a `letrec*'. IIRC, ages ago there used to be a `letrec*' binding which was identical to `letrec'. It's still pretty simple. Continuations have a bad habit of exposing all kinds of implementation details as happened at the beginning of this thread. It doesn't matter, because there are no first class continuation, (and because of the restriction on what you can put in the rhs of `letrec's). And BTW, OCaml's `let rec' is still inconvenient, it often forces you to put the whole file in a single such form -- if there's a function at the top that needs to call a function at the bottom. And personally I found that to be very disturbing, since I'd try to move just the calling function down, but that might drag others too. In general you get a general topological sort problem to solve, and if in the end you find that you really need mutually recursive functions then either you work t

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Michael Vanier — 2008-08-21T02:22:15

Excellent, thanks! Mike _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Matthew Flatt — 2008-08-21T02:18:44

R6RS implementations provide `letrec*'. FWIW, PLT Scheme's `letrec' corresponds to R6RS's `letrec*'. http://docs.plt-scheme.org/reference/syntax-model.html#(part._fully-expanded) Matthew _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Michael Vanier — 2008-08-21T02:05:23

Jumping in here... I wasn't aware that "letrec" was defined in terms of its let/set! semantics (though I knew that it could be so defined). I had always assumed that it was a primitive. To muddy the waters further, I believe that R6RS says that internal defines are actually translated into "letrec*", even though I don't know of any Scheme implementation that actually supports "letrec*". It's all a big mess. I also hate it wrt teaching, because SICP, for instance, describes define to have very simple semantics, but this isn't at all what internal defines really do (I'm guessing that the reason for this is that implementing internal defines in terms of some letrec or let/set! primitives is easier to optimize). So users expect that internal defines behave in ways similar to top-level defines, which they do not. This significantly undercuts the argument that Scheme is a "simple, elegant" language. I don't know of a good way out, either. I kind of like the Ocaml model where there are exactl

Define-scope

Pham Dinh Khai — 2008-08-20T14:08:14

Hi there, I'm Khai, I am studing DrScheme language. Could you help me to define the meaning of scope in programming global - variables local - parameters, local variables and local environments I uderstand these aspects but i don't know how to define in words hope to hear from you soon thanks, Khai _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Joe Marshall — 2008-08-20T20:11:24

Local makes me ill. It's bad enough that the top level doesn't have the same semantics as internal define, but that's a compromise due to the interactive nature of top level. It's worse to promote that behavior to internal define as well. On Wed, Aug 20, 2008 at 12:51 PM, Shriram Krishnamurthi public.gmane.org> wrote: Yes. ----- But.... Who would I object to? And why would anyone care what I thought? If the semantics of internal define changed enough that the code I write stopped working, I'd just write an explicit letrec or I'd write a macro that made it work right again. I'd certainly not make it the default in my own implementation, but if you have a portable macro you are free to do what you will.

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Joe Marshall — 2008-08-20T20:03:37

On Wed, Aug 20, 2008 at 12:44 PM, Abdulaziz Ghuloum public.gmane.org> wrote: It's better than raising an exception because returning to an continuation doesn't necessarily mean your program is broken. If your program doesn't try to do anything `funny' with the bindings, then it shouldn't notice or care if they are re-assigned or rebound and there is no reason to raise an exception. (In other words, I could write a program that worked perfectly well on your compiler and didn't depend on whether things were rebound or re-assigned, yet it wouldn't work at all on someone else's compiler because they raise an exception. (But it *would* work if they were lazy enough not to check.) Or alternatively, someone could perversely depend on that exception and discover it didn't happen on your compiler. Not often. It may be a habit I picked up from working in Common Lisp where you don't have letrec (you have labels, which only allows function binding). It's trivial enough

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Shriram Krishnamurthi — 2008-08-20T19:51:07

If LOCAL had a slightly less onerous syntax (the current syntax meets one need superbly, but at the cost of some syntactic pain for people writing a fresh LOCAL expression from scratch), would you object to it supplanting LETREC? S. _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Abdulaziz Ghuloum — 2008-08-20T19:44:21

On Aug 20, 2008, at 11:27 AM, Joe Marshall wrote: This is precisely what I do in my compiler. How is this better than raising an exception? (Note, Ikarus does not raise such exceptions, so, it is far less work for me and far more efficient for Ikarus to not introduce these checks for programs that return more than once to an , but I still don't see that choosing to rebind or to assign depending on the implementation's choice is better than raising an exception) No! Any restriction like that invalidates way too many valid and perfectly good programs that I do write all the time. I can't say the same. For example, I consider parameters (i.e., the result of calling make-parameter), record accessors, mutators, constructors, etc., to be procedures even if they're obtained by procedural means (from non-lambda expressions). This is a simple sequence of definitions: (define make-adder (lambda (n) (lambda (m) (+ n m)))) (define add1 (make-adder 1)) Do you never write code like this? I agr

Re: scheme in java

Shriram Krishnamurthi — 2008-08-20T19:38:29

Because you'd need to CPS, and that really destroys program structure and potentially also performance. See: http://www.cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-cont-from-gen-stack-insp/ S. On Wed, Aug 20, 2008 at 9:39 AM, Grant Rettke public.gmane.org> wrote: _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Joe Marshall — 2008-08-20T18:33:24

I don't consider that a big loss. It's trivial to change this to either (define (f x) (let ((local-var (add1 x))) (define (do-stuff . args) ...) ;; if you refer to local-var freely in here (do-stuff x local-var))) or (define (f x) (define (do-stuff . args) ...) ;; if local-var is not used in here (let ((local-var (add1 x))) (do-stuff x local-var))) The ability to write mutally-recursive programs in a side-effect free subset of the language. What precisely are we losing by allowing arbitrary expresions on the right hand side?

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Matthias Felleisen — 2008-08-20T18:33:31

On Aug 20, 2008, at 2:27 PM, Joe Marshall wrote: Amen. _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Re: about letrec and continuation : which behavior iscorrect ? and why ?

Joe Marshall — 2008-08-20T18:27:56

On Wed, Aug 20, 2008 at 8:20 AM, Abdulaziz Ghuloum public.gmane.org> wrote: The thing that I thought was a wart was that letrec was *required* to expand as if it were a let followed by a set even in cases where it could have been accomplished by a fixed-point computation. You are forced to be inelegant even when you don't need to be. Option 4: An implementation *may* implement letrec as a binding followed by an assignment, or it *may* implement letrec as a fixed point, or it *may* mix the two. Returning to an continuation may cause re-assignment or rebinding at the discretion of the implementation. Alternatively, the right hand side of the letrec could be restricted. I rarely use letrec (or internal define) for arbitrary values. I almost always use letrec (or internal define) for procedures only. If this were the case, then you'd have to explicitly have a side effect in the code above: (let ((x (list #f))) (set-car! x (lambda () x)) (eq? x ((car x))))