Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I actually thought that was the neatest thing about this proposed language. I didn't get too excited about any of the design goals, but regarding syntax, this seems pretty original.

It allows for less syntax, which is a win for readability and also less boilerplate tokens, but still gives you a little freedom to mess with your indentation, unlike python. It means that (true) lambdas wouldn't be a syntactical enigma like they would be in python.

I don't think that you would need to use "}" to end a block though, since it looks like its missing the opening bracket, but maybe double semicolons would work, since they apparently aren't used elsewhere:

    MAIN()
      IO.write("Hello, World!\n")
    ;;
To be honest, the syntax that I have found to be nicest on the eyes so far has been Io:

    whois := method(host,
        socket := Socket clone setHostName("rs.internic.net") setPort(43) 
        socket connect streamWrite(host, "\n")
        while(socket streamReadNextChunk, nil)
        return socket readBuffer
    )
taken from http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.h...


Io is an absolute joy. It's too slow to be practical but that's my personal bent. Not everything has to be practical of course.


`True lambdas' are overrated. The Python way is just fine. If you want to do anything that needs two lines, you are probably doing something complicated enough that this function deserves its own name.


...it wouldn't be as big an issue if Python's closures and scoping weren't problematic as well.


As far as I know Python has true lexical scoping for functions, if not for blocks. (They used to have very limited scoping ages ago.)

What do you mean?


In Python 2.6:

    def acc(x):
        foo = x
        def closures_are_broken():
            foo += 1
            return foo
        return closures_are_broken
    
    
    def acc2(x):
        foo = [x]
        def closure_with_workaround():
            foo[0] += 1
            return foo[0]
        return closure_with_workaround
The former is an error ("UnboundLocalError: local variable 'foo' referenced before assignment"), the latter is a workaround by manually boxing the variable in a list. I'm not sure why that works, but it's rather ugly.

The same, in Lua:

    function acc(x)
       local foo = x
       return function()
                 foo = foo + 1
                 return foo
              end
    end


Oh, yes. You are mutating variables. You shouldn't do that anyway in a functional setting.

Python's syntax forces the language to guess whether you want to make a new variable or use the variable of the same name from the outer scope. The heuristic they have, says that if you assign something to the variable, you get a new one by default. You can declare

  global x
before to assign to the variable in the outerscope.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: