Parser Generator that generates JavaScript code

[Peter Michaux]

Hi,

Does a parser generator exist that generates JavaScript code? Most
parser generators generate C or Java code.

Thanks,
Peter

 

[Daz]

Hi,

Does a parser generator exist that generates JavaScript code? Most
parser generators generate C or Java code.

Thanks,
Peter

What is it meant to generate the code from, exactly?

 

[Peter Michaux]

What is it meant to generate the code from, exactly?

A language grammer similar to that used by Yacc, JavaCC, SableCC or
Lemon.

A subset of SQL grammer is what I would like to implement in
JavaScript.

Peter

 

[Daz]

A language grammer similar to that used by Yacc, JavaCC, SableCC or
Lemon.

A subset of SQL grammer is what I would like to implement in
JavaScript.

Oh I see. Sorry I am not familiar with parser generators. I assumed you
meant something that will basically take some code, parse it, and then
display it on a webpage complete with syntax highlighting. I am
intrigued as to the the use of such parser generators, so I am going to
look into it. I will let you know if I come across anything.

All the best.

Daz.

 

[Daz]

A language grammer similar to that used by Yacc, JavaCC, SableCC or
Lemon.

A subset of SQL grammer is what I would like to implement in
JavaScript.

Peter

Hello again Peter. I have just tried a Google search for what you are
looking for, and out of the hundred or so pages that were returned,
there's nothing that matches the description of what you are looking
for. I beleive it would be safe to assume that such a thing doesn't
exist, or if such a thing does exist, it's probably so little known
that it does not work correctly, or is seriously buggy. This doesn't
mean that this is definitely the case, but as you rightly said, Google
practically throws C and Java parser generators at you, but there
doesn't appear to be any that work with JavaScript. Sorry...

Daz.

 

[VK]

A subset of SQL grammer is what I would like to implement in
JavaScript.

<http://trimpath.com/project/wiki/TrimQuery>

 

[Peter Michaux]

<http://trimpath.com/project/wiki/TrimQuery>

I found some fundamental flaws that will break TrimQuery in
unacceptable ways. For example a user cannot store "Mr SELECT test" as
their name in the in-browser database. There could be hack work arounds
for each of these problems but I think doing it right with a tokenizer
and parser are probably more fruitful in the long run.

Peter

 

[Peter Michaux]

Great zot! Trimpath extends Javascript with SQL queries! It's a
lightweight GPL open-source component that gives you the power of SQL
queries while running Javascript in a web browser. Written in Javascript.

I was just as excited when I saw it the first time. A DBMS in only 600
lines of JavaScript. I think it is too good to be true and some
investigation into the code has shown it too have problems. The idea of
a DBMS certainly could happen in a browser but is it a good idea?

A DBMS in the browser is appealing but I am conflicted about the
appropriateness of such a beast. How much thinking should a browser be
able to do? It seems like a slippery slope where the desire for a
little bit of cool DHTML could lead to way too much browser brains. For
example, in a DHTML data grid if the user can filter which rows are
visible or in which order they appear then custom code has to slowly be
written to manipulate the data. When the number of user options for
data filtering and sorting increases enough it would be better just to
write something like TrimQuery. With the innocent wish to sort a list
now download times have increased with more data and libraries to be
cached in the browser.

It looks like Gmail leaves all sorting, filtering and pagination up to
the server since the server has all the tools needed like a DBMS to
program this quickly. This also keeps individual page load times low. I
would not make sense to load 20 000 emails into my browser just so I
can search through them quickly. However when there are only 30 items
of data and only a few sort options then people want to delegate the
responsibility to the browser. Where is the line? It seems
fundamentally wrong to give the browser so much power but I don't know
how to articulate clearly when the line has been crossed. Perhaps it
is in the grey area.

There is also the problem of distrubuted data that needs to be
syncronized with the server data and what conflicts that might occur.

I think Gmail got this right.

This is primarily why I started the other thread called "The future of
applications in JavaScript?" I don't know if moving in the direction of
TrimQuery-type applications is a good idea or not. If it is a good idea
than we need more traditional software development tools like a parser
generator for developing JavaScript apps.

Peter

 

[George3]

I don't know if moving in the direction of
TrimQuery-type applications is a good idea or not. If it is a good idea
than we need more traditional software development tools like a parser
generator for developing JavaScript apps.

It seems things are moving in the direction of providing more
storage/db functionality in the browser - see Mozilla's Database API
(embeds SQLite for extensions/chrome app use - although not webpages):
http://developer.mozilla.org/en/docs/Storage
and also WHATWG DOM storage (for webpages to access):
http://www.whatwg.org/specs/web-apps/current-work/#scs-client-side