Change impactful parts of the surface syntax (again)

[fmease]

You know, personal taste can change over the years. Some of these are not super well motivated I guess, it comes down to my perceived sense of esthetics. Also, every time I come back to the project after a long break, I always get negatively surprised by my past syntax choices (scales falling of my eyes) and want to do sth. about it (thereby avoiding the more important tasks).

• (impl) comment prefix: ;;; → #
  • Historical context: Ages ago I was quite fond of / enamored in ; as a comment marker as used by many(?) assembly dialects. However over the years the ; got essentially "corrupted into" ;;; (initially ; → ;; to make ; start doc comments instead (to "heighten their status"); then, ;; → ;;; to make room for ; as an alternative declaration terminator which was subsequently removed without updating the comment grammar).
  • # is neat. I don't like Haskell-lineage -- (esp. if you can "break" it by attaching more symbols (e.g., in Haskell $-- or --| are operators) which doesn't feel robust) and C-lineage // doesn't feel right in a ML/Haskell-style language. Regarding ML-lineage (* *) block comments, well I still don't want block comments in Lushui (albeit my opinion is no longer that strict/quixotic) because of "lexical simplicity" and since block comment nesting is an unsolvable problem / rabbit hole. Also, (* specifically, that would clash with other lexical features like *-as-identifier (I don't want you to add extra spaces when writing (* 1 2) (( * 1 2))))
  • No longer need to special case shebangs #! since they're just comments
• (doc/spec) comment prefix: ;; → #|
  • One con: # no longer unconditionally starts a comment. That means you have to add a space after the # when commenting out sth. starting with |. In practice that's always done anyway but I've seen conventions where lack of space signifies commented-out code as opposed to prose / actual comment. Well, we could think about swapping # and #| (and change #| to e.g. #.)? Hmm. Or keeping #| as doc/spec comment and change impl comments to e.g. #. from #. This would permit us to intro a third kind of comment (which I always wanted (not an original idea tho)): "rich"/"checked"/"semantic" impl comments. Let's call them #: here. These would the same dialect of markup language like doc comments #| be it asc**doc or custom-made (of Haddock or MarkDown lineage). Most importantly, they would feature intra-doc links that will get checked by lushui doc or lushui build. Hyperlink (liveness) checking is probably out of scope but that could also be a feature (opt-in ofc)-
  • Slightly unrelated but we can update ui_test_framework's test parameter syntax from ;;; TEST to e.g. #? or #@ (or #.? / #.@, see paragraph above) which looks so much nicer (for devs)
• function declarations: No prefix → func
  • Allows for IDE-free Ctrl+F'ing for def site
  • Synchronization point for parse error recovery (that's why let (Lushui in 2019) is not a super great option either because it would conflict with let/in-expressions ("conflict" wrt. to error recovery that is)
  • Will probably make everything more legible since the eye has common patterns to "focus on" when skimming. Human synchronization points basically
• abolishing hyphens/dashes from the lexical grammar of words (category of identifiers); rephrased, migrating from dash/kebap-case(with _ being permitted, too) to pure snake case. It's always been awkward to have _ as a discard and wildcard (hole) but being dash-case first everywhere. for types the convention changes from (proper) upper dash case to (proper) upper snake case (Letter-Case → Letter_Case).
  • It was a cute idea but it's simply not realistic
• attributes from @simple / @(complex ...) to { simple } / { complex ... } plus allowing contractions via ,. E.g., { first } { two } to { first, two } (maybe we could even remove conseq attrs {a} {b} ... altogether? they lead to nasty hacks in the grammar (since they can be split across lines while still being considered 'together' despite "Line_Break==Decl_Terminator"))
  • having the split between simple and complex / unbracketed and bracketed is an eye-sore, it always has been, though I never admitted that. it's awkward to go from simple to complex, multiple steps are involved (e.g. jumping, not just inserting). esp. annoying if you used the simple form by accident
  • I always hated the idea of having to annotate all my component-public&transparent functions(…) with @(public topmost) @transparent (here we assume that transparent's reach defaults to public's reach). { public topmost, transparent } is more bearable I think (tho I haven't written larger Lushui programs yet, no experience/feel yet)
  • This means we have to update the syntax for record literals. We might want to merge the syntax of sequence literals ((), (x0,), path.(x0), (x0, x1, ..., xn), etc.) and record literals ({}, {p0 = x0, p1 = x1, ..., pn = xn; base}, etc.). Leaves the question of whether to merge the concepts too or not. In the latter case we would have to find a replacement for {} since it can't be () (the = disambiguates)). Several indie languages use [=] if [] reprs seq. However, in Lushui that would be (=) which looks very wrong. I guess we could permit trailing ; (empty base expr) and make (;) record unit. Hmmm, well, but don't we want base exprs for seqs too (e.g. for flatten/join/merge ops)?

Example

Current

;; Module-level documentation
module

;;; Some internal comment. Some internal comment.
;;; Some internal comment. Some internal comment.

;; These are the public-facing docs.
@(public topmost) @transparent
perform-it 'A [Operate-It A] (a: A): A =
    Operate-It.operate-it a

Then:

#| Module-level documentation
module

# Some internal comment. Some internal comment.
# Some internal comment. Some internal comment.

#| These are the public-facing docs.
{ public topmost, transparent }
func perform_it 'A [Operate_It A] (a: A): A =
    Operate_It.operate_it a

[fmease]

Ah I forgot (it's an older idea): Swap -> and =>. => is less visually appealing to me and therefore I don't want to see it everywhere but it's in all case/of's and lambdas. Furthermore, writing pi types "directly" (instead of via the sugar) is rarer.
Another reason: We go for uppercase for type formers/constructors. Cf. For vs. for. And to me, => is "more uppercase" than -> and should therefore be used in conjunction with For (and -> with for).

[fmease]

Problem: Constructors in data decls and fields in record decls are just functions syntactically because data/… decls contain a list of normal declarations (since we also want to support use-decls inside data decls for enabling symbol aliases). However, I don't want ctors or fields to get prefixed with func that's way too distracting and frankly hideous.

[fmease]

I guess I'm fine with adding a prefix for ctors & fields (needn't be the same) as long as they're not func. Ideally, they'd all share the same prefix but it's not strictly necessary.

[fmease]

Maybe we need to go for def after all … but do I really want defmod, defunion, deftrait, defrecord??? (I'd hate to have a generic "def"(inition) and keep module, data, … since those are also definitions).

[fmease]

I briefly thought about

union Bool
    of false
    of true

record Duple A B
    of first: A
    of second: A

func not (x: Bool): Bool = x case
    of Bool.false -> Bool.true
    of Bool.true -> Bool.false

but that's completely incompatible with our current indentation system that relies on "herrings" before line breaks.

Also, while of feels very fitting for union ctors and case/of, it feels slightly off for record/trait fields or match/withof if we wanted to somehow unreserve the common word "case"