oh-lang decided to avoid using periods for member access, e.g.
a small reason: member access is used quite frequently, so using a space makes sense as long as we can determine if member access is intended from context. there are some somewhat complicated rules for it, but nothing that a computer can't figure out. (i also think i can simplify the parser a bit after the bootstrap.)
the big reason: we wanted to support three types of declarations in oh-lang: readonly, writable, and temporary. these affect how you interact with the variable but do not change the underlying variable data. we wanted
as a perk, UFCS, which oh-lang will support, makes slightly more sense without a full-stop member access operator. e.g.,
one downside is the lack of a convenient "figure-this-nested-field-out" symbol, which is used in languages like Zig for great effect. for example, suppose your function takes an enum. in Zig, you can use
†: alternatives would have been
some_object some_field. in most languages (python, Rust, C, etc.), a period is used. there are a couple reasons for breaking with tradition.
a small reason: member access is used quite frequently, so using a space makes sense as long as we can determine if member access is intended from context. there are some somewhat complicated rules for it, but nothing that a computer can't figure out. (i also think i can simplify the parser a bit after the bootstrap.)
the big reason: we wanted to support three types of declarations in oh-lang: readonly, writable, and temporary. these affect how you interact with the variable but do not change the underlying variable data. we wanted
: to be a good default, to help with muscle memory and the novelty budget, so it was decided to be the readonly declaration, readonly_variable: #str. we used ; to make writable variables and . seemed like a decent temporary variable declarer, e.g., temp_var. #int.† this overloads a bit with real-number parsing, but so does member access in most other languages. (9.1234.toString() looks a bit weird in JavaScript!)
as a perk, UFCS, which oh-lang will support, makes slightly more sense without a full-stop member access operator. e.g.,
my_vector length() and length(my_vector) is just shuffling around the parts of the expression.
one downside is the lack of a convenient "figure-this-nested-field-out" symbol, which is used in languages like Zig for great effect. for example, suppose your function takes an enum. in Zig, you can use
.my_great_enum_value instead of MyEnumName.my_great_enum_value when it is clear from context. here's a full worked example:
// Zig
const std = @import("std");
const print = std.debug.print;
const MyEnum = enum {
wow,
not_wow,
};
fn doStuff(my_enum: MyEnum) void {
switch (my_enum) {
.wow => print("WOW\n", .{}),
.not_wow => print("ok, not cool\n", .{}),
}
}
pub fn main() void {
doStuff(.not_wow);
}
this is so convenient that i don't know why Rust doesn't do this -- since it's strongly typed and does not allow overloads. because oh-lang doesn't have a member-access operator per se, it uses an "infer-this-type" token #~ to do a similar thing. a translation to oh-lang of the above would be:
#my_enum: #one_of
[ wow:
not_wow:
]
do_stuff(my_enum:): #null
{ what my_enum
#~ wow { print("WOW") }
#~ not_wow { print("ok, not cool") }
}
main(): #null
do_stuff(#~ not_wow)
because oh-lang allows function overloading, inferring types may not always work. in case you have multiple overloads with enum values shared among multiple enums (probably not ideal!), you'd need to pass fully-qualified value of #my_enum not_wow into the function do_stuff. the infer-this-type token #~ has some additional uses and natural extensions, so it feels like a good fit for oh-lang, which avoids using a full stop for member access.
†: alternatives would have been
@ and $, but we want to reserve these for compiler macros and lambda expressions, respectively. also temp_var$ #int doesn't really look like a declaration; temp_var@ #int has some charm but keeping declarations all looking like punctuation ;:. has some mental cohesion to it.
Comments
Post a Comment