extract some features

[aeosynth]

imo, certain features, like iterators and promises, seem a bit specialized, and make the language feel bloated. maybe these should be extracted into their own macro library

[andreyvit]

I'd say anything coming to ES6 (iterators) should be kept in the core.

Aside from that, as long as we can override standard macros with custom ones (#111), the difference between the language and a standard macro library is basically an import statement and the way you describe it in the docs.

[ckknight]

If you don't use promises or generators, then you won't feel any performance hit on your code.

I think for a language, having a full-featured, useful standard library is very useful to provide a minimum of conceptual understanding.

Also, extracting some features would be significantly harder than others. For instance, removing generators would be complex because most of the logic takes place in the Gorilla AST to JavaScript AST conversion process, whereas providing some macros could be 10 lines of code in jsprelude.gs.

So, since they don't affect your performance if you don't use them, having features and not needing them is a lot nicer than needing features and not having them.

[aeosynth]

since they don't affect your performance if you don't use them, having features and not needing them is a lot nicer than needing features and not having them

the features would be an import away, and would compete with other implementations on an equal footing. someone could write a more performant macro, which becomes more popular than the standard

generators were just an example; since they are in es6, i guess would be ok with keeping them. promises and async seem too opinionated, though, especially to-promise! and from-promise!, which explicitly facilitate node.js style callbacks

[ckknight]

Possibly. I'm not totally sure how it would be best to divvy up, and even if I want to. I do somewhat understand your qualms about the node.js-facilitating macros, but I don't want to make the default use case of "I'm making an app or script that may have various different features, from promises to generators to Map/Set first-class syntax. Having to list at the top that you're using all those features seems like more of a pain than anything.

[aeosynth]

I'm not totally sure how it would be best to divvy up

one option: anything with a significant runtime, excluding es6

Having to list at the top that you're using all those features seems like more of a pain than anything.

import all std ?

[andreyvit]

@aeosynth If we allow to override standard macros, is there any reason third-party impls cannot compete on an equal footing? I.e. what's the practical benefit of requiring an import?

[ckknight]

128

[aeosynth]

this is a philosophical issue, not a technical one. with macro overriding, third parties can provide alternate implementations, but the standard macros will always be 'more equal' by virtue of being embedded in the language

[ckknight]

Well, that's why there's the standard part of the language (made up by the base syntax plus the standard macros like if and class) and then your own custom macros that you can include per-project or what have you.

One could argue that having class support is unnecessary (and I would agree), but it's handy in the general case.

The same could be said of pretty much any feature that one may or may not use (e.g. topicless switch, promises, generators, ES6 collections, etc.), but by having them be available makes it so you don't have to think about importing, since they're "standard".

Because of all the shiny features GorillaScript provides, it may seem "bloated" to you, and yes the surface area of the language is greater, but I'd rather have the standard niceties when desired.

[aeosynth]

ok. closing