[erlang-questions] ANNOUNCE: adapter_pattern for mochiweb/cowboy/misult and scripting language

[Michael Turner]

"IMHO a DOM object is a data structure (term) ..."

But in the browser, a DOM object represents something that's
*happening*, even if what's "happening" appears to us as a static
display in a browser window. When you delve into what's happening in
the hardware in order to make the right photons spray out toward your
retina from any given point, you find out there's a lot going on. You
can tell the DOM object to make something different happen, just by
changing the values in it. Ontologically, that makes it a process. And
(I would say) an object in Alan Kay's original sense:

 http://erlang.2086793.n4.nabble.com/Erlang-quot-object-oriented-quot-after-all-td2101240.html

So why not represent the state of that object as the arguments to a
tail-recursive function that waits for messages and sends messages? At
least as a first cut?

"... therefore I would be more interested in composable abstraction
over these terms, much like a parser abstracts over concrete syntax."

I understand the appeal of that, but ... parsers have the luxury of
chomping through a meal that sits still. You can make rules about how
morsels should be arranged on the plate. As soon as you go dynamic,
you've got things crawling around on your plate -- possibly capable of
reproduction as well. You're sending programs, and programs can write
programs. You're back to how we compose "abstractions" in
Turning-complete programming languages, and your composability is
defined by little more than the grammar of the language -- which can't
really tell you much about what's happening when a program runs, or
else we'd have algorithms that solve the Halting Problem.

Anyway, if you want the ultimate in composable abstraction for the
web, something "much like a grammar," don't you end up back at
XML/XSLT?

-michael turner


On Tue, Feb 21, 2012 at 5:48 AM, Jakob Praher <jakob@REDACTED> wrote:
> Am 20.02.12 19:51, schrieb Fredrik Svahn:
>>> To me, the most natural Erlang representation of a DOM object is the
>>> same as for any "object": it's an Erlang process. Now, I can't have an
>>> Erlang process in the browser itself (unless someone writes a web
>>> browser in Erlang, or implements Erlang in the browser[*]). But I
>>> *can* have Erlang processes on the server side, to interrogate and
>>> update page state as if its corresponding DOM objects were all Erlang
>>> processes.
>> Actually, in the version of browserl[1] I checked in a week ago, a DOM
>> object is a (pseudo-)process. At one point it was even possible to
>> send messages to it (e.g. to request an update) but that doesn't work
>> any longer. I might revisit the idea later if/when I get the time.
>
> IMHO a DOM object is a data structure (term) therefore I would be more
> interested in composable abstraction over these terms, much like a
> parser abstracts over concrete syntax.
>
> But if we are at it: How would you model a browser, if you could write
> it in Erlang?  To me a browser could be described as a hierarchical term
> storage process (the document) plus a render process that creates
> controls owned by the window. Terms are updated through the storage and
> it is the rendering process that presents the udpates to the user.
> Controls would be process nodes under the window that again change terms
> in the storage. Only the owning window is allowed to access the term
> storage, making it possible to have mulitple windows with private term
> storages.
>
> The term storage process could even be a protected distributed process
> that can be shared between the client and server side. If the server
> sends passes mutating messages to the storage process, the client can
> directly reflect these.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions