function composition construct about luna HOT 20 CLOSED

I love the global functions with typed signatures from julia

from luna.

ya that's sweet, in the long run it's bound to be a wayyyy more elegant solution than prototypes. Just brainstorming ideas. I didn't realize the first time I looked at it but julia looks really similar to lua actually

from luna.

I think maybe manual import of stdlib would be hot. Not sure how modules will work in Luna but something like this may be hot:

import array reduce

from luna.

real tricky stuff is say you have:

last = users[n]

# and later zomg it's not a function anymore

something | last

from luna.

Well the composition operator could sort out the ambiguity, since it expects functions

from luna.

yeah that's what I was thinking too, python style might not be so bad if you have these options:

fs = import 'fs'

fs rm()
fs cp()
# etc

import rm, cp from 'fs'

rm()
cp()

import * from 'fs' 
# or just import 'fs'

from luna.

you would have to support multiple vars / functions (just function overloading?) of the same name like julia in that case for sure yeah hmm

from luna.

another cool unixy example might be stuff like:

fs rm(fs glob('lib/*.js'))

as

fs glob('lib/*.js') | fs.rm

that sort of idea. pipelines are so clean <3

from luna.

I also like that operators are functions in Julia.

In this case, | could be defined as |(Array,Function).

Since there wouldn't be a a matching definition for |(Array,Object) (assuming users[n] is an object in your example), it would simply throw without needing to special-case the operator.

from luna.

yeah that's not uncommon, in ruby / c++ etc you can redefine them but they're not super elegant. As long as we have the "right" key concepts I dont think it's brutal to bake it into the syntax as long as they're solid, just like how we dont use polish notation for operations anyway, it's definitely an assumption but one we're all used to. I'd hate to unleash operator overloading to implement core stuff and then have people using / for a path.join() like ruby land hahaha, then it's kinda bringing back the coercion issues we have in js

from luna.

In any case, you would have to import the module that adds the overloaded definition… I don't think that's bad

from luna.

actually I think you're right with the julia stuff because we would kinda have to support function overloading, otherwise something generic like last would be specific to arrays and not sets / lists / whatever. hmmmMmMm

from luna.

Right, you're there anyways. And if you consider an operator just another function with special syntax, then it all becomes consistent.

from luna.

I can see keeping the suite of functions consistent in user-land could be really troublesome,
even things like a map callback:

map: arr:Array, fn:Function
  vals = []
  each(arr): val, i
    push(vals, fn(val, i))
  ret vals

maybe custom enumerable thing being implemented wrong and forgetting to pass i and then everything else goes to shit, unless there's some formal interface definition maybe.

then with our funky operator for proto-less oop:

map: arr:Array, fn:Function
  vals = []
  arr.each: val, i
    vals.push(fn(val, i))
  ret vals

or generic enum stuff could be untyped maybe, which would break once map, reduce, select etc hit arr.each on something non-enumerable which would be valid

map: arr, fn:Function
  vals = []
  arr.each: val, i
    vals.push(fn(val, i))
  ret vals

from luna.

I don't see the problem.

fn(val, i) would complain that the supplied function is not defined as Object,Number

from luna.

if the value(s) you're operating on are untyped it would be fine, I was just thinking of third-parties had to re-define the function and retain the semantics it could get dicey. More motivation for simple functions I guess too haha

from luna.

Ideally I kinda want to achieve things like ruby's nice Enumerable mixin and some of the others - without the indirection of mixins haha, hell even prototypes barely make sense to me even more. If we had only one composite type like Lua it could be pretty straight-forward, everything else would branch off that anyway

For other stuff like oh no I need a sprintf it would look somthing like:

# in string.luna

import io from 'stdio'

#
# Write string to stout with trailing newline:
#
#  puts('hey')
#  'hey'.puts()
#  'hey' | puts
#

export puts =: self:String
  io stdout write(self + '\n')

  # or:

  self | concat '\n' | io stdout write

  # or:
  io stdout write(+(self, '\n'))
  io stdout write(concat(self, '\n'))

#
# Format strings:
# 
#    'email "%s" received from %s <%s>'.format(subject, user name, user email)
# 
#

export format =: self:String, ...args
  # stuff




# in whatever.luna

import format, puts from 'string'

# valid uses:

puts('Hey %s'.format('tobi'))

puts('Hey %s' | format 'tobi')

'Hey %s' | format 'tobi' | puts

from luna.

some more random examples for myself, things like
this could handle concurrency pretty easily, hell maybe
even use a tail & to allow for fork/join that looks a lot like the shell.

I'm not a van of parenless calls but if we allowed them this would
look even more like nice unixy shell stuff:

cat 'names.txt' | grep 'tobi' | tee 'tobis.txt' | stdout pipe

effectively:

stdout pipe((tee(grep(cat('names.txt'), 'tobi'), 'tobis.txt'))

potentially even more crazyness, that im not advocating, but just
mentioning for myself, is sniffing a to_function() member of a struct (if we even allow for such a thing):

cat 'names.txt' | grep 'tobi' | tee 'tobis.txt' | stdout

some sort of fork/join concept to perform parallel work, & could wrap
the expression in a fork() function and then simply join() as needed

tobi = GET 'http://google.com/q?=tobi' &
loki = GET 'http://google.com/q?=loki' &
results = join(tobi, loki)

since fork() is just a function this would work fine:

fork:
  GET '...'

fork:
  GET '...'

this might be leaky as far as patterns go, but over-all I the 80-percentile use-case -
especially with web app development is sequential coupled with parallel queries
etc as you go, but none of this callback mess. more advanced patterns can just revert to coroutines.

another potential change is member access from so that we can pass arguments
without, as a delimiter. might be super sketchy but for example:

POST('/user', { name: 'tobi' })

to

POST '/user', { name: 'tobi' }

to

POST '/user' { name: 'tobi' }

if POST understood how to handle file streams then this could construct multipart:

glob '*.mp4' | POST '/upload'

another contrived example:

cat 'users.json' | json | map pets | first | POST '/pet'

from luna.

https://gist.github.com/1a83f93a8e6192f82b87

from luna.

dont want to violate my parens-only rule, yet at least, so:

cat('names.txt') | grep('tobi') | tee('tobis.txt') | stdout pipe

not any less readable anyway IMO

from luna.