Glyphs and Latin

Glyphs and operators#

Faber sử dụng các glyph, trong đó ký hiệu mang vai trò cấu trúc. Dưới đây là toàn bộ danh mục glyph nguồn được lexer nhận diện.

Luồng giá trị#

Hình dạng kiểu#

So sánh#

Logic và thao tác bit#

Cập nhật phép gán#

Chuỗi tùy chọn và khẳng định khác nihil#

Khoảng#

Dấu phân cách literal#

Dấu câu#

Latin vocabulary and structural glyphs#

Ba lựa chọn tín hiệu giúp nhận ra mã nguồn Faber ngay từ cái nhìn đầu tiên.

Faber đưa ra ba lựa chọn tín hiệu có chủ đích. Chúng phối hợp để tạo ra mã nguồn có hình thái ngữ pháp ổn định. Người đọc có thể nhận ra vai trò ngữ nghĩa của từng cấu trúc trước khi biết mã nguồn sẽ được biên dịch sang backend đích nào.

Ba tín hiệu#

Ba tín hiệu này được thiết kế để củng cố lẫn nhau. Người đọc biết Faber ở một bản địa hoá có thể đọc nó ở bất kỳ bản địa hoá nào khác vì ký hiệu và cấu trúc không thay đổi. Người đọc biết backend Rust vẫn có thể nhận ra mã nguồn Faber vì các từ khoá Latin và thứ tự kiểu-trước tạo nên một diện mạo riêng biệt.

Khai báo đặt kiểu trước#

Faber đặt kiểu trước tên trong mọi khai báo. Đây là điều ngược lại với cú pháp họ C phổ biến, và đó là chủ ý:

Khai báo đặt kiểu trước có nghĩa là hình dạng của dữ liệu là điều đầu tiên người đọc nhìn thấy. Điều này tự nhiên phù hợp với các ngôn ngữ đọc từ trái sang phải theo độ bao quát ngữ nghĩa — khai báo trong tiếng Trung, tiếng Hindi và tiếng Ả Rập cũng theo cùng thứ tự.

hàm divide(số a, số b) → số ∪ rỗng {
    nếu b ≡ 0 do_đó trả rỗng
    trả a / b
}

Từ vựng hành vi bằng tiếng Latin#

Faber sử dụng các từ Latin cho mọi cấu trúc có hình dạng hành vi hoặc ngữ pháp. Từ vựng này nhỏ và đều đặn. Nó bắt nguồn từ một nguồn cổ điển duy nhất thay vì có nhiều nguồn từ nguyên pha trộn như trong hầu hết ngôn ngữ lập trình.

Khai báo#

Liên kết và truyền giá trị#

Luồng điều khiển#

Từ vựng Latin có thể liên kết — nó được cung cấp trong gói chuẩn nhưng có thể ánh xạ lại thông qua bản địa hoá người đọc. Lập trình viên Thái thấy ถ้า thay cho si; lập trình viên Trung Quốc thấy 函数 thay cho functio. Từ vựng không có đặc quyền; chỉ ngữ pháp là cố định.

Ký hiệu cấu trúc#

Trong khi từ vựng hành vi sử dụng các từ Latin, ý nghĩa cấu trúc sử dụng các ký hiệu phổ quát. Các ký hiệu này không bao giờ được bản địa hoá và không bao giờ thay đổi ý nghĩa giữa các lần kết xuất. Chúng là điểm neo trực quan giúp nhận ra mã nguồn Faber bất kể từ khoá được hiển thị bằng ngôn ngữ nào.

Luồng giá trị#

Hình dạng kiểu#

So sánh và logic#

Quy ước liên kết rất quan trọng#

Một lựa chọn ký hiệu cần được chú ý đặc biệt vì đây là điểm gây nhầm lẫn phổ biến nhất đối với người đọc mới:

Hầu hết ngôn ngữ dùng = cho cả “định nghĩa trường này trong một kiểu” và “đặt một giá trị thời gian chạy vào biến này”. Faber tách hai nhiệm vụ đó. Mọi ← đều là luồng dữ liệu đang hoạt động; mọi = bên trong Type { … } đều là bố cục trường của genus.

# Runtime binding: ← attaches a value to a name
fixum numerus count ← 0
varia textus label ← "ready"
count ← count + 1

# Structural shape: = defines field values inside a literal
fixum _ p ← Point {
    x = 10,
    y = 20
}

So với các ngôn ngữ phổ biến#

Bảng dưới đây cho thấy các mẫu lập trình phổ biến ánh xạ thế nào vào hệ thống ba tín hiệu của Faber. Cột Faber sử dụng một ký hiệu hoặc từ khoá khác nhau cho từng nhiệm vụ ngữ nghĩa riêng biệt — không nạp chồng.

Tham khảo#

1. Ngữ pháp EBNF — danh mục đầy đủ các ký hiệu và từ khoá
2. examples/corpus/ — kho ngôn ngữ với 292 tệp ví dụ bao phủ mọi từ khoá
3. examples/corpus/operatores/ — các ví dụ về toán tử và ký hiệu
4. Các điều răn — chín quy luật thiết kế bảo toàn các tín hiệu này

Canonical vs sugar surfaces#

Nhiều bề mặt có thể phân tích, một hình dạng ngữ nghĩa duy nhất.

Một mẫu thiết kế lặp lại trong Faber: ngôn ngữ định nghĩa một cách viết chuẩn cho mỗi cấu trúc, nhưng chấp nhận nhiều cách viết đường tắt có ngữ nghĩa tương đương. Trình biên dịch không ưu tiên cách nào — cả hai đều được phân tích thành cùng một nút AST. Bộ định dạng quyết định cách viết nào sẽ được xuất ra dựa trên ngữ cảnh và chế độ.

Quy tắc: Các cách viết đường tắt có ngữ nghĩa tương đương với dạng đầy đủ. Nhiều bề mặt được phân tích thành cùng một HirAnnotation hoặc nút kiểu. faber format --canonical ưu tiên cách viết chuẩn; chế độ tác giả giữ nguyên cách viết đường tắt mà tác giả đã dùng.

Đường tắt kiểu số#

Các kiểu số có cách viết chuẩn dạng đầy đủ và các dạng đường tắt nhỏ gọn. Lựa chọn này áp dụng theo từng mô-đun, không phải theo từng kho mã — một gói CLI có thể dùng dạng đầy đủ ở mọi nơi, trong khi một mô-đun nhân tensor dùng dạng đường tắt:

Faber thông thường (ưu tiên dạng đầy đủ):

hằng danh_sách<f32> values ← tập_rỗng

hằng ten_xo<f32, [2, 3]> grid ← tập_rỗng

hằng số<i32> narrow ← 7

Các mô-đun số (ưu tiên dạng đường tắt):

hằng danh_sách<f32> values ← tập_rỗng

hằng ten_xo<f32, [2, 3]> grid ← tập_rỗng

hằng số<i32> narrow ← 7

Đường tắt chỉ dùng ở vị trí kiểu. Các định danh giá trị có tên f32, tf32 hoặc mf32 vẫn giữ nguyên — trình biên dịch chỉ diễn giải chúng là đường tắt khi chúng xuất hiện ở vị trí kiểu. Một tệp sử dụng đường tắt nhất quán nên khai báo điều này một lần ở đầu tệp:

# STYLE: numeric sugar (tf32, mf32, sf32, lf32, lu32)

Đường tắt chú thích#

Chú thích Faber tuân theo cùng mô hình hai bề mặt như kiểu số. Chú thích là siêu dữ liệu do trình biên dịch sở hữu, được gắn vào các khai báo — chẳng hạn @ optio cho định nghĩa tùy chọn CLI hoặc @ futura cho các hàm bất đồng bộ.

Dạng chuẩn: một bản ghi có ngoặc nhọn với tên trường rõ ràng:

@ optio {
    binding = verbose,
    brevis = "v",
    longum = "verbose",
    typus = bivalens,
    ubique = verum,
    descriptio = "Enable verbose output"
}

Dạng đường tắt: các đối số theo vị trí và bí danh có tên:

@ optio verbose brevis "v" longum "verbose" typus bivalens ubique descriptio "Enable verbose output"

Cả hai dạng đều tạo ra cùng một bản ghi HirAnnotation. Dạng chuẩn rõ ràng và tự mô tả; dạng đường tắt ngắn gọn cho các chú thích được dùng thường xuyên, khi thứ tự trường đã được quy ước rõ. faber format --canonical ưu tiên các bản ghi có ngoặc nhọn; chế độ tác giả giữ nguyên dạng mà tác giả đã chọn.

Định dạng theo tác giả và dạng chuẩn#

Lệnh faber format hoạt động ở hai chế độ, phản ánh nguyên tắc dạng chuẩn và dạng đường tắt:

Cả hai chế độ đều đi qua toàn bộ phần đầu của trình biên dịch (phân tích từ vựng, phân tích cú pháp, phân tích ngữ nghĩa đối với chế độ chuẩn). Mã nguồn không hợp lệ sẽ tạo ra chẩn đoán của trình biên dịch — bộ định dạng không âm thầm định dạng đầu vào bị lỗi.

Các quy tắc chính áp dụng cho cả hai chế độ:

• Thụt lề bốn khoảng trắng
• Dấu ngoặc Stroustrup: dấu { mở nằm trên cùng dòng với phần đầu điều khiển
• Chế độ tác giả giữ nguyên sự hiện diện của các dòng trống nhưng thu gọn các chuỗi dài hơn một dòng
• Chế độ tác giả không chèn các dòng trống mà mã nguồn không có
• Chế độ chuẩn chuẩn hóa cách viết kiểu về dạng đầy đủ, tensor đường tắt về dạng chuẩn, và chú thích về bản ghi có ngoặc nhọn
• Chế độ chuẩn xuất T ∪ nihil cho các hợp nullable, và sponte cho các tham số tùy chọn

Nguyên tắc thiết kế#

Mẫu dạng chuẩn và dạng đường tắt xuất hiện ở nhiều nơi vì đây là một nguyên tắc thiết kế có chủ ý, không phải tập hợp các tiện ích riêng lẻ:

Mẫu này phục vụ hai mục tiêu. Thứ nhất, nó hạ thấp rào cản tiếp cận — người dùng mới có thể viết tf32[4] mà không phải gõ tensor<fractus<f32>, [4]>. Thứ hai, nó giữ cho ngôn ngữ chuẩn không mơ hồ — khi độ chính xác quan trọng, dạng đầy đủ nói chính xác ý nghĩa của nó. Bộ định dạng kết nối hai dạng này: tác giả viết dạng đường tắt, người đánh giá có thể yêu cầu dạng chuẩn, và CI có thể thực thi một trong hai.

Tham chiếu#

1. radix/docs/design/numeric-type-sugar.md — các họ đường tắt đầy đủ, ưu tiên cách viết
2. radix/docs/design/annotation-sugar.md — mô hình chú thích hai bề mặt
3. radix/docs/design/faber-canonical-surface.md — chính sách định dạng theo tác giả và dạng chuẩn
4. faber/docs/EBNF.md — các bảng ngữ pháp cho dạng đường tắt