Re: [racket-dev] Racket on Rockets

2011-07-28 Thread Sam Tobin-Hochstadt
On Jul 28, 2011 7:26 AM, "Noel Welsh"  wrote:
>
> On Wed, Jul 27, 2011 at 9:20 PM, Tony Garnock-Jones 
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-28 Thread Noel Welsh
On Tue, Jul 26, 2011 at 6:20 PM, Jay McCarthy  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 Noel Welsh
On Wed, Jul 27, 2011 at 9:20 PM, Tony Garnock-Jones  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-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 1:20 PM, Tony Garnock-Jones  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


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Carl Eastlund
On Wed, Jul 27, 2011 at 4:17 PM, Sam Tobin-Hochstadt  wrote:
> On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones  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 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 Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones  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: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 12:21 PM, Tony Garnock-Jones  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-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.

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


[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 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

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