| Author |
Message |
|
| Guest |
 Posted: Mon Jul 16, 2007 12:48 pm |
 |
|
|
Guest
|
On 7/16/07, Joe Armstrong <erlang@gmail.com> wrote:
> I have on occasion thought that it would be fun to implement Javascript.
>
> The idea of having lot's of little javascripts running in process and
> message parsing
> would be fun.
>
> The first step would be a simple interpretor - from that the compiler
> is easy 
>
> The difficulty of wring an interpretor seems mainly to do with getting
> an accurate
> parse tree of the js source into Erlang - the interpretor should be pretty easy.
>
> So now I wonder "how can I get a parse tree of some javascript" - Ideally
> there would be a javascript-parser-in-javascript that produced a JSON
> parse tree.
>
> If such a parser exists please tell me where to find it !!
Take a look at Narcissus:
http://en.wikipedia.org/wiki/Narcissus_(JavaScript_engine)
-bob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Jul 16, 2007 2:50 pm |
|
|
|
Guest
|
Joe Armstrong wrote:
> The difficulty of wring an interpretor seems mainly to do with getting
> an accurate
> parse tree of the js source into Erlang - the interpretor should be pretty
easy.
So, for me, who is new to Erlang and thought about it on my drive home last
Friday, is this the right approach to the implementation: have a separate
process for each object and lexical environment. An object is then
represented as a PID, and requests for properties and methods (which are
basically the same in Javascript), would send a message to the process,
which would return the appropriate value (which may also be an object/PID)
or function. Nested lexical environments (e.g., with blocks, function
blocks, and the global environment), therefore, can send forward a request
to their higher level if the value is not found in their environment.
Am I on the right track?
Cheers,
David
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Jul 16, 2007 7:42 pm |
|
|
|
Guest
|
Joel Reymont wrote:
> This is the reason I asked.
>
> Think scalable web development for the masses.
>
> In Javascript.
>
> On top of Erlang.
Not meaning to discourage any effort here - a JS implementation in
erlang might be an interesting project and have some uses, and as others
have pointed out implementing languages is fun - the goal of "... for
the masses" is misguided. Syntax isn't the problem - if it was, we'd
all be programming in COBOL. Sure, erlang syntax is a little different,
but its the programming philosophy that is alot different, and putting a
javascript face on that isn't going to make it any more accessible.
Unless you're going to be able to accurately translate idiomatic
javascript into idiomatic erlang you're going to have an erlang program
that uses a single process with no message passing, no exception
handling, no matching, etc., and then it really isn't erlang anymore.
-J
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Jul 16, 2007 8:08 pm |
|
|
|
Guest
|
On 7/16/07, Jeff Rogers <dvrsn@diphi.com> wrote:
> Joel Reymont wrote:
> > This is the reason I asked.
> >
> > Think scalable web development for the masses.
> >
> > In Javascript.
> >
> > On top of Erlang.
>
> Not meaning to discourage any effort here - a JS implementation in
> erlang might be an interesting project and have some uses, and as others
> have pointed out implementing languages is fun - the goal of "... for
> the masses" is misguided. Syntax isn't the problem - if it was, we'd
> all be programming in COBOL. Sure, erlang syntax is a little different,
> but its the programming philosophy that is alot different, and putting a
> javascript face on that isn't going to make it any more accessible.
> Unless you're going to be able to accurately translate idiomatic
> javascript into idiomatic erlang you're going to have an erlang program
> that uses a single process with no message passing, no exception
> handling, no matching, etc., and then it really isn't erlang anymore.
That argument only makes sense if you're talking about writing whole
programs in JavaScript and then compiling them down to Erlang.
Syntax is definitely a problem in certain contexts, and embedding a
language in Erlang (one way or another) is an obvious solution to
that. In the JavaScript case you're probably going to be having lots
of little JS interpreters all over the place (e.g. one per HTTP
request) so the imperative nature of how idiomatic JS works isn't
really a big deal. They're all isolated from one another, and you've
got plenty of them.
-bob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Jul 16, 2007 10:54 pm |
|
|
|
Guest
|
> The next alternative would be to find a yacc grammar for javascript
> and put this into yecc
> but I suspect this would be out-of-sync with real javascript.
>
> Failing that it's back to the ECMA-262 spec ( I suppose) and try to
> convert the
> grammar in the appendices to something sensible.
I started some time ago to convert the LR(1) given on mozilla website
(http://www.mozilla.org/js/language/grammar14.html) to a yeec one.
I also use robert's leex module for the scanner.
The problem is that my compiler courses are far away, so I resurrected my
"red dragon" book to refresh my memory.
I manage to parse a simple javascript file with a function declaration, and
produce the AST tree for that. Okay, nothing really astonishing
I only roughly converted only a part of the grammar, and didn't managed the
{normal, initial} and {allowIn, noIn} grammar arguments for now. I resolved
one shift/reduce problem, but I'm not sure I did it the good way. That why I
have to revise my lessons on grammar, It's more a patch than anything else.
Denis
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 17, 2007 2:41 am |
|
|
|
Guest
|
Douglas Crockford (original author of the JSON format) has a chapter in Beautiful Code (his chapter is online at http://javascript.crockford.com/tdop/tdop.html) which develops a simple Pratt parser for a reasonable subset of javascript.
Crawford writes about javascript generally...
"We don't have time in this short chapter to deal with the whole JavaScript language, and perhaps we wouldn't want to because the language is a mess. But it has some brilliant stuff in it that is well worth consideration. We will build a parser that can process Simplified JavaScript. We will write the parser in Simplified JavaScript. Simplified JavaScript is just the good stuff..."
So perhaps a Pratt parser in Erlang would be useful, if one doesn't exist yet. And so developing a parser for Simplified Javascript would be a good starting point.
Perhaps the implementation should stop at this subset, and so encourage it's widespread adoption just as Crawford stopped with the subset of Javascript data and called that "JSON"?
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 17, 2007 4:42 am |
|
|
|
Guest
|
> which develops a simple Pratt parser for a reasonable subset of javascript.
BTW someone (Joel? Joe?) suggested using JSON as the parse tree might be helpful.
The Pratt parser I just mentioned by Douglas Crawford parses Simplified Javascript into an almost-JSON parse tree. The difference is that the keys are symbols rather than strings.
So it would be a trivial change to make the parse tree true JSON. Then a bootstrap would be fairly simple -- write the interpreter in Erlang to take the parse tree in JSON and execute it.
Then writing a Pratt parser in Erlang would be unnecessary as Crawford's parser is itself written in Simplified Javascript. As long as the speed was acceptable.
Of course the next step would be to write a translator from the JSON parse tree into Erlang, and there'd be a Simplified Javascript *compiler* for Erlang.
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 17, 2007 7:32 am |
|
|
|
Guest
|
Thanks - I found the narcissus code.
Then I built the stand-alone version of spidermonkey - and tried to load the
narcissus code into the stand-alone spidermoney and ... nothing
happened. It just
sat staring at me like an underfed cat and refused to purr.
I read (well skimmed) the code for the javascript-in-javascript parser.
This is neat code and not the kind of stuff you write after having read the
first few chapters of the Dragon book. It's a mix of a lexer, a
recursive descent parser
and a operator precedence parser - all rolled together into a single file.
Since it's a meta-interpreter I've no idea if the code is even correct
and if it computes
the same values as the embedded js interpreters.
So the problem of a parser still remains - I suspect the easiest way
is to make a library from spidermonkey and use the C parser, and hack
this to dump the parse tree in
a suitable form. Embedding spidermonkey in Erlang would have the added
advantage of
making any new js interpreter/compiler easy to test - just by running
the same function in
the real interpreter and in the Erlang version.
/Joe
On 7/16/07, Bob Ippolito <bob@redivi.com> wrote:
> On 7/16/07, Joe Armstrong <erlang@gmail.com> wrote:
> > I have on occasion thought that it would be fun to implement Javascript.
> >
> > The idea of having lot's of little javascripts running in process and
> > message parsing
> > would be fun.
> >
> > The first step would be a simple interpretor - from that the compiler
> > is easy
> >
> > The difficulty of wring an interpretor seems mainly to do with getting
> > an accurate
> > parse tree of the js source into Erlang - the interpretor should be pretty easy.
> >
> > So now I wonder "how can I get a parse tree of some javascript" - Ideally
> > there would be a javascript-parser-in-javascript that produced a JSON
> > parse tree.
> >
> > If such a parser exists please tell me where to find it !!
>
> Take a look at Narcissus:
> http://en.wikipedia.org/wiki/Narcissus_(JavaScript_engine)
>
> -bob
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 17, 2007 7:42 am |
|
|
|
Guest
|
All little more digging revealed this to be a "Pratt parser" - I also found a
simplified js parser at http://javascript.crockford.com/tdop/index.html.
Things are looking up.
Now I need to find a decent description of Pratt's parser.
/Joe
On 7/17/07, Joe Armstrong <erlang@gmail.com> wrote:
> Thanks - I found the narcissus code.
>
> Then I built the stand-alone version of spidermonkey - and tried to load the
> narcissus code into the stand-alone spidermoney and ... nothing
> happened. It just
> sat staring at me like an underfed cat and refused to purr.
>
> I read (well skimmed) the code for the javascript-in-javascript parser.
>
> This is neat code and not the kind of stuff you write after having read the
> first few chapters of the Dragon book. It's a mix of a lexer, a
> recursive descent parser
> and a operator precedence parser - all rolled together into a single file.
>
> Since it's a meta-interpreter I've no idea if the code is even correct
> and if it computes
> the same values as the embedded js interpreters.
>
> So the problem of a parser still remains - I suspect the easiest way
> is to make a library from spidermonkey and use the C parser, and hack
> this to dump the parse tree in
> a suitable form. Embedding spidermonkey in Erlang would have the added
> advantage of
> making any new js interpreter/compiler easy to test - just by running
> the same function in
> the real interpreter and in the Erlang version.
>
> /Joe
>
>
>
>
> On 7/16/07, Bob Ippolito <bob@redivi.com> wrote:
> > On 7/16/07, Joe Armstrong <erlang@gmail.com> wrote:
> > > I have on occasion thought that it would be fun to implement Javascript.
> > >
> > > The idea of having lot's of little javascripts running in process and
> > > message parsing
> > > would be fun.
> > >
> > > The first step would be a simple interpretor - from that the compiler
> > > is easy
> > >
> > > The difficulty of wring an interpretor seems mainly to do with getting
> > > an accurate
> > > parse tree of the js source into Erlang - the interpretor should be pretty easy.
> > >
> > > So now I wonder "how can I get a parse tree of some javascript" - Ideally
> > > there would be a javascript-parser-in-javascript that produced a JSON
> > > parse tree.
> > >
> > > If such a parser exists please tell me where to find it !!
> >
> > Take a look at Narcissus:
> > http://en.wikipedia.org/wiki/Narcissus_(JavaScript_engine)
> >
> > -bob
> >
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 17, 2007 3:56 pm |
|
|
|
Guest
|
Also, how would you handle garbage collection of the Javascript objects?
DBM
-----Original Message-----
From: David Mercer [mailto:dmercer@gmail.com]
Sent: Monday, July 16, 2007 09:40
To: 'erlang-questions@erlang.org'
Subject: RE: [erlang-questions] JavaScript compiler for Erlang
Joe Armstrong wrote:
> The difficulty of wring an interpretor seems mainly to do with getting
> an accurate
> parse tree of the js source into Erlang - the interpretor should be pretty
easy.
So, for me, who is new to Erlang and thought about it on my drive home last
Friday, is this the right approach to the implementation: have a separate
process for each object and lexical environment. An object is then
represented as a PID, and requests for properties and methods (which are
basically the same in Javascript), would send a message to the process,
which would return the appropriate value (which may also be an object/PID)
or function. Nested lexical environments (e.g., with blocks, function
blocks, and the global environment), therefore, can send forward a request
to their higher level if the value is not found in their environment.
Am I on the right track?
Cheers,
David
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 17, 2007 4:58 pm |
|
|
|
Guest
|
Am Mon, 16 Jul 2007 10:35:49 +0200 hat
"Joe Armstrong" <erlang@gmail.com> geschrieben:
> I have on occasion thought that it would be fun to
>implement Javascript.
You should be aware of
http://lambda-the-ultimate.org/node/1784
Specifying ECMAScript via ML
(Sorry, if somebody posted this already)
Regards,
Marc
>
> The idea of having lot's of little javascripts running
>in process and
> message parsing
> would be fun.
>
> The first step would be a simple interpretor - from that
>the compiler
> is easy
>
> The difficulty of wring an interpretor seems mainly to
>do with getting
> an accurate
> parse tree of the js source into Erlang - the
>interpretor should be pretty easy.
>
> So now I wonder "how can I get a parse tree of some
>javascript" - Ideally
> there would be a javascript-parser-in-javascript that
>produced a JSON
> parse tree.
>
> If such a parser exists please tell me where to find it
>!!
>
>Failing this I guess the easiest approach is to take
>spidermonkey make
> the stand-alone
> version and fix the parser to dump the parse tree in
>some suitable
> format. Unfortunately
> I suspect that spidermonkey make C data structures
>suitable for
> compiling/interpreting
> rather than parse trees as such.
>
> The next alternative would be to find a yacc grammar for
>javascript
> and put this into yecc
> but I suspect this would be out-of-sync with real
>javascript.
>
>Failing that it's back to the ECMA-262 spec ( I suppose)
>and try to convert the
> grammar in the appendices to something sensible.
>
> In projects like this I always think that writing an
>accurate parser
> is the tricky bit.
>
> /Joe
>
>
>
>
> On 7/14/07, Joel Reymont <joelr1@gmail.com> wrote:
>> This is the reason I asked.
>>
>> Think scalable web development for the masses.
>>
>> In Javascript.
>>
>> On top of Erlang.
>>
>> On Jul 13, 2007, at 8:11 PM, denis wrote:
>>
>> > We are building an infrastructure allowing giving some
>>services to our
>> > users. But external developers (same company, but
>>other teams)
>> > could build
>> > their own custom services inside the infrastructure.
>>Having these
>> > new users
>> > to learn a new language to build a custom services
>>(which can be quite
>> > simple) can be badly perceived.
>>
>> --
>> http://topdog.cc - EasyLanguage to C# compiler
>> http://wagerlabs.com - Blog
>>
>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| rvirding |
| Posted: Wed Jul 18, 2007 8:22 pm |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
With the garbage collector of course! Sorry couldn't resist that.
I am in no way a js guru. How fine are js objects? I know Erlang
processes are lightweight but are they lightweight enough? Would you get
problems with implicit/explicit sequentiality in js? Otherwise just keep
them in a table.
Still thinking about doing PHP, there are an awful lot of applications.
Someone asked earlier which versions we are thinking about. At this
stage I would say the latest version for which I can get a decent
description of the language and main libraries. It doesn't matter that
much until you get users who would actually want to use it.
Robert
David Mercer wrote:
> Also, how would you handle garbage collection of the Javascript objects?
>
> DBM
>
> -----Original Message-----
> From: David Mercer [mailto:dmercer@gmail.com]
> Sent: Monday, July 16, 2007 09:40
> To: 'erlang-questions@erlang.org'
> Subject: RE: [erlang-questions] JavaScript compiler for Erlang
>
> Joe Armstrong wrote:
>> The difficulty of wring an interpretor seems mainly to do with getting
>> an accurate
>> parse tree of the js source into Erlang - the interpretor should be pretty
> easy.
>
> So, for me, who is new to Erlang and thought about it on my drive home last
> Friday, is this the right approach to the implementation: have a separate
> process for each object and lexical environment. An object is then
> represented as a PID, and requests for properties and methods (which are
> basically the same in Javascript), would send a message to the process,
> which would return the appropriate value (which may also be an object/PID)
> or function. Nested lexical environments (e.g., with blocks, function
> blocks, and the global environment), therefore, can send forward a request
> to their higher level if the value is not found in their environment.
>
> Am I on the right track?
>
> Cheers,
>
> David
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
   
|
| wuji |
| Posted: Tue Aug 14, 2012 6:49 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
of a U.S. horseracing track denied allegations Monday that that jordan 6 that the chief of Mexico's most violent drug cartel had
a $1 million race so his own horse would win.According win.According imitation designer *beep* win.According to two confidential FBI informants, Zetas leader Miguel Angel
Morales, also known as "40," bragged that he had paid paid jordan 6 olympic 2012 paid the gatekeepers at New Mexico's Ruidoso Downs $10,000 "to
back the horses" competing against his own horse, Mr. Piloto, Piloto, replica designer *beep* Piloto, in the 2010 All American Futurity Race, which Mr.
won.Trevino Morales and 13 other defendants were indicted last week week [h3]imitation designer *beep*[/h3] week for allegedly laundering at least $20 million in cocaine
through horse racing, breeding and training in the U.S. The The [h3]jordan 6s[/h3] The informants' claims were part of an affidavit filed in
of a search warrant for an Oklahoma horse ranch allegedly allegedly [h4]cheap jordans[/h4] allegedly owned by a Zetas front corporation.Shaun Hubbard, general manager |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
