|
|
|
|
Re: Extend javascript grammer [message #756025 is a reply to message #755958] |
Thu, 10 November 2011 13:56 |
Henrik Lindberg Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
On 11/10/11 11:29 AM, Zeeshan Safder wrote:
> Thanks henrick for your honest suggestions. Javascript is not my choice.
> I have given task to write a strong grammer and intellesence for the
> language based on javascript. Is there any better tool other than xtext
> or I have to go with it?
Anyway you try this, you will have a hard time. JS is dynamically typed,
and the language is not context free (you don't know what something
means until the value is known), many constructs have quirky resolution
that are only known to the runtime implementation.
If you aim for a sane subset of JS, you can probably pull it off with
Xtext. However since JS is very dynamic in nature there is not much
opportunity to do "intellisense" as "you can try anything, you will
either get what was expected or a surprise".
It is only in a debugger all values/"types" are known, but not before
they are evaluated.
You would need quite fancy static analysis of the JS code to collect
information.
> I have to start it yet, and you are already showing me dark outcome,
> just a joke ;)
>
Sorry. I wasted several weeks on a JS approach. Just warning you.
> Anyhow is there any better tool for it? I am also searching about
> jseclipse tool meanwhile...
You can use antrl, or some other parser generator technology. You will
need to write the rest yourself. You can look at the DLTK project's
support for various dynamic languages as inspiration. Can't combine that
with Xtext though.
You should really convince those that stated the JS requirement that you
will be far better off with an Xtext implementation and use Xbase. It is
clean, statically typed with type inference to reduce clutter,
interpreter, code generation, works out of the box, etc. etc. Will make
you a lot more productive (several orders of magnitude IMO), and let you
focus on the extensions rather than engaging in yakshaving a very furry
JS-yak ;) - just saying.
I can reccomend Sven's blog post "Dear Java killers,"
http://blog.efftinge.de/2011/04/dear-java-killers.html
- henrik
|
|
|
|
Re: Extend javascript grammer [message #756122 is a reply to message #756121] |
Fri, 11 November 2011 05:37 |
Zeeshan Safder Messages: 27 Registered: November 2011 |
Junior Member |
|
|
I think I need to explain my custom language a bit. It named ngCore and they try to make it close to OOP. We are playing with classes (the objects). And it extends from other classes. My task is now actually write intellesence for it. When I typed 'this.' it should show all class and its base classes attribtues.
[Updated on: Fri, 11 November 2011 07:00] Report message to a moderator
|
|
|
Re: Extend javascript grammer [message #756177 is a reply to message #756122] |
Fri, 11 November 2011 11:58 |
Henrik Lindberg Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
On 11/11/11 6:37 AM, Zeeshan Safder wrote:
> I think I need to explain my custom language a bit. It named ngCore and
> they try to make it close to OOP.
You talked earlier about JavaScript, if ngCore is "java script like" it
does not really say much about how difficult it is.
The only way to know is to describe its grammar and the semantics.
> We are playing with classes (the
> objects). And it extends from other classes. My task is now actually
> write intellesence for it. When I 'this.' it should show all class and
> it base classes methods.
With a good grammar for a well behaved language, Xtext will generate
much of the "intellisense" (code completion, proposals, linking,
navigation, etc.) for you.
I suggest you start with some examples, and experiment with that to get
a basic understanding of the various features provided by Xtext. Don't
start with a full blown grammar of ngCore as your very first attempt.
Once you have familiarized yourself with Xtext's features start your
ngCore grammar with the terminals and the smallest possible part of the
language. Make that work before adding more complex constructs.
This approach makes it possible to understand what causes errors when
generating the grammar. If you write it all at once, you will most
likely be overwhelmed by the error output, and it is very difficult to
figure out "cause and effect" (and it is time consuming for others to
help you).
When you work in stepwise fashion, it makes it possible to ask concrete
questions about details and you are more likely to get help. It is
simply not possible to answer "How do I write good 'intellisense' for my
Javascript like language 'ngCore'" with anything but, "Make a good
implementation" :)
So, go ahead, jump in, start with one of the examples.
Regards
- henrik
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03569 seconds