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

Pocketlang

github.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Pocketlang

#51

Post by nine_k »

throwaway894345 wrote: post #30
WmyEE0UsWAwC2i wrote: post #27

Earlier quoted context omitted.

Sounds like https://dhall-lang.org/

It's close. I also want something that is going to be syntactically familiar to humble programmers (my target users, myself, etc); Dhall's syntax is clearly Haskell-adjacent which is an obstacle for many of us. I'll probably just roll my own using a Rust-like syntax.

I frankly think that alternative syntaxes for the same languages ought to be a thing. Case in point: OCaml and Reason.

I can imagine a curly-braced syntax for Dhall (BTW Haskell does have curly-braced syntax when you need it), curly-braced syntax for Python, etc. Indent-based syntax for HTML was implemented (but I forgot the name).

Also, RTL syntax and Arabic / Hebrew keywords for languages have also been implemented; this must be a huge help to those whose native writhing systems are RTL. Try writing your code right-indented and with all expressions backwards.

Re: Pocketlang

#52

Post by adsharma »

throwaway894345 wrote: post #40
adsharma wrote: post #35

Earlier quoted context omitted.

Would your users be ok with something like this? Python syntax, rust concepts and transpiles to rust (and 6 other languages) https://twitter.com/arundsharma/status/1407229297392115713

The syntax seems generally fine (Python's type annotation syntax is shoe-horned to minimize changes to the parser--if you're allowing yourself to rewrite the parser, why not improve the type annotations? Indeed, why not stick to a more Rust-like syntax in general?). I would want the ability to restrict the standard library and builtins (no I/O) a la Lua. Also, if the type system involves a borrow checker, I'll pass (…

I'm open to having another syntax, another parser that produces the same AST. Let the market decide. No borrow checker concepts in the source, but transpiled rust code of course uses the borrow checker.

The python standard library is where I think the strength of this approach lies. Was reading some history on why reddit was rewritten in python (after initially implemented in LISP).

Transpiling python stdlib is a significant task in itself and could use more love.

Re: Pocketlang

#53

Post by throwaway894345 »

adsharma wrote: post #52
throwaway894345 wrote: post #40

Earlier quoted context omitted.

The syntax seems generally fine (Python's type annotation syntax is shoe-horned to minimize changes to the parser--if you're allowing yourself to rewrite the parser, why not improve the type annotations? Indeed, why not stick to a more Rust-like syntax in general?). I would want the ability to restrict the standard library and builtins (no I/O) a la Lua. Also, if the type system involves a borrow checker, I'll pass (…

I'm open to having another syntax, another parser that produces the same AST. Let the market decide. No borrow checker concepts in the source, but transpiled rust code of course uses the borrow checker. The python standard library is where I think the strength of this approach lies. Was reading some history on why reddit was rewritten in python (after initially implemented in LISP). Transpiling python stdlib is a sig…

Having a stdlib is fine, but it’s incompatible with an embedded scripting language where we want to provide and control the APIs that are available to the user. It sounds like you’re building a general purpose application programming language which is fine, but the tradeoffs differ.

Re: Pocketlang

#54

Post by dang »

leephillips wrote: post #18
__ryan__ wrote: post #13

> The language is written using Wren Language and their wonderful book Crafting Interpreters as a reference. I had to read this a few times to understand that this isn’t saying that Pocketlang is not written in Wren. I was looking for Wren code in the repo and I was slightly confused. Very cool project though! I always love to see projects inspired by Crafting Interpreters.

Do you usually read the second paragraph first?

Please don't be a jerk in HN comments.

https://news.ycombinator.com/newsguidelines.html

Re: Pocketlang

#55

Post by __ryan__ »

sicromoft wrote: post #48
__ryan__ wrote: post #13

> The language is written using Wren Language and their wonderful book Crafting Interpreters as a reference. I had to read this a few times to understand that this isn’t saying that Pocketlang is not written in Wren. I was looking for Wren code in the repo and I was slightly confused. Very cool project though! I always love to see projects inspired by Crafting Interpreters.

> I had to read this a few times to understand that this isn’t saying that Pocketlang is not written in Wren I had to read that a few times to understand what I think is an unintentional double negative on your part.

Ah yes, the double negative was unintentional.

I shouldn’t be allowed on HN until I’ve had my morning coffee.

Re: Pocketlang

#56

Post by beefjerkins »

blauditore wrote: post #49
sicromoft wrote: post #48

Earlier quoted context omitted.

> I had to read this a few times to understand that this isn’t saying that Pocketlang is not written in Wren I had to read that a few times to understand what I think is an unintentional double negative on your part.

So, to decrypt this: The author used Wren as an example/reference on how to build a programming language, but built something unrelated to it. Correct?

Yep

Re: Pocketlang

#57

Post by rmetzler »

blauditore wrote: post #49
sicromoft wrote: post #48

Earlier quoted context omitted.

> I had to read this a few times to understand that this isn’t saying that Pocketlang is not written in Wren I had to read that a few times to understand what I think is an unintentional double negative on your part.

So, to decrypt this: The author used Wren as an example/reference on how to build a programming language, but built something unrelated to it. Correct?

Oh, thanks for clarifying. I had trouble to understand both sentences before.

Re: Pocketlang

#58

Post by remix2000 »

throwaway894345 wrote: post #25

I love these little embedded languages, but I really want one that supports type annotations. I'm specifically want something that can generate large configuration structures (e.g., Kubernetes YAMLs, CloudFormation YAMLs, Terraform HCLs, etc) and I want some static typing because the iteration loops can be quite long (minutes) which is too long to test every branch and writing and maintaining unit tests to catch type…

Wildly underrated libTCC[1] might be a good fit.

[1] https://bellard.org/tcc/

Re: Pocketlang

#59

Post by nvarsj »

throwaway894345 wrote: post #25

I love these little embedded languages, but I really want one that supports type annotations. I'm specifically want something that can generate large configuration structures (e.g., Kubernetes YAMLs, CloudFormation YAMLs, Terraform HCLs, etc) and I want some static typing because the iteration loops can be quite long (minutes) which is too long to test every branch and writing and maintaining unit tests to catch type…

I guess no one mentioned jsonnet yet, but it's probably the most popular thing in use (along with ksonnet). But really, it's the most awful of the lot - where you have to program using a strange bastardization of JSON (Hello XML nightmares of the 90s/00s). Try using that for a while, and you'll be begging to use dhall-lang.

Re: Pocketlang

#60

Post by garethrowlands »

mirthless wrote: post #6

What about generic algorithms like filter/map. Is it python style like map(fn, filter(...))?

Isn't python style more about its built-in comprehensions and much less about generic functions?

    [fn x for x in ... if ...]
I know there's a `map` in, say, `multiprocessing.Pool`, but using that doesn't feel as natural as a comprehension in python or `map` in, say, Haskell or Kotlin.
Post reply on HN