Tea expression language ideas

[andychu]

Continued from #835

Tea Language

Semantic changes

• I think we need a ?? operator that is like or, except it returns the first argument if it's non-null (None), not if len(x) == 0. This matches C semantics.
  • this replaces ${x:-'default'} too? That currently doesn't work on integers. It can be $[x ?? 'default'] instead
• I don't like in on lists (fixed too many accidentally quadratic bugs). It good for dicts, and maybe acceptable for strings ...

Prettier

• multiline strings should strip leading space of closing delimiter (and probably disallow anything on first line?)
• removed in favor of $[x] and _ESCAPE Tagged prefixes for strings. In addition to r'foo', maybe we want html'foo' or html"foo", sql'foo'
  • or we could copy JS strings which use backticks
• (Tea language) Func[Int, Str => Int] instead of Func[[Int, Str], Int]
• maybe optional sigils like push!(x) and even?(i)

New functionality:

• => for method call, universal function call on first arg type
  • or should we use |> because there seems to be a consensus on this? R jus built in support for it: https://news.ycombinator.com/item?id=25316608
  • Is it pipefirst or pipelast?
  • Do we need a lazy vs. eager syntax for it? So we can compile to SQL like dplyr does?
  • I think we want to do Commands could take (lazily evaluated) expressions #955 with where [size > 10 K] before doing this. That uses a literal Unix pipe, not a function chaining operator.
• maybe: overflow operators ... &+ and &* -- language semantics shouldn't depend on the compiler #824
  • note: Zig has modulus and remainder operators for unsigned; we don't have unsigned yet

[andychu]

The FAQ brought up the => vs. |> issue:

http://www.oilshell.org/blog/2021/02/new-faqs.html

A bunch of possible ways to write this:

var line =  _line.strip()
var line =  _line |> strip()
var line =  _line => strip()

_ _line => strip() => var line  # it's annoying that there's a _ here

_ _line |> strip() |> var line

Maybe we can have a keyword in addition to _, like

exp _line => strip() => var line  # exp and not expr ?  pass was ruled out.  

Note Ubuntu has exp in alliance package, which is a calculator: http://manpages.ubuntu.com/manpages/trusty/man1/exp.1.html

EXPR _line => strip() => var line
Expr _line => strip() => var line  # this is possible ...

Also someone brought this up:

=> _line => strip() => var line
|> _line |> strip() |> var line  # possible problem: |> is two tokens that would require lookahead

Actually => is not that bad:

• We're already detecting = as a keyword`
• We might detect _ <span>foo</span> as a keyword for "Pulp"

[andychu]

Random idea from https://oilshell.zulipchat.com/#narrow/stream/121540-oil-discuss/topic/left-to-right.20syntax.20ideas

Allow obj!method() for mutating methods, in addition to obj.method()! It could be a matter of convention.

Or it could be the more conventional:

obj.method!()
myfunc!(x)

Or the ! could tell you which one is mutated!

obj.method!(x)  # mutates x
obj!method(x)  # mutates obj

[andychu]

Idea: get rid object.method() syntax altogether

Get rid of _ mylist.append(x)

Maybe:

append :mylist foo bar

_ append(mylist, %(foo bar))

# if parse_paren is on:


append(mylist, %(foo bar))

• ksh style function definition can still be used for the latter
  • function f { echo hi }
  • though very discouraged!
• problem: doesn't this break EVERYTHING in Oil?
  • I guess it only breaks f(), it doesn't have to break f(arg)
• f( - ) could be an alternate? Or call f(), or _ f()

[andychu]

Related to #950

[andychu]

Oil issues moved to #980. This is now low priority

[andychu]

This experiment is obsolete -- we're now doing a Yaks IR first, with Lispy syntax

See #yaks channel on Zulip