wish: allow a: in the function def

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

wish: allow a: in the function def

iler.ml
wish: allow a: in the function definition line:
      function foo(a:line1, a:line2)
This is currently not allowed. But it seems logical to allow it.

Yakov
Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

Nikolai Weibull-11
On 4/23/07, Yakov Lerner <[hidden email]> wrote:
> wish: allow a: in the function definition line:
>       function foo(a:line1, a:line2)
> This is currently not allowed. But it seems logical to allow it.

Why should it be?  Extra typing?

Counterwish: implement better semantics for VimScript so that the
lookup order of variables alleviates the need for explicit
environments.  Yes, this will break backwards compatibility.  Tough.

  nikolai
Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

Robert Lee-7
Nikolai Weibull wrote:

> On 4/23/07, Yakov Lerner <[hidden email]> wrote:
>> wish: allow a: in the function definition line:
>>       function foo(a:line1, a:line2)
>> This is currently not allowed. But it seems logical to allow it.
>
> Why should it be?  Extra typing?
>
> Counterwish: implement better semantics for VimScript so that the
> lookup order of variables alleviates the need for explicit
> environments.  Yes, this will break backwards compatibility.  Tough.
>
>  nikolai
>
Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
using SpiderMonkey) so that people don't need to learn a new language
just to change the color scheme or keyboard mappings. Yes, this will
break backwards compatibility. Tough.

While you are at it: Use XPCOM for GVim and include better OS
integration (so that we can do things like drag and drop text to and
from a Vim window). Also, allow automatic word-wrapping in comments to
be specified on a per-comment-type basis, so that, for example, //
comments can be set to not wrap while */ /* comments do.

Cheers,

-Robert
Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

Peter Hodge-3
In reply to this post by Nikolai Weibull-11

--- Nikolai Weibull <[hidden email]> wrote:

> On 4/23/07, Yakov Lerner <[hidden email]> wrote:
> > wish: allow a: in the function definition line:
> >       function foo(a:line1, a:line2)
> > This is currently not allowed. But it seems logical to allow it.
>
> Why should it be?  Extra typing?

So that the name is consistent everywhere. Makes it much easier to search. I
would appreciate this addition, too.

regards,
Peter


Send instant messages to your online friends http://au.messenger.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

Thomas-59
In reply to this post by Nikolai Weibull-11
>> wish: allow a: in the function definition line:
>>       function foo(a:line1, a:line2)

> Counterwish: implement better semantics for VimScript so that the
> lookup order of variables alleviates the need for explicit
> environments.  Yes, this will break backwards compatibility.

I personally like both wishes. I don't think that this has to
necessarily break backwards compatibility as variables can already have
implicit prefixes: eg foo could be l:foo when used in a function or
g:foo when used in global scope.

So maybe one could make vimscript search a variable foo as l:foo, a:foo,
(maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
variable name error if none exists. Or so.

Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

Ilya Sher-2
In reply to this post by Robert Lee-7
Robert Lee wrote:
> [snip]

> Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> using SpiderMonkey) so that people don't need to learn a new language
If I understand you correctly, you assume that
ECMAScript is the most popular language among
the people that wish to customize VIM. How
do you know the assumption is right?

[snip]

--
For robots (please don't mail me there): [hidden email]
My real email is ilya @ same domain

Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

Andy Wokula
In reply to this post by Thomas-59
Thomas schrieb:
>> Yakov Lerner schrieb:
>>> wish: allow a: in the function definition line:
>>>       function foo(a:line1, a:line2)

yeah, occasionally I do

   :setl isk+=:

to get completion of variable names in vim scripts.
I'd like to have this for function arguments, too.
 
>> Counterwish: implement better semantics for VimScript so that the
>> lookup order of variables alleviates the need for explicit
>> environments.  Yes, this will break backwards compatibility.
>
> I personally like both wishes. I don't think that this has to
> necessarily break backwards compatibility as variables can already have
> implicit prefixes: eg foo could be l:foo when used in a function or
> g:foo when used in global scope.

> So maybe one could make vimscript search a variable foo as l:foo, a:foo,
> (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> variable name error if none exists. Or so.

Don't like the idea.
In Vim script there is no need or possibility to declare variables.
Now, if I forget to init a fun-local variable (happens often to me)
Vim gives me a helpful error ("undefined variable").

This wouldn't be the case anymore if Vim could find obscure variables with
the same name I've never heard of (e.g. set by some weird plugin).

Also would it be _recommended_ to ever use a window-local variable without
the "w:" prefix? ... IMHO not.

--
Regards,
Andy

EOM
Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

Thomas-59

> Also would it be _recommended_ to ever use a window-local variable
> without
> the "w:" prefix? ... IMHO not.
Well, it would make it easier for the user to configure scripts. I'm
myself not convinced that it's a good idea to allow this for all
variables, though. But I think it could be useful in some situations
when you want the user to set a variable per buffer/window or use the
global value. I sometimes end up with code like this

if a:0 >= 1
    let x = a:1
elseif exists('b:foo')
    let x = b:foo
else
    let x = g:foo
endif

The idea was to solve this with some magic.

Of course, with the exception of s:, a user-defined function could help
too, which probably is sufficient.

let x = a:0 >= 1 ? a:1 : GetValue('foo', 'bg')

Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

iler.ml
In reply to this post by Ilya Sher-2
On 4/24/07, Ilya Sher <[hidden email]> wrote:
> Robert Lee wrote:
> > [snip]
>
> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> > using SpiderMonkey) so that people don't need to learn a new language

As a sarcastic joke, this sounds average. But seriously, vim
having supprt for embedded perl,python,ruby, tcl and scheme
interpreters, it is realistically to expect javascript interpreter added
one day.

Yakov
Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

Gregory Seidman-4
In reply to this post by Ilya Sher-2
On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote:
> Robert Lee wrote:
> [snip]
> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> > using SpiderMonkey) so that people don't need to learn a new language
> If I understand you correctly, you assume that
> ECMAScript is the most popular language among
> the people that wish to customize VIM. How
> do you know the assumption is right?
> [snip]

Actually, I like the proposal for two entirely different reasons:

1) the language specification comes from an international standards body
2) there are lots of people working on efficient implementations, at least
   two of which are open source (SpiderMonkey and Adobe's Tamarin, though
   there seem to be some plans to convert SpiderMonkey to use Tamarin)

It is looking more and more like the world of scripting languages for
application extension (as opposed to standalone scripting languages) is
converging on ECMAScript and Lua, particularly for interactive apps. There's
a lot to be said for following a path that leads to interoperability and
code reuse. I would argue that international standardization lends
ECMAScript an edge over Lua, incidentally.

--Greg

Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

Nikolai Weibull-11
On 4/24/07, Gregory Seidman <[hidden email]> wrote:

> On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote:
> > Robert Lee wrote:
> > [snip]
> > > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> > > using SpiderMonkey) so that people don't need to learn a new language
> > If I understand you correctly, you assume that
> > ECMAScript is the most popular language among
> > the people that wish to customize VIM. How
> > do you know the assumption is right?
> > [snip]
>
> Actually, I like the proposal for two entirely different reasons:
>
> 1) the language specification comes from an international standards body

So?  In what way does this make it a good language?  In what way does
this make it a good language to extend Vim with?  Anyone can write a
standard.  It doesn't mean that it's good or what is being
standardized will be, either.

> 2) there are lots of people working on efficient implementations, at least
>    two of which are open source (SpiderMonkey and Adobe's Tamarin, though
>    there seem to be some plans to convert SpiderMonkey to use Tamarin)

SpiderMonkey is a terribly inefficient implementation, which is why
Tamarin will be used in future versions of Gecko.  And I wouldn't say
that efficiency is the primary concern of a language/runtime engine to
use for Vim.

> It is looking more and more like the world of scripting languages for
> application extension (as opposed to standalone scripting languages) is
> converging on ECMAScript and Lua, particularly for interactive apps.

I'm sure Microsoft agrees with this sentiment.

> There's a lot to be said for following a path that leads to interoperability and
> code reuse.

Yeah, follow-the-leader is everyone's favorite game.  And just look at
all the libraries for both these languages.  Application extension may
sometimes be restricted to the domain of the actual application, but
having an abundance of libraries certainly opens up for more
interesting possibilities.

> I would argue that international standardization lends
> ECMAScript an edge over Lua, incidentally.

Lua is standardized in the sense that it has only one implementation.

  nikolai
Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

Nikolai Weibull-11
In reply to this post by iler.ml
On 4/24/07, Yakov Lerner <[hidden email]> wrote:
> On 4/24/07, Ilya Sher <[hidden email]> wrote:
> > Robert Lee wrote:
> > > [snip]
> >
> > > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> > > using SpiderMonkey) so that people don't need to learn a new language

> As a sarcastic joke, this sounds average. But seriously, vim
> having supprt for embedded perl,python,ruby, tcl and scheme
> interpreters, it is realistically to expect javascript interpreter added
> one day.

Yes.  All that is required is that someone actually invests some time
into doing it.

  nikolai
Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

Nikolai Weibull-11
In reply to this post by Ilya Sher-2
On 4/24/07, Ilya Sher <[hidden email]> wrote:
> Robert Lee wrote:
> > [snip]
>
> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> > using SpiderMonkey) so that people don't need to learn a new language
> If I understand you correctly, you assume that
> ECMAScript is the most popular language among
> the people that wish to customize VIM. How
> do you know the assumption is right?

Aw, come on.  Everyone knows ECMAScript.  It's like with HTML:
everyone knows HTML.  It's like on the web and stuff.

I mean, seriously, it's a lot more intuitive to write

Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t', "")

than

:set fo-=t

It's all about domain specific languages.  It's said so on the internet.

  nikolai
Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

Nikolai Weibull-11
In reply to this post by Andy Wokula
On 4/24/07, Andy Wokula <[hidden email]> wrote:
> Thomas schrieb:

> > So maybe one could make vimscript search a variable foo as l:foo, a:foo,
> > (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> > variable name error if none exists. Or so.

> Don't like the idea.
> In Vim script there is no need or possibility to declare variables.
> Now, if I forget to init a fun-local variable (happens often to me)
> Vim gives me a helpful error ("undefined variable").

And I have the same problem with a: prefixes for my arguments.  Fine,
keep prefixes for g:, w:, and b:, but a: is just such an incredibly
nonstandard way of doing things.  In almost all languages parameters
are treated the same as local variables.

  nikolai
Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript

Ilya Sher-2
In reply to this post by Nikolai Weibull-11
Nikolai Weibull wrote:

> On 4/24/07, Ilya Sher <[hidden email]> wrote:
>> Robert Lee wrote:
>> > [snip]
>>
>> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
>> > using SpiderMonkey) so that people don't need to learn a new language
>> If I understand you correctly, you assume that
>> ECMAScript is the most popular language among
>> the people that wish to customize VIM. How
>> do you know the assumption is right?
>
> Aw, come on.  Everyone knows ECMAScript.
That's an assumption again. Something that's perceived as general truth.
Any facts to support it?
I guess there are lot of happy C (just an example) programmers
using VIM that don't know JavaScript and friends.

> It's like with HTML:
> everyone knows HTML.  It's like on the web and stuff.
>
> I mean, seriously, it's a lot more intuitive to write
>
> Vim.options['formatoptions'] =
> Vim.options['formatoptions'].replace('t', "")
>
> than
>
> :set fo-=t
It's true for me but I assume there are people who would argue.
Huge clarity/brevity tradeoff though...
>
> It's all about domain specific languages.  It's said so on the internet.
>
>  nikolai


--
For robots (please don't mail me there): [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

Gregory Seidman-4
In reply to this post by Nikolai Weibull-11
On Tue, Apr 24, 2007 at 05:57:45PM +0200, Nikolai Weibull wrote:

> On 4/24/07, Ilya Sher <[hidden email]> wrote:
> >Robert Lee wrote:
> >> [snip]
> >
> >> Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> >> using SpiderMonkey) so that people don't need to learn a new language
> >If I understand you correctly, you assume that
> >ECMAScript is the most popular language among
> >the people that wish to customize VIM. How
> >do you know the assumption is right?
>
> Aw, come on.  Everyone knows ECMAScript.  It's like with HTML:
> everyone knows HTML.  It's like on the web and stuff.
>
> I mean, seriously, it's a lot more intuitive to write
>
> Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t', "")
>
> than
>
> :set fo-=t
>
> It's all about domain specific languages.  It's said so on the internet.

Hey, congratulations! You designed a crappy API! Of course, you can
design a crappy API in any language. Take a look at this:

:let &fo = substitute(&fo, "t", "", "")

That looks terrible! Oh, hang on, you say there's a better way?

I'm not impressed with your strawman argument.

>  nikolai
--Greg

Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

Nikolai Weibull-11
On 4/24/07, Gregory Seidman <[hidden email]> wrote:

> On Tue, Apr 24, 2007 at 05:57:45PM +0200, Nikolai Weibull wrote:
> > On 4/24/07, Ilya Sher <[hidden email]> wrote:
> > >Robert Lee wrote:
> > >> [snip]
> > >
> > >> Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> > >> using SpiderMonkey) so that people don't need to learn a new language
> > >If I understand you correctly, you assume that
> > >ECMAScript is the most popular language among
> > >the people that wish to customize VIM. How
> > >do you know the assumption is right?
> >
> > Aw, come on.  Everyone knows ECMAScript.  It's like with HTML:
> > everyone knows HTML.  It's like on the web and stuff.
> >
> > I mean, seriously, it's a lot more intuitive to write
> >
> > Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t', "")
> >
> > than
> >
> > :set fo-=t
> >
> > It's all about domain specific languages.  It's said so on the internet.
>
> Hey, congratulations! You designed a crappy API! Of course, you can
> design a crappy API in any language.

Yes, sorrry.  My two minute API design is obviously flawed.  Perhaps
we can get to see a better one?

> Take a look at this:
>
> :let &fo = substitute(&fo, "t", "", "")
>
> That looks terrible! Oh, hang on, you say there's a better way?

Yes?

> I'm not impressed with your strawman argument.

And I'm not impressed with your argument for replacing VimScript with
ECMAScript.

Either way, this point is completely moot.  VimScript strikes a
balance between being a set of editor commands and a programming
balance.  It's not perfect by any means, but it does fit the model
quite well.  It won't be replaced, for the simple reason that
VimScript is, in essence, Vim.

  nikolai
Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

iler.ml
In reply to this post by Nikolai Weibull-11
On 4/24/07, Nikolai Weibull <[hidden email]> wrote:

> On 4/24/07, Andy Wokula <[hidden email]> wrote:
> > Thomas schrieb:
>
> > > So maybe one could make vimscript search a variable foo as l:foo, a:foo,
> > > (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> > > variable name error if none exists. Or so.
>
> > Don't like the idea.
> > In Vim script there is no need or possibility to declare variables.
> > Now, if I forget to init a fun-local variable (happens often to me)
> > Vim gives me a helpful error ("undefined variable").
>
> And I have the same problem with a: prefixes for my arguments.  Fine,
> keep prefixes for g:, w:, and b:, but a: is just such an incredibly
> nonstandard way of doing things.

> In almost all languages parameters are treated the same as local variables.
"almost all languages" ? totally untrue. This is only true for in C
(and descendants).
Besides C and descentants, no other language treats function parameters
as local variables.

I actually like a:,l:,g:,b: etc prefixes. They are useful in practice
because in languages
like C++, people tend to invent project-specific suffixes and prefixes
to distinguish between method vars, local vars, etc.
Vim codifies this. I find this convenient.

"Incredibly nonstandard" ? Since when ALL programming languages
obey one and the same standard ? From forth to lisp to vb.net to perl ?
Where did you see common standard for all programing languages ?
This thing does not exist. There are families of related languages with
common features and spirit, yes, but where did you see "standard features"
that programming language must obey ? This is ridiculous statement.
There is no such thing.

Yakov
Reply | Threaded
Open this post in threaded view
|

Re: replace VimScript (was: wish: allow a: in the function def)

Gregory Seidman-4
In reply to this post by Nikolai Weibull-11
On Tue, Apr 24, 2007 at 05:49:19PM +0200, Nikolai Weibull wrote:

> On 4/24/07, Gregory Seidman <[hidden email]> wrote:
> >On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote:
> >> Robert Lee wrote:
> >> [snip]
> >> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> >> > using SpiderMonkey) so that people don't need to learn a new language
> >> If I understand you correctly, you assume that
> >> ECMAScript is the most popular language among
> >> the people that wish to customize VIM. How
> >> do you know the assumption is right?
> >> [snip]
> >
> >Actually, I like the proposal for two entirely different reasons:
> >
> >1) the language specification comes from an international standards body
>
> So?  In what way does this make it a good language?  In what way does
> this make it a good language to extend Vim with?  Anyone can write a
> standard.  It doesn't mean that it's good or what is being
> standardized will be, either.

Where did anyone say that standardization made it a better language than
any other? Most of what makes it a good language has been there since the
earliest JavaScript implementations. Many of the issues that have made it
difficult to work with in the past have been hammered out during
standardization or were API issues rather than language issues.

But even that isn't what standardization buys you. The main advantage is
interoperability. If someone writes some excellent library for use in some
Flash app, but is of use in some other environment that provides ECMAScript
extension, you can just copy it over and use it. I'm capable of porting an
algorithm in one language I know to another language I know, but that's a
bit more work than copy and paste.

> >2) there are lots of people working on efficient implementations, at least
> >   two of which are open source (SpiderMonkey and Adobe's Tamarin, though
> >   there seem to be some plans to convert SpiderMonkey to use Tamarin)
>
> SpiderMonkey is a terribly inefficient implementation, which is why
> Tamarin will be used in future versions of Gecko.  And I wouldn't say
> that efficiency is the primary concern of a language/runtime engine to
> use for Vim.

I strongly disagree with that statement. Efficiency is certainly important
for an editor. I don't want to sit and twiddle my thumbs while vim starts
up or executes hooks on file read, nor do I want it to suck up a big chunk
of memory while it's going about its business. In fact, what I'm asking it
to do currently rarely takes much time, but it could be really nice to ask
it to do a lot more and still not pay a huge time or memory penalty.
Efficiency is definitely important.

> >It is looking more and more like the world of scripting languages for
> >application extension (as opposed to standalone scripting languages) is
> >converging on ECMAScript and Lua, particularly for interactive apps.
>
> I'm sure Microsoft agrees with this sentiment.

What does Microsoft have to do with anything?

> >There's a lot to be said for following a path that leads to
> >interoperability and code reuse.
>
> Yeah, follow-the-leader is everyone's favorite game.  And just look at
> all the libraries for both these languages.  Application extension may
> sometimes be restricted to the domain of the actual application, but
> having an abundance of libraries certainly opens up for more
> interesting possibilities.

Vim already has Perl, Python, and Ruby interpreters for application
extension, assuming you build it with the appropriate options. Any library
available for any of these languages can be made available to the Vim
runtime with minimal hassle. Are there lots of VimScript libraries that are
outside the application domain? So how does replacing VimScript with
ECMAScript prevent these interesting possibilities?

As for following the leader, you are on shaky ground. Vim followed in the
footsteps of vi just as Linux followed in the footsteps of Unix. Do you see
something wrong with adopting good choices simply because other people are
making the same good choices? I think that recognizing good choices being
made by others and benefiting from them is a pretty good idea.

> >I would argue that international standardization lends ECMAScript an
> >edge over Lua, incidentally.
>
> Lua is standardized in the sense that it has only one implementation.

The same applies to Intercal. I don't see the relevance.

You seem to have a particularly hostile view toward ECMAScript, beyond a
simple preference for the status quo, and I'm not sure why. Would you like
me to talk about why I like it as a language, rather than why I think it
would benefit Vim?

>  nikolai
--Greg

Reply | Threaded
Open this post in threaded view
|

Re: wish: allow a: in the function def

A.J.Mechelynck
In reply to this post by Robert Lee-7
Robert Lee wrote:
[...]
> Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> using SpiderMonkey) so that people don't need to learn a new language
> just to change the color scheme or keyboard mappings. Yes, this will
> break backwards compatibility. Tough.
[...]

Don't? WTF EMCAScript? If you want to replace vimscript by something I already
know (yes, /I/ am people), use COBOL, BASIC or FORTRAN. Or even ALGOL. At
least vimscript uses the same commands as those which I type at the vim
command-line.

OTOH, some other "people" prefer LISP. But replacing vimscript by Lisp has
already been done: it's called Emacs.

Or if you want to scrap ex-commands everywhere (even when typed-in by hand,
one by one) and use EMC-WTF instead, go ahead, I'm not detaining you. But
don't call your new editor Vim.


Best regards,
Tony.
--
Real Programs don't use shared text.  Otherwise, how can they use
functions for scratch space after they are finished calling them?
123