Re: [racket-dev] Racket on Rockets

2011-07-28 Thread Noel Welsh
On Wed, Jul 27, 2011 at 9:20 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:

 Would it be fair to say that were such a thing to come into existence,
 the VM would need to be changed as part of that work?

There is nothing you can't do with a brave heart and a disassembler.
In other words, I've occasionally thought it would be fun to write a
generic object inspector via abuse of the FFI.

N.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket on Rockets

2011-07-28 Thread Noel Welsh
On Tue, Jul 26, 2011 at 6:20 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 I was recently telling some people that I thought 'Ruby on Rails' was
 mostly an ORM plus a set of default dispatching rules with convenient
 ways of extending the defaults.

I agree, though I don't have much RoR experience. However, that isn't
where the action is in web frameworks these days. My opinion is that
it resides in two areas:

 1. rich clients -- that is, interfaces that use a lot of
Javascript. Here FRP within the browser and between the browser and
server would be a big win. Interesting to stuff to look at: Opa,
WebSharper, (and Javascript frameworks like backbone.js, and the Scala
reactive project, etc.)

 2. Scalable servers like https://github.com/jdegoes/blueeyes

Both could be addressed from Racket. I'm not convinced it really has
the computing horsepower to do a bang-up job for #2 (certainly it has
the abstractions) but then neither does Node.js and that doesn't stop
Node's extremely active supporters.

N.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket on Rockets

2011-07-28 Thread Sam Tobin-Hochstadt
On Jul 28, 2011 7:26 AM, Noel Welsh noelwe...@gmail.com wrote:

 On Wed, Jul 27, 2011 at 9:20 PM, Tony Garnock-Jones to...@ccs.neu.edu
wrote:

  Would it be fair to say that were such a thing to come into existence,
  the VM would need to be changed as part of that work?

 There is nothing you can't do with a brave heart and a disassembler.
 In other words, I've occasionally thought it would be fun to write a
 generic object inspector via abuse of the FFI.

Certainly. That's how the disassembler I wrote works.  It's not a stable
solution, but it is effective.

sam th
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 12:21 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 On 2011-07-26 1:20 PM, Jay McCarthy wrote:
 I don't have a lot of expertise on the ORM side, but I think Snooze
 would probably be awesome and my MongoDB-backed structs may be helpful
 too.

 Is there a way of generically traversing all structure in a completely
 privileged way in Racket, without programming at the VM level? For
 example, one might wish to serialize some arbitrary data structure or
 write an object inspector or interactive debugger.

If you have a sufficiently powerful inspector, you can traverse any
structure.  In principle, you can even traverse closures this way, but
no inspector with the needed power exists.  See `struct-vector'.

 I'm guessing no is the answer, based on the existence of separate
 serializable and non-serializable structure definitions. I guess
 that if I were to try it out I'd be defeated by opaque closures and by
 the inspector mechanism. Does that sound right?

 Regards,
  Tony
 _
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev




-- 
sam th
sa...@ccs.neu.edu

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Tony Garnock-Jones
On 2011-07-27 4:01 PM, Sam Tobin-Hochstadt wrote:
 If you have a sufficiently powerful inspector, you can traverse any
 structure.  In principle, you can even traverse closures this way, but
 no inspector with the needed power exists.  See `struct-vector'.

That sounds fantastic! Especially the traversal of closures. What kinds
of dark alchemy would I have to engage in to get hold of the necessary
inspector?

Would such an inspector be able to represent the structure of chaperoned
and impersonated values accurately?

Finally, what about the other direction? I notice there's no obvious
`vector-struct`. Is there a general way of moving from the description
of a structure to the structure itself?

Regards,
  Tony
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 On 2011-07-27 4:01 PM, Sam Tobin-Hochstadt wrote:
 If you have a sufficiently powerful inspector, you can traverse any
 structure.  In principle, you can even traverse closures this way, but
 no inspector with the needed power exists.  See `struct-vector'.

 That sounds fantastic! Especially the traversal of closures. What kinds
 of dark alchemy would I have to engage in to get hold of the necessary
 inspector?

No such alchemy exists, it's just intended as part of the conceptual framework.

 Would such an inspector be able to represent the structure of chaperoned
 and impersonated values accurately?

No, `struct-vector' uses the chaperoned accessors, but doesn't
represent their structure.

 Finally, what about the other direction? I notice there's no obvious
 `vector-struct`. Is there a general way of moving from the description
 of a structure to the structure itself?

No.
-- 
sam th
sa...@ccs.neu.edu

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Tony Garnock-Jones
On 2011-07-27 4:17 PM, Sam Tobin-Hochstadt wrote:
 No such alchemy exists, it's just intended as part of the conceptual 
 framework.

Would it be fair to say that were such a thing to come into existence,
the VM would need to be changed as part of that work?

 No, `struct-vector' uses the chaperoned accessors, but doesn't
 represent their structure.

OK. And there's nothing else that can expose that structure?

 No.

OK.

Thanks,
  Tony
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Carl Eastlund
On Wed, Jul 27, 2011 at 4:17 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
 On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 On 2011-07-27 4:01 PM, Sam Tobin-Hochstadt wrote:
 If you have a sufficiently powerful inspector, you can traverse any
 structure.  In principle, you can even traverse closures this way, but
 no inspector with the needed power exists.  See `struct-vector'.

 That sounds fantastic! Especially the traversal of closures. What kinds
 of dark alchemy would I have to engage in to get hold of the necessary
 inspector?

 No such alchemy exists, it's just intended as part of the conceptual 
 framework.

 Would such an inspector be able to represent the structure of chaperoned
 and impersonated values accurately?

 No, `struct-vector' uses the chaperoned accessors, but doesn't
 represent their structure.

 Finally, what about the other direction? I notice there's no obvious
 `vector-struct`. Is there a general way of moving from the description
 of a structure to the structure itself?

 No.

There is struct-type-make-constructor; if you have the inspector for
the structure, you can get at its structure type as well.

--Carl

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 1:20 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 On 2011-07-27 4:17 PM, Sam Tobin-Hochstadt wrote:
 No such alchemy exists, it's just intended as part of the conceptual 
 framework.

 Would it be fair to say that were such a thing to come into existence,
 the VM would need to be changed as part of that work?

Yes.

 No, `struct-vector' uses the chaperoned accessors, but doesn't
 represent their structure.

 OK. And there's nothing else that can expose that structure?

Right.

-- 
sam th
sa...@ccs.neu.edu
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


[racket-dev] Racket on Rockets

2011-07-26 Thread Jay McCarthy
I was recently telling some people that I thought 'Ruby on Rails' was
mostly an ORM plus a set of default dispatching rules with convenient
ways of extending the defaults.

I don't have a lot of expertise on the ORM side, but I think Snooze
would probably be awesome and my MongoDB-backed structs may be helpful
too.

On the side of default dispatching rules, I've made a little demo:

https://github.com/jeapostrophe/exp/tree/master/ror

[For the demo, the ORM is just hash tables of structs.]

This program:

#lang racket/base
(require ror.rkt)

(blast-off!
 [posts (title body)])

is an incredibly generic blog where you can see all the posts, add
new ones, and edit old ones. It sets up a slew of un-hygienic names
and allows you to override them to replace default behavior.

This program uses that overriding feature to replace the top-level index:

#lang racket/base
(require web-server/servlet
 ror.rkt)

(define (post-render id)
  (define obj (hash-ref *posts* id))
  `(div (h2 ,(posts-title obj))
,(posts-body obj)))

(define (index req)
  (response/xexpr
   `(html
 (head (title My Racket on Rockets blog))
 (body
  (h1 My Racket on Rockets blog)
  ,@(for/list ([last-post-n (in-range 5)])
  (define post-id (- (hash-count *posts*) (add1 last-post-n)))
  (if (negative? post-id)
  '(div)
  (post-render post-id)))
  (p (a ([href ,(to-url posts-new)]) New Post)  
 (a ([href ,(to-url posts-index)]) All Posts))

(blast-off!
 [posts (title body)])

You could also define posts-new or posts-index to control the
corresponding default functions.

In case what I had in mind wasn't clear... I hope this is.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev