Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kashmir: A statically typed Lispy language compiling to Go

owickstrom.github.io

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Kashmir: A statically typed Lispy language compiling to Go

#61

Post by smt88 »

nothrabannosir wrote: post #26
cjslep wrote: post #21

Earlier quoted context omitted.

Do you know how much effort/time it would take to spin up a "play.kashmir", similar to "play.golang"? If it is minimal, it could be one of those items that really lowers the barrier to entry into the language.

Especially if you just do the compilation to Go and redirect the user to a prefilled play.golang.org page with the resulting code. And a comment withe original code and a link back to your site :)

Pre-filling a page on another domain isn't possible unless the creator of that page explicitly creates a way to do it. That's an important security feature of web browsers.

Re: Kashmir: A statically typed Lispy language compiling to Go

#62

Post by technomancy »

mantasm wrote: post #53
hyperpape wrote: post #35

Earlier quoted context omitted.

"Go is the assembly language of cloud infrastructure" People say this about JavaScript because to run code in a browser, it has to execute as JavaScript. As a result, there are lots of actual libraries or webapps that are written in other languages and compiled to JavaScript. In contrast, you can do cloud computing in Java, C++, or various other languages. Go may have advantages, but compiling to Go would just be a c…

Go made choices that makes it a good language to be compiled to. Compilation-wise: it's incredibly fast and compiles to static machine binaries. Runtime-wise: it has great concurrency and communication primitives.

Interesting. What I've heard about Google Go is that the design choices make it very difficult to implement a repl in. So I would expect any other language that compiles to it to be subject to the same limitation, making it a rather poor fit for a Lisp... but maybe I'm missing something?

Re: Kashmir: A statically typed Lispy language compiling to Go

#63

Post by codygman »

bipin_nag wrote: post #56
hyperpape wrote: post #35

Earlier quoted context omitted.

"Go is the assembly language of cloud infrastructure" People say this about JavaScript because to run code in a browser, it has to execute as JavaScript. As a result, there are lots of actual libraries or webapps that are written in other languages and compiled to JavaScript. In contrast, you can do cloud computing in Java, C++, or various other languages. Go may have advantages, but compiling to Go would just be a c…

Javascript would be the assembly language of web i.e. what runs on your browser. Although that won't be true with the advent of Webassembly. Go is language of choice on cloud. If you ask me following is the checklist it passes: 1. Low memory footprint/good GC 2. Concurrency (goroutines) builtin 3. Great dependency (package) management 4. Compiled/closer to bare metal 5. Fast compilation If you check other languages a…

> 3. Great dependency (package) management

Eh... Then why are people experimenting with vendoring?

> If you check other languages against the list they lack at least one of the above. If you feel any other language is better suited please tell.

Ocaml checks all of them. So does Haskell (with stack package manager), with only the low memory requirement being challengeable since many aren't used to optimizing lazy evaluation.

Re: Kashmir: A statically typed Lispy language compiling to Go

#64

Post by codygman »

rough-sea wrote: post #36
jondot wrote: post #28

Earlier quoted context omitted.

There are so many motivations for this (and so many lisp/go projects that are abandoned). This looks very promising and I hope it takes off. A few of the motivations: * A lisp with an amazing startup time * A lisp that can tap into a big and vivid ecosystem, like Clojure is tapping into Java's and its own * Cross compilation and self-contained binary (I've personally tried doing this with various lisps, and none of t…

so why not just use Go? less complexity - same benefits. you're basically saying it's somehow an advantage to program in s-expressions...

There are many reasons using sexp's can be better than just writing Go including but not limited to:

- structured editing of source code - macros (dry, dsl's, etc) - if your Go code uses interface{} everywhere you'll probably have more of an advantage using dynamic typing anyway.

Re: Kashmir: A statically typed Lispy language compiling to Go

#65

Post by codygman »

themartorana wrote: post #39
rough-sea wrote: post #36

Earlier quoted context omitted.

so why not just use Go? less complexity - same benefits. you're basically saying it's somehow an advantage to program in s-expressions...

Have you ever talked to a Lisp enthusiast? That's said, the project states more flexibility as a goal - specifically supporting generics. Between code generation and the cross-language compiler, writing generics (but generating non-generic Go code) should be somewhat easy to reason about.

Have you ever talked to one of the many people who write Lisp,scheme, or Clojure for real world applications and even get paid for it.

There are many advantages to writing real world applications in a lisp.

Re: Kashmir: A statically typed Lispy language compiling to Go

#68

Post by owickstrom »

gus_massa wrote: post #2

I'd really like to see an snippet in the front page. There are some samples in the tutorial, but I like to see an example to get some feeling of the language. For example, a mix of (define (factorial n) (if ( and ;; here the type of y is inferred (fn ([x : int] y) (+ x y))

Got something up there now.

Re: Kashmir: A statically typed Lispy language compiling to Go

#69

Post by owickstrom »

S4M wrote: post #8
owickstrom wrote: post #6

Earlier quoted context omitted.

Cool! :) I'll add more examples as soon as possible. Actually there's not much you can do with Kashmir at the moment, I've mostly focused on getting the basic model up so there's no library functions available etc. I have an idea about how to read the type signatures from compiled Go packages to be able to do simple interop between Kashmir and Go - no extern declarations or anything like that.

One thing I wonder: does let take types? Something like: (let ((x :string "hello")) (fmt.Println (+ x "owickstrom"))) (Although in that case the type can probably be infered...)

It does!

  (let (([x : string] "hello"))
    (fmt.Println (+ x "owickstrom")))

Re: Kashmir: A statically typed Lispy language compiling to Go

#70

Post by dTal »

zem wrote: post #55
dTal wrote: post #48

Earlier quoted context omitted.

>Cross compilation and self-contained binary Did you try Chicken Scheme? $ echo "(print \"Hello, World"'!'"\")" > hello-world.scm $ csc hello-world.scm $ ./hello-world Hello, World! $ du hello-world 16 hello-world

I use chicken and it's awesome, but i dont think there's an easy way to generate windows and mac binaries from linux. go is really good for that.

I don't know about 'easy', but it just calls GCC in the end, so anything that can be made to work with GCC can be made to work with Chicken. Apparently building Windows binaries on Linux can be done with MinGW, though I've never tried: http://www.blogcompiler.com/2010/07/11/compile-for-windows-o...
Post reply on HN