tj / luna Goto Github PK

def first(v:vec, n:int) {
  ret vec.slice(0, n)
}

as sugar for:

def first(v:vec, n:int) {
  ret slice(vec, 0, n)
}

types will still use " " for fields, or change the above to and use. for fields

what's your position regarding OOP in luna?

i currently am very much in love with Go's solution which basically is methods dispatching on structs

I was looking at your example :

person pets select: pet
  pet species == 'ferret' && pet age > 4

I wondered what it would look like if there was more arguments. I would seem that you'd need the brackets in this case?

person.pets.eat("quickly", :
  print("im done"))

Is that correct ?

not personally a fan, but lots of people seem to love #{foo} vs '.foo.' for whatever reason, so consider it i guess, the token stream would be equivalent

maybe add these.

or:

if foo or bar == baz

equivalent to:

if foo == baz || bar == baz

and:

if foo and bar == baz

equivalent to:

if foo == baz && bar == baz

no if foo bar() end crap, looks disgusting, same with functions:

def add(a:int, b:int) ret a + b end

force the newline

even in core I want these to be explicit. Need to think deeper about scenarios however something like:

import sum, length from "vector"
import length from "set"

[1,2,3].length()
[1,2,3].sum()

in general I don't like this because it makes it extremely non-obvious where things came from, however it can still be handy for "throw-away" scripts and executables etc:

import "vector"
import "set"

[1,2,3].length()
[1,2,3].sum()

from local files etc:

import sum from "./my/awesome/vector"

[1,2,3].sum()

looks nicer with idents after, however doesn't read nice:

import "vector": length, sum
import "set": length

Similar to Go they'll be auto-exported, however instead of making you use capitalization, we'll just make you not prefix with _, if it's private use _ (or just expose a bunch of junk, whichever you want). This would be public:

def length(v:vec) {

}

private:

def _length(v:vec) {

}

for implementation sake we'll probably just treat them the same as exports for now, not a big deal really who cares. The only thing it may be useful for explicitly omitting these is some sort of tool that outputs the functions a module exports.

another nice thing with node's style is you can name functions whatever you like, and avoid poor choices that people might make

perhaps "use", short and sweet:

use "vector"
use "set"

[1,2,3].length()
[1,2,3].sum()

using ast output to prevent regressions

pros and cons here but just as a note for later, it might be worth going the approach of an explicit "self" arg:

User.name =: self
  self first + ' ' + self last

user name()
// => "tj holowaychuk"

User name({ first: 'tj', last: 'holowaychuk' })
// => "tj holowaychuk"

this has several pros:

• no need for .apply() or .call() like javascript (just need a spread operator User name(obj, ...args))
• less magical
• available to closures

can look nice, but I've seen so much shit now, that I don't think this is
worth it. Even in Stylus we have this problem and it's mostly declarative. I need
to think on this some more since I have some other more functional plans but
over-all it's looking like significant whitespace sucks

what about allowing ? And ! In function names like ruby does? I find that useful for array methods like pop

once a reasonable amount of implementation is complete, it might be worth abstracting so that the language itself is not bound to the concurrency model, nor many of the dependencies, making it easier to embed, though for the meantime adoption and interest will be greater to have things bundled.

I'm a fan of a, b = [1, 2] but not really in love with ruby's a = 1,2,3, looks great for small things but gets kinda lost without the brackets but for swapping it's nice a, b = b, a

Honestly I prefer def in OO, I see better fun in luna especially for anonymous stuff (if you'll ever want to support it):

a=fun(a:int, b:string){}

or

fun bar() do
   a = fun(){ long_job }
   promise = async(a)
end

but here I see the js problem where:

a = func(){} or func a(){} ?

as separate executable for project boilerplate

ok, i figured out i definitely don't have the time ATM to work on my project.. but i might as well randomly contribute to this one because why not

tl;dr we should have a roadmap, some place where to discuss features, something more specific than what's currently in the readme.. so i can pick up an item from there, push da code and PR it :D

user.name.first.write(stdout) should be equivalent to write(user.name.first, stdout), etc

I removed them because the following looks perfectly fine:

cat('something').grep('whatever').print()

however when arguments are not present pipes are nicer:

tree.archy().indent().highlight('blue')
tree | archy | indent | highlight('blue')

get('http://google.com').grep('tobi').print()
get('http://google.com') | grep('tobi') | print

tough call, supporting both is a little lame, though they do have slightly different use-cases, and with pipes we can assume calls vs slots

you should really investigate pypy and rpython they implemented php with it and it's a lot faster than hiphop for php, they also implemented python with rpython wich is a lot faster than cpython.

pypy

you might want to look at it, that way more programmers can contribute to luna.

cheers :)

need to think about this some more, we get some major wins from typed functions so the implications of allowing untyped and variadic may be a little weird

don't think I like it anymore, too much visual ambiguity introduced by whitespace. use . for fields as well (user.name > user name).

looks like garbage

things like:

a = def(int:a, int:b) { ret some }
a(1, 2)

can like in julia everything be considered as a function itself ? In that case def(a:int) can have sense.

def sub(a:vec_t, b:vec_t) {
  ret vec_t:{
    x: a x - b x
    y: a y - b y
  }
}

vs

def sub(a:vec_t, b:vec_t)
  ret vec_t:{
    x: a x - b x
    y: a y - b y
  }
end

I like braces better in general however if {} are used for anything else, hashes, structs etc it's more noise

Are you going to make your own VM? Look at this: https://github.com/GenTiradentes/tinyvm

Here's a PubSub implementation in luna.

• How do you consider the param-feature?
• Is Array#each(str) possible as a shortcut?
• How will the dictionary-syntax be?
• Are there other mistakes?

PubSub = Object clone()
PubSub channels = []

PubSub param: channel
  channels[channel] ?= []

PubSub subscribe := channel fn
  channels[channel] push(fn)

PubSub publish := channel msg
  channels[channel] each(msg)

PubSub unsubscribe := channel fn
  channels[channel] remove(fn)

exports = PubSub

or more experimental:

PubSub = Object clone()
PubSub channels = []

PubSub param: channel
  channels[channel] ?= []
  channel = channels[channel]

PubSub subscribe := {channel} fn
  channel push(fn)

PubSub publish := {channel} msg
  channel each(msg)

PubSub unsubscribe := {channel} fn
  channel remove(fn)

exports = PubSub

@visionmedia this project seems your best work, I'm not a c expert but I wanna see more!!!

I wanna join this maybe I could help writing the std-lib ? Are we ready for that?

Let me know!

might as well! saves a lot re-implementation work for anyone looking to parse docs etc

i see nowhere infos about an irc chan or a Ggroup so.. is there one?

i really like some ideas from luna btw, keep up the good job :D

I know the project hasn't reached that point yet, what do you think on Go's defer.

as separate executable from markdown files

similar to lua: [1,2,3], [foo:bar, bar: baz]. we could maybe then use {} as a Hash, these hashes could then of course be typed and expose helpful methods like hash.keys(), hash.values(), hash.each: key, val etc

once the switch dispatcher is done

in rewriter

not a huge fan of ruby-style foo #{bar} etc, if you have complex expressions you might as well use concatenation, and for smaller simple expressions it's noisy. I'd rather do some simpler substitution or perhaps python style %

really prefer lowercase c-style vec_t, user_t etc, but it can be a bit ambiguous without _t, also core types would be very common so shorter rust-style may be nice:

def greet(name:String) {
  ret "hello " + name
}

vs

def greet(name:string) {
  ret "hello " + name
}

vs

def greet(name:str) {
  ret "hello " + name
}

u8, i8, u16 etc from rust are sexy too

currently:

users map(:user | user pet) select(:pet | pet age > 10)

is equivalent to the following, but allows for implicit returns

user
  map: user
    ret user pet
  select: pet
    ret pet age > 10

or equivalent to the following javascript:

users.map(function(user){
  return user.pet
}).select(function(pet){
  return pet.age > 10
})

I dont like the current syntax, but I dont want lookahead like dart's (foo, bar) { } syntax or (foo, bar) ->, it makes you scan further ahead than you should have to in order to disambiguate. We could do some special-casing but I dont want to get too deep into that either.

Alternatively or as a compliment it would be nice to quote and provide something like:

users map(.pet) select(.age > 10)

luna < some.luna

I cloned the project and having trouble running the tests.

After I do rake test, the linker complains that the following symbols are missing _luna_object_get, _luna_object_set, and _luna_object_size. I noticed these were macros but were deleted in this commit: e579e51

I guess the tests were not updated.

Anyways, I'm curious about luna and would love to get my hands dirty in VM development. Cheers.

need to think on this. generally i prefer them to be equal, like in javascript, however, I would also like to avoid a regular expression literal, so we will need a string literal that does not require double escaping. tough call, a regexp literal is not much worse than this change

for example the following js:

[1,2,3].map(function(n){ return n * 2 }).reduce(function(sum, n){ return sum + n })

would be equivalent to:

[1,2,3] | map * 2 | reduce +

This would be great because we would have no Array prototype, no prototypes anywhere ideally. map, reduce, first, last and friends would all be separate functions accepting an array. This would have great composition benefits and avoid obscure global manipulations that you see in ruby, js etc. Need to think about how to get something like this in.

Some other implications of this would include potential issues with these identifiers becoming effectively reserved. It would be lame to have list | enum.unique | enum.map * 2 ..., however they would be very easy to bundle up into modules that you explicitly import, however still dumping into that scope.

Perhaps treat . as the composition operator and ` to quote, making it look a lot like regular class or prototype style invocation.

oldest_pet = users.map(`pets).sort(`age).last()

[2,4,6,2,3,8].unique().select(`even).sort().last()

perhaps | could compliment . in that it would imply invocation and quoting:

[2,4,6,2,3,8] | unique | select even | sort | last

if this were the case you would only really use . when intermediary member access is necessary. Luna would effectively treat this as sugar for:

last(sort(select(unique([2,4,6,2,3,8]), even)))

not really an issue ... more of a thought. are you going to use it?

Issue reported by a store owner:
https://dl.dropboxusercontent.com/s/4r8ksygxeoa3i42/media-queries.mov

right now cat ('foo') is valid, I dont want this, no jquery syntax cat ( 'foo' ) crap

currently:

def greet(str:string): string {
  return "hello " + str
}

could be:

def greet(str:string) string {
  return "hello " + str
}

or like rust:

def greet(str:string) -> string {
  return "hello " + str
}

the first two are easier to type, however the extra whitespace introduced by -> makes things a little easier to read IMO

expr statement