What you're describing with parameter ordering is Lisp's Mysterious Tuple Problem [0]. It's also part of why Lisp works so well for one or only a few developers, but breaks down for large teams. Javascript (and Self before it) has really started a structural revolution with the JSON object as a syntactic form. I'm currently working on a language very similar to your last paragraph, where all objects do have such a field indicating their class, so an object in the textual representation might look like:
{ Point x 2 y 3 }
Instead of n-ary tuple operation like Lisp, my design limits all functional application/message sends to a form of a receiver object, message, optional it object, and additional map of args in the preceding syntactic way (still not sure if they would have a class or be classless). Multiple dispatch would be limited to just the receiver and the it object.
You can see in Smalltalk where this syntax would be helpful in the awkward selector syntax it adopts.
bool ifTrue: [block] ifFalse: [block]
Looks better as
bool if {
If
$then block
$else block
}
Where here the $ in slot names means the corresponding value isn't evaluated, a reference to the late John Shutt's Kernel [1] that explored replacing the lambda calculus at the base of Lisp with a lazy vau calculus in order to restore the historically maligned fexpr [2]. Originally they were removed from the language because they made compiling difficult at a time when performance really mattered (1980), and replaced with special forms that weren't first class subjects of the language (and neither really were the syntactic macros that accompanied them). Going back to the original topic, Alan Kay listed Lisp as one of the primary inspirations for Smalltalk, and especially the fexpr, which he saw as underappreciated:
> There were not just EXPRs (which evaluated their arguments), but FEXPRs (which did not). My next question was, why on earth call it a functional language? Why not just base everything on FEXPRs and force evaluation on the receiving side when needed? I could never get a good answer, but the question was very helpful when it came time to invent Smalltalk, because this started a line of thought that said "take the hardest and most profound thing you need to do, make it great, and then build every easier thing out of it". That was the promise of LISP and the lure of lambda—needed was a better "hardest and most profound" thing. Objects should be it. [3]
I'm still in search of the "hardest and most profound thing" - here's to hoping it's real.
I like your syntax, but wouldn't it be better as something like
{ Point :x 2 :y 3 }
or maybe:
{ Point x: 2 y: 3 }
that little bit of extra punctuation (only needs to be a single character) is really helpful in making clear what is the field and what is the value. Syntactic minimalism is great, but sometimes it is taken a bit too far
> Where here the $ in slot names means the corresponding value isn't evaluated
If parameters have type declarations, why not make laziness part of the type instead of part of the name?
I suppose it makes it clear at the invocation site that the parameter is lazy-evaluated. I wonder how important that is though? In Smalltalk, it is very clear, due to [] vs (). In most Lisps, you can't tell from the invocation site whether some symbol is an ordinary defun, or a special form or macro, you have to look up its definition or documentation. In my experience, that isn't a big problem – if you don't remember it, sooner or later you end up having to look it up anyway, to understand what the parameters mean and what it actually does.
I agree my syntax is quite spartan, though that's because I don't intend to rely on it as the user interface, but would rather extend to structured editing more like Self.
On the laziness part I'm torn - quoting is what that amounts to and it never seemed extremely elegant either. The call site disambiguation is nice for knowing whether you can compile something.
You can see in Smalltalk where this syntax would be helpful in the awkward selector syntax it adopts.
Looks better as Where here the $ in slot names means the corresponding value isn't evaluated, a reference to the late John Shutt's Kernel [1] that explored replacing the lambda calculus at the base of Lisp with a lazy vau calculus in order to restore the historically maligned fexpr [2]. Originally they were removed from the language because they made compiling difficult at a time when performance really mattered (1980), and replaced with special forms that weren't first class subjects of the language (and neither really were the syntactic macros that accompanied them). Going back to the original topic, Alan Kay listed Lisp as one of the primary inspirations for Smalltalk, and especially the fexpr, which he saw as underappreciated:> There were not just EXPRs (which evaluated their arguments), but FEXPRs (which did not). My next question was, why on earth call it a functional language? Why not just base everything on FEXPRs and force evaluation on the receiving side when needed? I could never get a good answer, but the question was very helpful when it came time to invent Smalltalk, because this started a line of thought that said "take the hardest and most profound thing you need to do, make it great, and then build every easier thing out of it". That was the promise of LISP and the lure of lambda—needed was a better "hardest and most profound" thing. Objects should be it. [3]
I'm still in search of the "hardest and most profound thing" - here's to hoping it's real.
[0] https://www.codeproject.com/Articles/1186940/Lisps-Mysteriou...
[1] https://web.cs.wpi.edu/%7Ejshutt/kernel.html
[2] https://fexpr.blogspot.com/2011/04/fexpr.html
[3] http://worrydream.com/EarlyHistoryOfSmalltalk/