Future of Frege editors/IDEs

[Ingo W.]

It turned out that the eclipse plugin is starting to experience problems with newer eclipse versions.

I guess I can fix it for this time. But it will probably happen again and again.

Here is a list of options I see:

1. Stay with the successor of IMP. Pro: low effort. Contra: This seems to be a one man show.
2. Wrte an eclipse plugin from scratch, using latest Eclipse technology. Pro: future-proof. Contra: who can do this? 
3. Wrte an IDEA plugin from scratch, using latest Eclipse technology. Pro: future-proof. Contra: who can do this? 
4. Wrte a NetBeans plugin from scratch, using latest Eclipse technology. Pro: ???. Contra: who can do this? Who uses NetBeans anyway?
5. Roll your own in FregeFX. Pro: Dierk has the know how. Stand alone product. Contra: stand-alone product 
6. Use ATOM or something like that. Pro: attract the cool kids. Contra: would need indirect interfacing with compiler (i.e. via pipes or sockets). Could be cool, though, once we had it.

Non-options:

Use emacs.

(Haha, I'm joking. But then I'd prefer VIM)

[zjhsdtc]

i want try idea plugin from scratch

--
You received this message because you are subscribed to the Google Groups "Frege Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to frege-programming-l...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Federico Tomassetti]

I have written Eclipse plugins in the past and I am now writing an
IntelliJ IDEA Plugin. In my opinion it is more difficult to write Idea
plugins: the API is very powerful but intricate and there are not as
many examples as for Eclipse. On the other end the people the people
on Jetbrains forums are more reactive.
One think that really helped me was re-using code from the ANTLR
Plugin for IntelliJ: basically they wrote an adapter from ANTLR
generated grammars to the lexer and parser formats expected by IDEA.
The lexer IDEA expects has to produce tokens also for whitespace and
comments, it could be rolled back, it could be invoked on a subset of
the whole file, etc., so it is not so easy to create.
Auto-completion for IDEA is great and so it is support for
auto-refactoring. It is very much Java-oriented and I am not sure how
much that could be a problem for Frege.

I would be happy to help a little with the IDEA plugin because I would
love to improve in that area but I definitely could not lead the
development of it.

For people interested a good starting point is here:
http://www.jetbrains.org/intellij/sdk/docs/tutorials/custom_language_support_tutorial.html

Cheers,
Federico

> --
> You received this message because you are subscribed to the Google Groups
> "Frege Programming Language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to frege-programming-l...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Website at http://tomassetti.me
GitHub https://github.com/ftomassetti

[Ingo W.]

Well, we can't reuse Java refactoring and code completion anyway.

Regarding the lexer, it already recognises comments. It also knows the offsets and length of each token. So one can simply fill the gaps with whitespace tokens, if that is needed.

However, the lexer alone doesn't provide enough information for more than most basic syntax colouring. For example, it can't tell if a name is a name space, type class, type constructor or data constructor. It also doesn't know if that name is imported from another module.

Anyway, if we can form a working group, I'll be happy to take part or at least assist.

For me, it would be helpful to have a skeleton, where all the boilerplate for the various features is done and I could just fill in the Frege specific code.

The feature list should not be less ambitious than what we have in the eclipse plugin, and possibly more.

[Walter Chang]

how about something like this https://github.com/ensime/ensime-server ?  ensime server contains all the relevant core logic for an scala ide and editors like emacs, vim and sublime can hook into it with minimum effort.

--
You received this message because you are subscribed to the Google Groups "Frege Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to frege-programming-l...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

.......__o
.......\<,
....( )/ ( )...

[Erik Post]

Hi all,

Please allow me to repeat here what I said on #frege:

I'd like to call your attention to https://github.com/haskell/haskell-ide. This is an initiative aimed at consolidating the effort around the many tools available for Haskell development, in particular wrt editor/IDE support. My thinking as a co-developer on some of the PureScript infrastructure is that, with some of the right input, this might be made into a multi-language toolchain, since languages such as Frege, Haskell, PureScript, Elm and, to some extent, Scala have rather a lot in common. I noticed this https://groups.google.com/forum/#!topic/frege-programming-language/JdMQvD3a28Y post on the Frege mailing, and thought this might be an excellent time for (some of) you folks to weigh in; I think your input on the discussions going on here https://github.com/haskell/haskell-ide/issues/ would be very much welcomed. There's also the irc channel #haskell-ide.

Hope to see you around! :)

Cheers,

Erik

[harv...@cse.ohio-state.edu]

Tooling is quite frequently the limiting reagent with new programming languages (or, at least those lacking massive industry support).  Reknowned Scala hacker Simon Schäfer has been thinking about the issues surrounding IDEs and tooling (in the context of Scala), but I think he is interested in the broader context of other languages and platforms.  His research goals synopsis is probably a worthwhile read for anyone interested in these kinds of problems:

https://github.com/sschaef/ide-research/wiki/Goals-of-This-Research-Platform

Cheers,

William Harvey

[hu...@bluecorn.io]

1. Wrte an eclipse plugin from scratch, using latest Eclipse technology. Pro: future-proof. Contra: who can do this? 

If the syntax and grammar are well documented somewhere then maybe this might provide one way of writing an Eclipse editor from scratch:

https://eclipse.org/Xtext/ 

[Ingo W.]

Hi Hugo,

it is not only documented (i.e. Haskell 2010 Report, Frege Language Ref (though a bit outdated)), it is actually implemented on the JVM.

Writing a second compiler in a 3rd language (and then, for the next IDE, a 3rd compiler or at least parser in a 4th one (IDEA I'm looking at you!)) is precisely what I'd love to avoid ... 

This is the conditio sine qua non: Compilation of a source module must result in the exact same outcome, whether from an IDE or from the command line. This means an IDE must use the standard compiler, whether directly or through interfaces.

This was precisely the idea of the IMP language framework (which is the base for the current eclipse plugin): You have a compiler, now build an IDE around it.

Regards, Ingo

[hu...@bluecorn.io]

Ok. I looked at it seems it should be feasible to implement the an editor using Xtext.

Umm... so you are saying you don't like the idea of using Xtext to generate the editor for both Eclipse and IDEA? 

I have no experience with what Xtext will generate for IDEA but I do have experience with using Xtext within Eclipse. From my perspective, Xtext only generates an editor which produces and manipulates *.fr files. Once the editor is made then the product artifacts can be accessed from command line and manipulated using command line in an arbitrary directory structure. The editor can also be integrated into the Eclipse Platform where one can create a Frege project and use the standard Eclipse IDE workflow of editing, building, running/debugin etc.Is the same possible with the generated IDEA plugin from Xtext???

Personally, I am learning Haskell (Frege) and building an editor using Xtext would be doable but it would take time since I would be learning the language as I build the editor. I am willing to create an Xtext based edtior for Frege that can support a "Hello Word" script in a fr file:

module Main where

main = putStrLn "Hola"

--

Maybe once that is done then we can see if it would be worthwhile to continue working on the Xtext based editor?

-H

[Ingo W.]

Hugo,

perhaps I didn't express myself clearly enough. I have nothing against Xtext or any other technologies. To the contrary, the prospect of supporting Eclipse and IDEA in one go is great.

The question is only this. Let's say we have this Xtext thing. (to me, it is not at all clear how compiling, building, etc. would work, but let's put this aside for the sake of discussion.)

Now, how do you think would be the workflow, for

- making changes or adjustments to the lexical grammar

- making changes or adjustments to the grammar  (this happens, for example in the process of adapting to Haskell)

- making changes in the data structures the compiler uses (aka AST)

- ....

in such a way that the IDE is still consistent with the command line?

I tell you, for comparison, how the workflow is now:

- Recompile the compiler with itself, so that the changes are incorporated.

- Test

- Stop eclipse

- Drop the new fregec.jar in the lib/ directory of the eclipse plugin

- Start eclipse

- Done!

(There are slightly more complicated cases, where the need arises to recompile the plugin itself.)

On the Xtext page, I've read something about EMF models, and such. Do you think it would be possible to generate the Xtext stuff somehow?

For example, the parser for the command line compiler is generated from the output of byacc.

[Hugo A. Garcia]

Well... if the the changes to the compiler require changes in the
grammar or syntax used by the editor then the changes have to be done
manually. But I think this is true for any editor implementation.

If the changes are just to the compiler without affecting the
grammar/syntax of the editor then I would strongly urge and recommend
that a separate library plug-in which only contains the fregec.jar is
updated and distributed as a new release. Parts of this process can be
automated using the current makefiles and github release mechanisms.

Here is an example of how to have the fregec.jar ins a separate
plug-in using the current ide:

https://github.com/hugo-bluecorn/eclipse-plugin

I used the current master to compile Frege.

-H

> --
> You received this message because you are subscribed to the Google Groups
> "Frege Programming Language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to frege-programming-l...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

-H

[Thomas Johnsson]

Let me mention another option that I think has not been mentioned:  adapting Leksah. http://leksah.org/

-- Thomas

[Abhinav Sharma]

I'd like to suggest Visual Studio Code as a valid alternative to Atom since, the latter has a tendency to hang and get even slower with more plugins. However, VsCode being written in TypeScript is more a valid solution - perhaps we might be able to use the GHCjs for writing the proper bindings and build upon that work.

They made a simpler design decision regarding the concept of language server which might prove to be even more useful.

Please do take a leighweight editor in consideration - MS is putting a lot of work to make this a dev. env. for the dotNET core VM. They'll keep improving it blazingly fast.

[Dierk König]

visual studio code would even allow writing the language service in Frege itself.
The "language server" approach makes that possible.

cheers
Dierk