Replace Titan with Pallene in comments of coder.lua
@@ -26,15 +26,15 @@ end
-- In Decl nodes. (see @decl)
--
-- _lua_entry_point:
--- _titan_entry_point:
+-- _pallene_entry_point:
-- In Toplevel.Func nodes.
--- Names of the C functions that we generate for each titan function
+-- Names of the C functions that we generate for each pallene function
--
-- _layout:
-- In Toplevel.Record nodes. (see @records)
local whole_file_template = [[
-/* This file was generated by the Titan compiler. Do not edit by hand */
+/* This file was generated by the Pallene compiler. Do not edit by hand */
/* Indentation and formatting courtesy of pallene/pretty.lua */
#include <string.h>
@@ -108,12 +108,12 @@ end
local function c_float(n)
-- Use hexadecimal float literals (%a) to avoid losing any precision.
-- This feature is part of the C99 and C++17 standards. An alternative
- -- C89-compatiple solution might be to refactor the Titan compiler to
+ -- C89-compatiple solution might be to refactor the Pallene compiler to
-- represent float literals as strings instead of as numbers.
return string.format("%a /*%f*/", n, n)
end
--- @param type Type of the titan value
+-- @param type Type of the pallene value
-- @returns type of the corresponding C variable
--
-- We currently represent C types as strings. This suffices for primitive types
@@ -1662,7 +1662,7 @@ local function generate_unop(op, exp, ctx)
end
-- Relational operators, and basic float operations have the same semantics in C
--- and in Lua / Titan.
+-- and in Lua / Pallene.
local function generate_binop(op, exp, ctx)
local x_stats, x_var = generate_exp(exp.lhs, ctx)
local y_stats, y_var = generate_exp(exp.rhs, ctx)
@@ -1682,7 +1682,7 @@ local function generate_binop(op, exp, ctx)
return cstats, r.name
end
--- For integer arithmetic operators Lua/Titan mandates well-defined
+-- For integer arithmetic operators Lua/Pallene mandates well-defined
-- two's-compliment wraparound in case of overflow.
local function generate_intop(op, exp, ctx)
local x_stats, x_var = generate_exp(exp.lhs, ctx)
@@ -1744,7 +1744,7 @@ local function generate_unop_intneg(exp, ctx)
return cstats, r.name
end
--- Lua/Titan integer division rounds to negative infinity instead of towards
+-- Lua/Pallene integer division rounds to negative infinity instead of towards
-- zero. We inline luaV_div here to give the C compiler more optimization
-- opportunities (see that function for comments on how it works).
local function generate_binop_idiv_int(exp, ctx)
@@ -1779,7 +1779,7 @@ local function generate_binop_idiv_int(exp, ctx)
return cstats, q.name
end
--- Lua/Titan guarantees that (m == n*(m//n) + (,%n))
+-- Lua/Pallene guarantees that (m == n*(m//n) + (,%n))
-- See generate binop_intdiv and luaV_mod
local function generate_binop_mod_int(exp, ctx)
local m_stats, m_var = generate_exp(exp.lhs, ctx)
@@ -1851,7 +1851,7 @@ local function generate_binop_pow(exp, ctx)
return cstats, r.name
end
--- In Lua and Titan, the shift ammount in a bitshift can be any integer, but in
+-- In Lua and Pallene, the shift ammount in a bitshift can be any integer, but in
-- C shift ammount must be a positive number less than the width of the integer
-- type being shifted. This means that we need some if statements to implement
-- the Lua shift semantics in C.
