5 ms·

Thanks! Yes I plan to have data literals -- it's basically going to be JSON, because that is sort of the least common denominator between JS, Python, Ruby, Per

by chubot 10y ago

Thanks! Yes I plan to have data literals -- it's basically going to be JSON, because that is sort of the least common denominator between JS, Python, Ruby, Perl, etc. Shell is a glue language, and JSON is pretty natural at this point. There is also going to be influence from R and CSV files (which goes with awk). I have thought about the config problem a lot -- and a configurable sandboxed "data mode" you are talking about is probably what I will go with. If you squint, the oil shell will look not unlike nginx configs, e.g. a bunch of words with nested {} for blocks. Maybe like https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl or https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl (hm this seems to even have here docs!) This kind of thing was done a lot with Python at my last job, to various degrees of success (e.g. https://bazel.build/ https://bazel.build/ - the build language is derived from Python). Python sort of has some "data mode" sandboxing features, like being able to set __builtins__ when you exec/eval, but probably not enough. It didn't work well enough to prevent people from writing their own config file parser eventually. The syntax is close but not exactly what you want for some use cases.

taeric 10y ago
I'm curious how far from just dropping to sexps you are looking. While I will not claim that lisp is the be all of languages, when you have a literal syntax that is literally made for linked structures, it becomes a lot easier to represent whatever you are wanting to do. And it you can keep yourself from having tons of "pseudo languages" that are used for different structures.
- chubot 10y ago
  I've mentioned this a few places so I should probably write a post about it, but I did experiment with Lisp and shell (using femtolisp which is used to bootstrap Julia). There is an obvious similarity in that they both have prefix rather than infix syntax. Tcl explored this design space pretty fruitfully as well. The short answer is that the experiment didn't work very well. If you want a shell based around Lisp, the new "oh shell" is closer to that. It has homoiconic syntax, which I don't agree with. I talked about that a bit here: http://www.oilshell.org/blog/2016/10/28.html http://www.oilshell.org/blog/2016/10/28.html The oh shell is influenced by the es shell, which was almost literally a Lisp. There is also EShell (ELisp) on my Github wiki, and earlier Scheme shell. So without going into too much detail, I think the idea has been tried and it has failed not by accident, but for fundamental reasons. That's not to say that Lisp isn't hugely influential. Julia and Elixir both have very Lisp-like metaprogramming which I hope to take some inspiration from. Without having tried it in detail yet, I think the lesson is that in 2017 you don't need homoiconity to have metaprogramming. And another lesson is that people like syntax (me included!) The shell especially needs syntax because it will often be typed in a terminal as opposed to in an editor with help.
  - taeric 10y ago
    I fully agree that lisp is not the answer for a shell. My question was only for your data literal syntax. Specifically, maps as association lists are very natural in lisp. So are many other structures. And JSON is easily seen as a crappy sexp. XML is easily a complicated sexp. Python's pickling is a complicated eval. And I get it. Some things have a more "natural" syntax that isn't postfix. Even in common lisp, the reader macro is often used for infix things. However, when the examples used are easily translated to sexps, and back, it makes me wonder why we don't think programmers could learn to write them.
    - chubot 10y ago
      The literal syntax is going to look more like JSON, like Python and JavaScript have. I don't see what's better about association lists (assoc (k v) (k2 v2)) vs. {k:v, k2: v2}. I mentioned in that blog post that Clojure introduced meanings for [] and {} in a Lisp, and I generally view that as a good thing. Also if that syntax is only used for data literals, and not code, then it loses the whole Lisp paradigm and I wonder why you would want that syntax.
      - lispm 10y ago
        > Clojure introduced meanings for [] and {} in a Lisp Lisp was using [] and {} before in a lot of software. For example this is a data structure in Connection Machine Lisp called Xapping, basically a parallel hash table: {moe->"Oh, a wise guy, eh?" larry->"Hey, what's the idea?" curly->"Nyuk, nyuk, nyuk!"} Straight from the 80s. Scheme was using [] also many years before in the standard, programs and books.
        taeric 10y ago
        My thought is that the confusion is most people are taught that lisp has no syntax. And that they should avoid the reader macro at all costs. Few, then, actually dive into large programs in lisp to see how real programs actually look. In this example, though, what was the advantage of the special syntax? (I'm assuming there was one. Just a lot of these parallel hash tables written in literal form?)

by chubot 10y ago

taeric 10y ago

I'm curious how far from just dropping to sexps you are looking. While I will not claim that lisp is the be all of languages, when you have a literal syntax that is literally made for linked structures, it becomes a lot easier to represent whatever you are wanting to do. And it you can keep yourself from having tons of "pseudo languages" that are used for different structures.

chubot 10y ago
I've mentioned this a few places so I should probably write a post about it, but I did experiment with Lisp and shell (using femtolisp which is used to bootstrap Julia). There is an obvious similarity in that they both have prefix rather than infix syntax. Tcl explored this design space pretty fruitfully as well. The short answer is that the experiment didn't work very well. If you want a shell based around Lisp, the new "oh shell" is closer to that. It has homoiconic syntax, which I don't agree with. I talked about that a bit here: http://www.oilshell.org/blog/2016/10/28.html http://www.oilshell.org/blog/2016/10/28.html The oh shell is influenced by the es shell, which was almost literally a Lisp. There is also EShell (ELisp) on my Github wiki, and earlier Scheme shell. So without going into too much detail, I think the idea has been tried and it has failed not by accident, but for fundamental reasons. That's not to say that Lisp isn't hugely influential. Julia and Elixir both have very Lisp-like metaprogramming which I hope to take some inspiration from. Without having tried it in detail yet, I think the lesson is that in 2017 you don't need homoiconity to have metaprogramming. And another lesson is that people like syntax (me included!) The shell especially needs syntax because it will often be typed in a terminal as opposed to in an editor with help.
- taeric 10y ago
  I fully agree that lisp is not the answer for a shell. My question was only for your data literal syntax. Specifically, maps as association lists are very natural in lisp. So are many other structures. And JSON is easily seen as a crappy sexp. XML is easily a complicated sexp. Python's pickling is a complicated eval. And I get it. Some things have a more "natural" syntax that isn't postfix. Even in common lisp, the reader macro is often used for infix things. However, when the examples used are easily translated to sexps, and back, it makes me wonder why we don't think programmers could learn to write them.
  - chubot 10y ago
    The literal syntax is going to look more like JSON, like Python and JavaScript have. I don't see what's better about association lists (assoc (k v) (k2 v2)) vs. {k:v, k2: v2}. I mentioned in that blog post that Clojure introduced meanings for [] and {} in a Lisp, and I generally view that as a good thing. Also if that syntax is only used for data literals, and not code, then it loses the whole Lisp paradigm and I wonder why you would want that syntax.
    - lispm 10y ago
      > Clojure introduced meanings for [] and {} in a Lisp Lisp was using [] and {} before in a lot of software. For example this is a data structure in Connection Machine Lisp called Xapping, basically a parallel hash table: {moe->"Oh, a wise guy, eh?" larry->"Hey, what's the idea?" curly->"Nyuk, nyuk, nyuk!"} Straight from the 80s. Scheme was using [] also many years before in the standard, programs and books.
      - taeric 10y ago
        My thought is that the confusion is most people are taught that lisp has no syntax. And that they should avoid the reader macro at all costs. Few, then, actually dive into large programs in lisp to see how real programs actually look. In this example, though, what was the advantage of the special syntax? (I'm assuming there was one. Just a lot of these parallel hash tables written in literal form?)