Re: improving Vim - Kickstarter - brainstorming - goals - who wants to join?

Excerpts from hermitte's message of Wed Nov 27 14:44:42 +0100 2013:
> The difficulty with C++, is to force ourselves to forget we also know C.
> (BTW, C/C++ is a beast that shall be hunt down. Either code in C, or
> in C++. Never try to import C good practices in C++ because they don't
> apply)
Historically I was told that C++ was written to "reuse the knowledge
of programmers because C programmers did know C".

So how do you rewrite an application such as Vim using C++ without
rewriting it if you should be using only one of C or C++ ?

If I choose to create a new artifical language, I possibly could write
something turning C into my new language, then do what I said to test
huge amounts of C code by adding runtime checks.

Your points are valid. In Haskell I can do:

data Struct =
name :: String,
list :: List (of) Int,
age :: Int

deriving (Show, Read)
^ this is built into the compiler

$(derive [serialize-to-binary, memory-alloc, memory-check])
^ this is "template haskell", which derives class instances for me.

So how I can I possibly make C++ derive a "new(my struct)" which
calls s.bar.fill('\x0') (and does this for each field of the struct) ?

I know that postgresql invents his own preprocessor to make it easier
using SQL in C/C++. But somehow I feel that template haskell like macro
preprocessing is the cleaner solution.

That's what I'm missing and looking for, too.

> Indeed. It's always better to find errors at compilation stage, or at
> least in test units.
Again - who can afford rewriting C? So at least I want to have the
tooling.. but I don't. You should have notice that I'm probably not a
perfect C programmer, but I cannot even imagine becoming one for those
easons.

> Again. Forget free/delete exist and embrace smart-pointers. Not
> necessarily std::shared_ptr<>, but at least the light and fast
> std::unique_ptr<>.
So you think C++ is more than ever a valid replacement for C in the Vim
case. I twould still be interesting to learn why Yzis failed, and how to
prevent such failure.

> Anyway. Use whatever language you master. But don't invent/create a
> new one for this project -- I hope I misread the first message about
> choosing a new language to implement this fork of vim.
I'm wondering how synergy can be shared between Yi and Vim for example.
One is C++, one is Haskell. There might be pieces to share.
In which language to write those in?
That's why I came up with the idea of a language which translates to
both Haskell/Elisp/C++ to at least share "semantic syntax highlighting"
which gets discussed more and more often.

Eg why not allow having some code "run in the browser" ?
I know about llvm -> JS, I don't consider that to be an option, though.

Those are the reasons why I think about "new languages", too.
> On another topic as a plugin writer that has always forced himself to
> stick to viml (for portability issues), it would be nice to have viml
> supported (for ascendant compatibility). I've written to many things,
> and I don't want to leave and loose everything.
I know. VimL is lacking features. But I agree. That's why I consider
this to be "must have". That's why I think truning viml into a
python/ruby/lua/ like standalone project would be worth it.

CcxCZ told me about http://pypy.org which somehow illustrates how
multiple backends could be served.

Marc Weber

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.