imagine a language like Lua except every table literal is actually a block of code that is run like a module. for example:

let someTable = {
    export someValue = "foo"
    let privateValue = "bar"
}

print(someTable.someValue)
# prints "foo"

print(someTable.privateValue)
# error

that would mean that when you require("someModule") you’re essentially wrapping the entire someModule file inside of { } and getting the result

it would make table literals more noisy but it would also let a Lua-like language have even fewer concepts that need to be learned in order to understand it

plus, you could define a whole class inside of one set of { } which would make the syntax mirror how most other languages do classes - and create a visual divide between the class and any unrelated stuff that might exist in the same file:

let SomeClass = {
    export new = (value) -> {
        let newInstance = {
            let privateValue = value
        }

        setmetatable(newInstance, this)
        return newInstance
    }

    export getValue = (this) -> {
        return this.privateValue
    }

    export setValue = (this, value) -> {
        this.privateValue = value
    }
}

let instance = SomeClass.new("foo")

you could even make it so that if you return inside of { } then the whole { } block evaluates to whatever you returned, so you can have multiple statements inside of your expressions (and not just table expressions) just like in Lisp:

let fibonacciNums = {
    let a, b = 0, 1
    let nums = {}

    for _ in range(100) do
        a, b = b, a+b
        list.push(nums, a)
    end

    return nums
}

print(fibonacciNums)
# {1, 1, 2, 3, 5, ...}

come to think of it, you could fix the noisiness by having two sets of syntax: the usual long-form { } syntax and a short-form [ ] syntax for when you want to make a simple, quick literal:

let someNums = [1, 2, 3, 4]
let aDict = [
    "foo" = "bar",
    "baz" = "qux",
    1337 = 7331,
]

both would create the same type of value (a Lua-style table) but one would be a shortened form of the other

@kasdeya oh my god I’m interested. I’ve been looking at writing my own language based on table literals and I love the idea that a table is just. the set of public variables from a block of code. that’s so snazzy.

@nycki I’m so glad you like the idea so much! 💙

@kasdeya have you seen any of my posts about nift? my original idea was “json and xml are both kinda noisy, what if I wrote a language based on having the absolute minimal object structure”

so for instance a niftie that represents an html div with children might look like this:

(div id main (
  (h1 "Lorem Ipsum")
  (p "Dolor sit amet.")
))

some ideas I am debating:

• quotes are optional around one-word strings
• key-value pairs do not require any additional syntax, the “keys” of a dictionary are just the even-numbered items
• for html/xml specifically, you can treat the final element of a list as its “child node”

@nycki I haven’t unfortunately, but I love this! when I was younger I experimented with a ton of different languages that transpiled into HTML, but they often had weird implicit rules or syntax that I had a hard time getting an intuition for. this feels dead simple, easy to learn, and much easier to read too

quote are optional around one-word strings

hmm, another possibility would be to steal from Lisps (especially Fennel) and have one-word strings be quotable using a prefixed : like this:

(div
  ((p class :foo "Hello, world!")
   (p class :bar "some text")))

I think that would probably be how I would do it (edit: actually, I guess in this case class doesn’t need to be quoted but foo does, but what makes class special here? maybe it would be :class :foo instead)

also I’m curious what JSON would look like in nift! JSON is already fairly terse, but has some annoying syntax rules (like no leading commas, and no comments allowed)

@kasdeya converting json to nift is easy if you agree that a dict is just a list of alternating keys and values, the problem is that then to convert back you need a schema that says which is which; the type information is lost. thats been the bottleneck; i need to write a language for “re-hydrating” nifties.

{
  entries: [
    {
      "name": "andrew",
      "numbers": [413, 612]
    },
    {
      "name": "boo",
      "numbers": [23, 19],
    }
  ]
}

entries (
  (
    name andrew
    numbers (413 612)
  )
  (
    name boo
    numbers (23 19)
  )
)

@nycki ohh - that definitely makes sense! you almost need like a database schema or something. that sounds like an interesting problem to solve. maybe you could even include type information in the schema, so that the nifty could be type-checked at the same time that it’s being converted