From 41529a7b4597877a3ad3c54a7bbe6b1c7d26ca2f Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 01:52:30 +0200 Subject: [PATCH 001/116] fix mistake in rusts-into-in-scala --- _languages/rusts-into-in-scala.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/_languages/rusts-into-in-scala.md b/_languages/rusts-into-in-scala.md index 8ea4c1fe..67d73e8f 100644 --- a/_languages/rusts-into-in-scala.md +++ b/_languages/rusts-into-in-scala.md @@ -87,9 +87,11 @@ The only drawback is that, similar to Rust, the conversion method `into` needs t #### Java's Supplier -Perhaps amusingly, it's also possible to completely forgo the definition of our own `Into` type in favor of using Java 8's [`Supplier`](https://docs.oracle.com/javase/8/docs/api/java/util/function/Supplier.html) interface: +Perhaps amusingly, it's also possible to completely forgo the definition of our own `Into` type in favor of using Java 8's +[`Supplier`](https://docs.oracle.com/javase/8/docs/api/java/util/function/Supplier.html) interface +(adjusting the types in the approaches above from `Into` to `Supplier accordingly): - def strings(s: Supplier[String]) = s.into + def strings(s: Supplier[String]) = s.get ... and that's it! From 0a9475507bc0b401cd7a4a7549c1712f085fcc00 Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 02:45:46 +0200 Subject: [PATCH 002/116] hide some wip pages --- _languages/alasca/classes-values.md | 1 + _languages/alasca/collections.md | 3 ++- _languages/alasca/conditions.md | 1 + _languages/alasca/functions.md | 1 + _languages/alasca/identity-equality-hashcode.md | 1 + _languages/alasca/keywords.md | 1 + _languages/alasca/modifiers.md | 1 + _languages/alasca/modules.md | 1 + _languages/alasca/standard-library.md | 3 ++- _languages/alasca/streams.md | 1 + _languages/alasca/string-text.md | 1 + _languages/alasca/syntax-overview.md | 1 + _languages/alasca/traits-sealed-enum.md | 1 + _languages/alasca/typeclasses.md | 1 + _languages/alasca/visibility-exports.md | 1 + _languages/equality-and-identity-part5.md | 1 + _languages/naming-conventions-lookup.md | 1 + _languages/naming-conventions-stream.md | 1 + _languages/threads-futures-async.md | 1 + 19 files changed, 21 insertions(+), 2 deletions(-) diff --git a/_languages/alasca/classes-values.md b/_languages/alasca/classes-values.md index 2975afe0..1744cd70 100644 --- a/_languages/alasca/classes-values.md +++ b/_languages/alasca/classes-values.md @@ -1,6 +1,7 @@ --- title: "Alasca: Classes and Values" date: 2018-08-31 12:00:00 +0200 +published: false --- - `class`: reference type diff --git a/_languages/alasca/collections.md b/_languages/alasca/collections.md index 0c75289c..b2f60258 100644 --- a/_languages/alasca/collections.md +++ b/_languages/alasca/collections.md @@ -1,6 +1,7 @@ --- title: "Alasca: Collections" date: 2018-08-31 12:00:00 +0200 +published: false --- - collections are immutable @@ -35,4 +36,4 @@ value SizeInfo object Unknown value Known(Size) value Bounded(Size) -``` \ No newline at end of file +``` diff --git a/_languages/alasca/conditions.md b/_languages/alasca/conditions.md index 1b513378..2cc559b6 100644 --- a/_languages/alasca/conditions.md +++ b/_languages/alasca/conditions.md @@ -1,6 +1,7 @@ --- title: "Alasca: Conditions" date: 2018-08-31 12:00:00 +0200 +published: false --- See [Unified Condition Syntax](https://soc.github.io/languages/unified-condition-syntax). diff --git a/_languages/alasca/functions.md b/_languages/alasca/functions.md index 53abea28..05e298a2 100644 --- a/_languages/alasca/functions.md +++ b/_languages/alasca/functions.md @@ -1,6 +1,7 @@ --- title: "Alasca: Functions" date: 2018-08-31 12:00:00 +0200 +published: false --- - zero or one paramemter list diff --git a/_languages/alasca/identity-equality-hashcode.md b/_languages/alasca/identity-equality-hashcode.md index 7b3a29b7..f00bde24 100644 --- a/_languages/alasca/identity-equality-hashcode.md +++ b/_languages/alasca/identity-equality-hashcode.md @@ -1,6 +1,7 @@ --- title: "Alasca: Identity, Equality and Hashcode" date: 2018-08-31 12:00:00 +0200 +published: false --- All values and non-open classes receive a default implementation of equality and identity. diff --git a/_languages/alasca/keywords.md b/_languages/alasca/keywords.md index da197516..8413ab6b 100644 --- a/_languages/alasca/keywords.md +++ b/_languages/alasca/keywords.md @@ -1,6 +1,7 @@ --- title: "Alasca: Keywords" date: 2018-09-07 12:00:00 +0200 +published: false --- **6 letters** namespaces – declaring namespaces and bringing namespaces into scope: diff --git a/_languages/alasca/modifiers.md b/_languages/alasca/modifiers.md index 4d093a7f..f2db8a43 100644 --- a/_languages/alasca/modifiers.md +++ b/_languages/alasca/modifiers.md @@ -1,6 +1,7 @@ --- title: "Alasca: Modifiers" date: 2018-09-07 12:00:00 +0200 +published: false --- All modifiers start with an `@` sign and are placed on the preceding line of the element they annotate. diff --git a/_languages/alasca/modules.md b/_languages/alasca/modules.md index 01cb1c82..7e7867b2 100644 --- a/_languages/alasca/modules.md +++ b/_languages/alasca/modules.md @@ -1,6 +1,7 @@ --- title: "Alasca: Modules" date: 2018-08-31 12:00:00 +0200 +published: false --- Modules contain funs, lets, vars, classes, values, and other modules. diff --git a/_languages/alasca/standard-library.md b/_languages/alasca/standard-library.md index 88602547..df563f7c 100644 --- a/_languages/alasca/standard-library.md +++ b/_languages/alasca/standard-library.md @@ -1,6 +1,7 @@ --- title: "Alasca: Standard Library" date: 2018-08-31 12:00:00 +0200 +published: false --- Ordered from necessary to convenient: @@ -136,4 +137,4 @@ object std.regex // important enough for top-level? ``` // "every element except the last one!" loop(i < arr.length - 1) -// arr.length - 1 == -1 if arr is empty \ No newline at end of file +// arr.length - 1 == -1 if arr is empty diff --git a/_languages/alasca/streams.md b/_languages/alasca/streams.md index 71b256ed..fa424cde 100644 --- a/_languages/alasca/streams.md +++ b/_languages/alasca/streams.md @@ -1,6 +1,7 @@ --- title: "Alasca: Streams" date: 2018-09-31 12:00:00 +0200 +published: false --- diff --git a/_languages/alasca/string-text.md b/_languages/alasca/string-text.md index 08663759..f93fa77c 100644 --- a/_languages/alasca/string-text.md +++ b/_languages/alasca/string-text.md @@ -1,6 +1,7 @@ --- title: "Alasca: String and Text" date: 2018-08-31 12:00:00 +0200 +published: false --- #### String diff --git a/_languages/alasca/syntax-overview.md b/_languages/alasca/syntax-overview.md index f074631e..69929d0e 100644 --- a/_languages/alasca/syntax-overview.md +++ b/_languages/alasca/syntax-overview.md @@ -1,6 +1,7 @@ --- title: "Alasca: Syntax Overview" date: 2018-08-31 12:00:00 +0200 +published: false --- ```scala diff --git a/_languages/alasca/traits-sealed-enum.md b/_languages/alasca/traits-sealed-enum.md index 078f9449..4cc2a6b4 100644 --- a/_languages/alasca/traits-sealed-enum.md +++ b/_languages/alasca/traits-sealed-enum.md @@ -1,6 +1,7 @@ --- title: "Alasca: Traits, Sealed Traits and Enum Traits" date: 2018-08-31 12:00:00 +0200 +published: false --- #### Traits diff --git a/_languages/alasca/typeclasses.md b/_languages/alasca/typeclasses.md index 40d822d7..a74feb73 100644 --- a/_languages/alasca/typeclasses.md +++ b/_languages/alasca/typeclasses.md @@ -1,6 +1,7 @@ --- title: "Alasca: Typeclasses" date: 2018-08-31 12:00:00 +0200 +published: false --- ```scala diff --git a/_languages/alasca/visibility-exports.md b/_languages/alasca/visibility-exports.md index 48ae9517..67c64bbf 100644 --- a/_languages/alasca/visibility-exports.md +++ b/_languages/alasca/visibility-exports.md @@ -1,6 +1,7 @@ --- title: "Alasca: Visibility and Exports" date: 2018-08-31 12:00:00 +0200 +published: false --- - open modules: namespace to place files, at the top of source files diff --git a/_languages/equality-and-identity-part5.md b/_languages/equality-and-identity-part5.md index e1e25f37..206ce007 100644 --- a/_languages/equality-and-identity-part5.md +++ b/_languages/equality-and-identity-part5.md @@ -1,6 +1,7 @@ --- title: "Language Design: Equality & Identity – Part 5: Fixing Rust" date: 2022-06-09 12:00:00 +0200 +published: false ---
diff --git a/_languages/naming-conventions-lookup.md b/_languages/naming-conventions-lookup.md index 8502609d..f3d2cfef 100644 --- a/_languages/naming-conventions-lookup.md +++ b/_languages/naming-conventions-lookup.md @@ -1,6 +1,7 @@ --- title: "Language Design: Naming Conventions – Part 3: Lookup" date: 2022-06-07 12:00:00 +0200 +published: false --- diff --git a/_languages/naming-conventions-stream.md b/_languages/naming-conventions-stream.md index 7a594ee3..f483c0d1 100644 --- a/_languages/naming-conventions-stream.md +++ b/_languages/naming-conventions-stream.md @@ -1,6 +1,7 @@ --- title: "Language Design: Naming Conventions – Part 4: Stream" date: 2022-06-07 12:00:00 +0200 +published: false --- #### Mapping diff --git a/_languages/threads-futures-async.md b/_languages/threads-futures-async.md index 4933241e..e9b670dc 100644 --- a/_languages/threads-futures-async.md +++ b/_languages/threads-futures-async.md @@ -1,4 +1,5 @@ --- title: "Language Design: Threads, Futures and Async" date: 2022-06-05 12:00:00 +0200 +published: false --- From 8f5dbe7e59250df4aacb491c038bfaec63a9ae6f Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 14:08:44 +0200 Subject: [PATCH 003/116] reduce title size --- _sass/config/_typography.scss | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_sass/config/_typography.scss b/_sass/config/_typography.scss index 16c46a85..c9910772 100644 --- a/_sass/config/_typography.scss +++ b/_sass/config/_typography.scss @@ -28,7 +28,7 @@ --bigger: calc(var(--base-em) * var(--ms1)); --title3: calc(var(--base-em) * var(--ms2)); --title2: calc(var(--base-em) * var(--ms3)); - --title1: calc(var(--base-em) * var(--ms4)); + --title1: calc(var(--base-em) * var(--ms4) - 0.5px); /* fit more titles into one line */ --line-height-base: calc(var(--base) * var(--ms2)); --base-line: calc(var(--base-em) * var(--line-height-base)); From 118230f0041c6e674770608842a65d00a42fb8df Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 13:46:22 +0200 Subject: [PATCH 004/116] add cranelift links --- index.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/index.md b/index.md index 5cb32018..417978e3 100644 --- a/index.md +++ b/index.md @@ -110,6 +110,14 @@ layout: index + From 1ae45a8d8f7ffc5db9e3f2d97da1697cb6b059da Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 13:57:17 +0200 Subject: [PATCH 005/116] add fixing swift --- _languages/equality-and-identity-part6.md | 10 ++++++++++ index.md | 1 + 2 files changed, 11 insertions(+) create mode 100644 _languages/equality-and-identity-part6.md diff --git a/_languages/equality-and-identity-part6.md b/_languages/equality-and-identity-part6.md new file mode 100644 index 00000000..a89bd515 --- /dev/null +++ b/_languages/equality-and-identity-part6.md @@ -0,0 +1,10 @@ +--- +title: "Language Design: Equality & Identity – Part 5: Fixing Swift" +date: 2022-06-11 12:00:00 +0200 +published: false +--- + +
+ Dear reader, comments on this page are invite-only due to low-quality feedback.
+ Please refrain from linking this page on community foris of any language mentioned herein. +
diff --git a/index.md b/index.md index 417978e3..7065ca40 100644 --- a/index.md +++ b/index.md @@ -61,6 +61,7 @@ layout: index
  • Solution
  • Fixing Haskell
  • Fixing Rust
    • +
  • Fixing Swift
    • Comparing & Sorting
    From 03e7d02b4741a6c10943d301c56f6c4b5a9b8ae2 Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 14:26:43 +0200 Subject: [PATCH 006/116] no underline for footnote refs --- _sass/base/_base.scss | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/_sass/base/_base.scss b/_sass/base/_base.scss index a7f76d33..1cc37d98 100644 --- a/_sass/base/_base.scss +++ b/_sass/base/_base.scss @@ -307,3 +307,10 @@ table { margin: var(--base-line) calc(var(--base-line) * 3); padding: calc(var(--base-line) / 2) var(--base-line); } + +.footnote { + text-decoration: none; + &:hover { + text-decoration-line: line-through; + } +} From 45496de70d57aef5f404cad0a396d5d58f64b07c Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 14:38:49 +0200 Subject: [PATCH 007/116] add binary operators --- _languages/binary-operators.md | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 _languages/binary-operators.md diff --git a/_languages/binary-operators.md b/_languages/binary-operators.md new file mode 100644 index 00000000..358c0715 --- /dev/null +++ b/_languages/binary-operators.md @@ -0,0 +1,8 @@ +--- +title: "Language Design: Unary Operators" +date: 2019-09-21 12:00:00 +0200 +published: false +--- + +Many languages provide binary operators, usually for operations on numbers (addition, multiplication), +bits (shifts) and boolean values. From 107f6540db650ed429a225d0ccd2f8173507bb0f Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 14:40:57 +0200 Subject: [PATCH 008/116] add annotations-obsolete-modifiers-attempts to index --- _languages/annotations-obsolete-modifiers-attempts.md | 9 ++++----- index.md | 7 ++++++- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/_languages/annotations-obsolete-modifiers-attempts.md b/_languages/annotations-obsolete-modifiers-attempts.md index 6be1550e..0f9acfe2 100644 --- a/_languages/annotations-obsolete-modifiers-attempts.md +++ b/_languages/annotations-obsolete-modifiers-attempts.md @@ -1,11 +1,9 @@ --- -title: "Language Design: Annotations Obsolete Modifiers – Failed Attempts" +title: "Language Design: Annotations Obsolete Modifiers – Failed Design Attempts" date: 2021-12-15 14:00:00 +0200 --- -#### Failed Attempts - -##### Kotlin +#### Kotlin Kotlin [gave up on it](https://blog.jetbrains.com/kotlin/2015/08/modifiers-vs-annotations/), as they couldn't figure out how to recognize annotation usages as early in the compiler pipeline as modifiers previously. @@ -14,7 +12,8 @@ This lead to the determination that modifiers (without the prefix `@`) had to st able to omit the prefix `@`, leading to inconsistencies. -##### Ceylon +#### Ceylon Ceylon tried the route in which [everything is an annotation, but looks like a modifier (i. e. without prefix `@`)](https://ceylon-lang.org/documentation/1.3/reference/structure/annotation/). + This made it hard to distinguish between important keywords, and less important annotations. diff --git a/index.md b/index.md index 7065ca40..e4bcaf99 100644 --- a/index.md +++ b/index.md @@ -44,7 +44,12 @@ layout: index
  • Use consistent type names
    • - + From 827da394b03643bab5a5d2d1109a3e8fbc7f454e Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 23:02:43 +0200 Subject: [PATCH 009/116] improve comparing-and-sorting --- _languages/comparing-and-sorting.md | 36 ++++++++++++++++++----------- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/_languages/comparing-and-sorting.md b/_languages/comparing-and-sorting.md index 299e849f..3736fce3 100644 --- a/_languages/comparing-and-sorting.md +++ b/_languages/comparing-and-sorting.md @@ -7,40 +7,48 @@ Similarly to [equality and identity](equality-and-identity-part1), most language Languages usually provide only a single operation/protocol, often requiring workarounds for some data types in which the comparison operation and the sorting operation return distinct results. -Consider the following `Comparable` trait: +Consider the following `Comparable` trait as it frequently exists across many languages +(like [Haskell](https://hackage.haskell.org/package/base-4.16.1.0/docs/Data-Ord.html), +[Rust](https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html), +[Swift](https://developer.apple.com/documentation/swift/comparable), ...): ```ml trait Comparable[T] - fun < (that: T): Boolean = ... - fun > (that: T): Boolean = ... + fun < (that: T): Bool + fun > (that: T): Bool + ... ``` -... and an IEEE754-conformant implementation of `Comparable` for floating point values, such that `-0.0 < +0.0`, and `Float.NaN < Float.PositiveInfinity` are both false. - -As it becomes obvious, such an implementation of _partial order_ used to correctly _compare_ values, cannot be used to correctly _sort_ values (_total order_).[^1] +... and an IEEE754-conformant comparison implementation for floating point values, +i. e. `-0.0 < +0.0`, and `Float.NaN < Float.PositiveInfinity` are both false. -Worded differently, an implementation of _comparison_ operations for floating point values cannot be used as a stand-in for _sorting_ operations on floating point values.[^2] +As it becomes obvious, such an implementation of _partial order_ can be used to _compare_ values, +but cannot be used to correctly _sort_ values (_total order_).[^1] -Conveniently, IEEE754 standardizes a `totalOrder` relation in §5.10, defining how floating point numbers should be sorted. -The only requirement language-wise is to introduce a distinct trait which represents _total ordering_, enabling a clean separation of _comparisons_ and _sorting_ operations: +The reason is that the implementation of _comparison operations_ for floating point values (a partial order, IEEE754 §5.11) +cannot be used as a stand-in for _sorting_ operations on floating point values. +Conveniently, IEEE754 standardizes a `totalOrder` relation in §5.10, defining how floating point numbers are sorted. +The only requirement language-wise is to introduce a distinct trait[^2] which represents _total ordering_, +enabling a clean separation of _comparison operations_ from _sorting operations_: ```ml trait Sortable[T] - fun sortsBefore(that: T): Boolean = ... - fun sortsAfter (that: T): Boolean = ... + fun sortsBefore(that: T): Bool + fun sortsAfter (that: T): Bool + ... ``` This enables the use of each individual trait for its specific purpose, without conflating different concerns: ```ml -// compare values using Comparable +// example of comparing values using Comparable fun compareReversed[T : Comparable](x: T, y: T) = y < x -// sort values using Sortable +// example of sorting values using Sortable fun sort[T : Sortable](values: Array[T]) = ... - x sortsBefore y + if values(i).sortsBefore(values(j)) { ... } ... ``` From 49a10889a76d04ae4b80d5a49b5f5163cd2afe1f Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Sat, 11 Jun 2022 23:32:05 +0200 Subject: [PATCH 010/116] extend equality-and-identity (Rust) --- _languages/equality-and-identity-part5.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/_languages/equality-and-identity-part5.md b/_languages/equality-and-identity-part5.md index 206ce007..a05451d7 100644 --- a/_languages/equality-and-identity-part5.md +++ b/_languages/equality-and-identity-part5.md @@ -8,3 +8,12 @@ published: false Dear reader, comments on this page are invite-only due to low-quality feedback.
    Please refrain from linking this page on community foris of any language mentioned herein. + +Rust designers recognized the issues with Haskell's approach, but were not able to address the issues with Rust's `Eq` +and `PartialEq` traits. + +The main cause of this failure is the sub-typing relationship between `PartialEq` and `Eq`: + +It requires that an implementation of partial order needs to be consistent with an implementation of total order. + +This works for many types, but not for From cead03422cf9c66847a5329ed358a4caf05d016b Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Tue, 14 Jun 2022 18:35:41 +0200 Subject: [PATCH 011/116] add sad-state-of-programming-on-linux --- .../sad-state-of-programming-on-linux.md | 100 ++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 _standards/sad-state-of-programming-on-linux.md diff --git a/_standards/sad-state-of-programming-on-linux.md b/_standards/sad-state-of-programming-on-linux.md new file mode 100644 index 00000000..1ccbb7a0 --- /dev/null +++ b/_standards/sad-state-of-programming-on-linux.md @@ -0,0 +1,100 @@ +--- +title: "Standards: The sad state of programming on Linux" +date: 2022-06-14 12:00:00 +0200 +--- + +
    + A rough collection of notes, that – with constructive feedback – hopefully + turns into a more accessible description of the issues potential developers + face when they want to write (graphical) software for Linux on Linux.
    + Personally, I would enjoy some recreational GUI programming on my main OS, + but every time I look at what that would entail, I leave horrified, and with + all motivation drained. +
    + +#### Operating System + +- The POSIX API is severely outdated and hasn't been fit for any purpose for a long time. + - Vague spec (POSIX) on top of another vague spec (C), accommodating Linux-like OSes ("Unix") that have been irrelevant for 30 years. + - No technology/language independent API definition (instead "here is how it looks from C, good luck"). +- Complete lack of dependable APIs for even the most basic things. + - Unicode: every language/library/application ship their own Unicode data blob. + - Not even common regex/glob/... code to rely on. + - Time and calendar operations: pray that a sane[^tzdb] TZDB is available on the system and parse it yourself. + - Shipping your own TZDB is even more questionable than it is for the Unicode data blob. + - Settings/configuration management? + - Most applications can barely figure out where to place their config directory! + - File system and networking? + - old "blocking" syscalls? + - ~~old async syscalls?~~ (never worked) + - new uring syscalls? + +→ At a minimum, APIs should be defined in a technology-independent IDL, + to avoid forcing every new tool to include/implement half a C compiler (i. e. unlike Swift). + +→ As a benchmark, IDL should be capable to document register use, lifetime constraints, as well as + the limitations of running inside an interrupt handler. + +→ Consider Microsoft's MIDL/WinMD as an inspiration. + +→ There should be "Linux SDK" defined in terms of such an IDL. + +→ Such a Linux SDK should encompass more APIs than what is commonly provided by the Kernel user-space API or libc. + It should focus on providing a modern and reasonably broad API and feature base that allows implementing libraries and applications on. + + +#### C + +- C, a tool built to convert benign programming errors into CVEs. +- It can't even take responsibility for itself as in "C as a language"[^notalang], but wants to be + "C, the one and only way to interact and communicate with anything on a computer" (at least on Linux). +- Having to understand/speak with C is an ongoing heavy tax on any kind of innovation in the ecosystem. +- Different libc's mutually incompatible with each other. + - How can C people come up with this nonsense? +- Progress only by biological decay? (c. f. Planck's "Science progresses one funeral at a time") + +→ Some modern, minimal, reliable and secure languages that replace the higher-level parts where C is (incorrectly) used is desperately needed. + (For the lower-level parts, Rust has made so much headway already, just use it to replace the remaining C as fast as possible.) + + +#### GUI + +- Is there a single, viable option to develop native GUIs in a modern language on Linux today? + - GTK: C, toxic people I don't want to deal with. + - Bindings: ... + - Qt: C++, corporate shenanigans I don't want to deal with. + - Bindings: ... + - EFL: C + - FLTK: C + - Tk: C/Tcl +- Most other higher-level abstractions use Gtk underneath. +- Fonts, font shaping and font rendering? + - Situation looks less bad than everything else here ([AllSorts](https://github.com/yeslogic/allsorts), [RustyBuzz](https://github.com/RazrFalcon/rustybuzz)). + +Currently, writing F# using Avalonia running on .NET Core looks like the sanest choice (uses Skia for drawing), +with a modern JVM language using Swing[^openjfx] coming second (if you relax "native" sufficiently). +Previously, C# with WinForms developed on MonoDevelop also worked. + +**Is this really the best developers that use Linux as their main operating system can do?** + + +#### Packaging + +- The packaging and maintenance approach is seriously outdated and labor-intensive. + It is only kept alive by the thankless blood, sweat and tears of hundreds of volunteers. +- The new "saviors" (Flatpak, Snap) come at the price of handing control to some corporate entity. + (Some people won't realize the benefits and luxuries they enjoyed by package maintainers looking + out for them – until they have lost this privilege.) +- [Distr1](https://distr1.org/) looks fascinating, more so than [Nix](https://nixos.org/) or [Guix](https://guix.gnu.org/). + + +#### Coda + +Is there any way to fix this? + +- People who are in positions to enact change seem to be fine with status-quo. +- Could the Rust-for-the-kernel work bring small amounts of sanity to the userspace API, and up the stack? + +[^tzdb]: https://lwn.net/Articles/870478/ +[^notalang]: https://gankra.github.io/blah/c-isnt-a-language/ +[^openjfx]: Anyone tried OpenJFX? From f943a28ffab7bba83f137297ff59b69e23f4d872 Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Wed, 15 Jun 2022 01:21:47 +0200 Subject: [PATCH 012/116] increase font size on medium-width page --- _sass/config/_typography.scss | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_sass/config/_typography.scss b/_sass/config/_typography.scss index c9910772..071baf4d 100644 --- a/_sass/config/_typography.scss +++ b/_sass/config/_typography.scss @@ -76,7 +76,7 @@ h1, .h1 { font-size: var(--title1); } @media #{$medium-up} { body { - font-size: calc(var(--base-em) * var(--ms0)); + font-size: calc(var(--base-em)); line-height: calc(var(--base) * var(--ms3)); font-weight: 300; } From 853362d3a6c7043f708e02afcc8b4ae0c5a5ff07 Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Wed, 15 Jun 2022 01:05:43 +0200 Subject: [PATCH 013/116] fix padding on small widths --- _sass/base/_layout.scss | 3 +++ 1 file changed, 3 insertions(+) diff --git a/_sass/base/_layout.scss b/_sass/base/_layout.scss index 8c723f0d..b4fbc091 100644 --- a/_sass/base/_layout.scss +++ b/_sass/base/_layout.scss @@ -16,9 +16,12 @@ $number: 4; // for equal columns } .wrapper { + box-sizing: content-box; margin-right: auto; margin-left: auto; max-width: 50em; + padding-left: 10px; + padding-right: 10px; } .frontpage { From d596d9326a29db249ecc7a6639252296b3731679 Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Wed, 15 Jun 2022 12:59:08 +0200 Subject: [PATCH 014/116] add "Kinds Are Calling Conventions" to index --- index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/index.md b/index.md index e4bcaf99..dd25ad69 100644 --- a/index.md +++ b/index.md @@ -124,6 +124,7 @@ layout: index
  • A New Register Allocator
    • +     From 3e9c57407bd1e4e1c5cbe1de4f01388b55c1b7d4 Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Wed, 15 Jun 2022 14:04:14 +0200 Subject: [PATCH 015/116] add "Dynamic Linking in Swift" to index --- index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/index.md b/index.md index dd25ad69..5299c824 100644 --- a/index.md +++ b/index.md @@ -124,6 +124,7 @@ layout: index
  • A New Register Allocator
    • +
    Dynamic Linking in Swift
    Kinds Are Calling Conventionspdf
     From 11b3204dd12d150d182bed5b74aa3ce89485eb5b Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Wed, 15 Jun 2022 14:08:32 +0200 Subject: [PATCH 016/116] add "C Isn't A Programming Language Anymore" and "To Save C, We Must Save ABI" to index --- index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/index.md b/index.md index 5299c824..0f2694d5 100644 --- a/index.md +++ b/index.md @@ -141,6 +141,8 @@ layout: index - +
    + +
    Ghosts of Unix Past
    1. Design patterns
      2. From 0ed2e0ec6c7bf82b01269f31490a3296e60f3da6 Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Thu, 16 Jun 2022 19:13:18 +0200 Subject: [PATCH 017/116] add "Domains as Cargo Namespaces" --- _config.yml | 22 ++-- _runtimes/domains-as-cargo-namespaces.md | 130 +++++++++++++++++++++++ index.md | 2 +- 3 files changed, 146 insertions(+), 8 deletions(-) create mode 100644 _runtimes/domains-as-cargo-namespaces.md diff --git a/_config.yml b/_config.yml index cfca4643..a93078e6 100644 --- a/_config.yml +++ b/_config.yml @@ -18,7 +18,6 @@ email: simon@ochsenreither.de description: > baseurl: "" # the subpath of your site, e.g. /blog url: "" # the base hostname & protocol for your site -twitter_username: oxnrtr github_username: soc plugins: - jekyll-redirect-from @@ -28,18 +27,22 @@ collections: output: true name: "Standards" published: true - hardware: - output: true - name: "Hardware" - published: true languages: output: true name: "Languages" published: true + runtimes: + output: true + name: "Runtimes" + published: true interfaces: output: true name: "Interfaces" published: true + hardware: + output: true + name: "Hardware" + published: true scala: output: true name: "Scala" @@ -56,12 +59,12 @@ defaults: layout: post - scope: - type: hardware + type: languages values: layout: post - scope: - type: languages + type: runtimes values: layout: post - @@ -69,6 +72,11 @@ defaults: type: interfaces values: layout: post + - + scope: + type: hardware + values: + layout: post - scope: type: scala diff --git a/_runtimes/domains-as-cargo-namespaces.md b/_runtimes/domains-as-cargo-namespaces.md new file mode 100644 index 00000000..dcf78f4b --- /dev/null +++ b/_runtimes/domains-as-cargo-namespaces.md @@ -0,0 +1,130 @@ +--- +title: "Domains as Cargo Namespaces" +date: 2018-10-27 +update: 2022-06-16 +--- + +
      + Dear reader, comments on this page are invite-only due to low-quality feedback.
      + Please refrain from linking this page on language community forums and similar venues. +
      + +### Summary + +Provide a namespacing facility which addresses the following requirements: + +1. Allow claiming a namespace, thereby restricting the set of persons that can publish crates under it. +2. Avoid disputes over namespaces, which can take massive amounts of time and resources to manage. +3. Guarantee that namespaces are unique, solving the issue of "clashing" namespaces. Non-unique namespaces work poorly and cause disputes, as demonstrated by npm's `kik` conflict. +4. Avoid creating a hard dependency on external services. The recent AWS/GitHub service interruptions are a good example why this is important. +5. Make receiving a namespace as seamless as possible for users. Namespaces should be an additional benefit crate authors receive, not some annoying bureaucratic hurdle they have to jump over. + +### Design + +- Use (sub)domains as namespaces. _Maven_ has shown that this approach has been working exceedingly well for more than a decade. +- Control of a (sub)domain is established using domain validation (DV), for instance through DNS TXT recorsd or [RFC5785](https://tools.ietf.org/html/rfc5785). + _Let's Encrypt_ is successfully using this approach to generate millions of certificates each year. +- Crates.io maintainer will never need to get involved in namespace disputes, as ICANN's _Uniform Domain-Name Dispute-Resolution Policy_ deals with this. + +#### Example flow: user validates domain + +A user wants to publish their `foobar` crate under their domain `foobar-project.org`. + +1. The user adds `organization = "foobar-project.org"` to their `Cargo.toml` file. +2. The user runs `cargo publish`. +3. The command prints the following text to the console that contains a randomly generated token: + > Crates.io couldn't verify that you own `foobar-project.org`. To prove ownership, either + > + > a) create a DNS TXT record with the value `ZG2ioiTY3tMgwDYfmb6p` for the domain `foobar-project.org`, or + > + > b) place a text file with the text `ZG2ioiTY3tMgwDYfmb6p` at `https://foobar-project.org/.well-known/cargo-publishers`. +4. The user follows the instructions and reruns `cargo publish`. crates.io checks that the token matches and publishes the crate under the namespace. + +Upon the first request to publish a crate with a namespace, crates.io generates a random string that is user-, crate- and domain-specific. + +On each following publishing request crates.io checks whether the token is identical to what crates.io has on file for the specific user/crate/domain combination. + +#### Example flow: user wants to publish crate to a namespace maintained by others + +The ability to publish a crate is not limited to one person: If a different person wants to publish a crate to a domain, crates.io returns a similar reply: + +> You are not allowed to publish your crate `blurbs` under the `foobar-project.org` namespace. +> Owners of the namespace may change their domain validation token to either +> +> a) `Io3487xY3tjg54Ef9Opz` to allow you to publish `blurbs` under the `foobar-project.org` namespace, or +> +> b) `Hg7jak43EnHJ3la8DJ3J` to allow you to publish any crate under the `foobar-project.org` namespace. + +This person would then contact the owner of the namespace, who could decide whether to accept or reject this request. + +This also serves as a very easy way to allow external contributors to publish add-on crates to a crate in an organization, +without allowing them to publish to the main crate. E.g. authors of serde could publish their own crate under `serde.rs/serde` +and allow vetted, "official" add-on crates to be published by external contributors under `serde.rs/serde-abc` or +`serde.rs/serde-xyz`. + +#### Example flow: change in domain ownership + +This largely follows the flow of "user validates domain", except that publishing a new version of a crate that was +published by a previous domain owner is rejected with the following message: + +> You are not allowed to publish your crate `blurbs` under the `foobar-project.org` namespace, +> because a previous owner of the namespace has already used that crate name. +> +> To receive permission to re-use the crate name from the previous owner, you can ask them to navigate to +> `https://crates.io/me/transfer-crate-name?crate=blurbs&newOwner=your-account` and transfer the crate name to you. + +This person would then contact the owner of the namespace, who could decide whether to accept or reject this request. + +### Required Changes + +#### Changes to cargo + +cargo and its Cargo.toml format needs to be extended to allow +- adding `organization` keys to Cargo.toml files and treat them correctly +- adding dependencies on namespaced crates to Cargo.toml files + +#### Changes to crates.io + +crates.io needs to be extended + - to understand `organization` keys and namespacing + - to validate control of (sub)domains as specified above + - to correctly display such crates on the web + +#### Changes to the Language + +No changes to the language are required. Source code of crates does not need to be changed to enable namespaces. + +### Further Suggestions + +It is recommended that `/` is used as a separator between the namespace and the crate name. + +This would mean that a fully-qualified crate would look like a URL, making it easy to find further documentation or the project's homepage: + +Consider a crate called `foobar` with the namespace `foobar-project.org`. The fully-qualified name would be `foobar-project.org/foobar`. +This looks like a real URL and the namespace owner could place documentation there, forward to the crates GitHub page, or redirect to doc.rs. + +### Out of Scope + +This proposal does not discuss changes to the global namespace. + +### FAQ + +_This FAQ is not meant as a complete enumeration of all possible scenarios._ + +*Do I need my own domain?* + +No. A subdomain is sufficient. Every Rust crate author owns at least one already through their GitHub account. + +*I no longer care about maintaining the domain, what should I do?* + +Ask your maintainers or contributors to take over the domain. (This is not much different from a situation where the original author loses interest in maintaining his/her crate.) + +*My domain was hacked!* + +Use your domain registry's support channels to resolve this issue. +In the meantime, it might make sense to let crates.io maintainers know, so that the publication of new crates can be disabled until the issue is resolved. +(This is not much different from your crates.io account being compromised.) + +*Someone else owns my domain now!* + +Pick a new domain. Even if the new owners of the domain want to publish crates, they will not be able to publish newer versions of existing crates without your consent. diff --git a/index.md b/index.md index 0f2694d5..309fe5d7 100644 --- a/index.md +++ b/index.md @@ -107,7 +107,7 @@ layout: index
    RuntimesDomains as Cargo Namespaces From ca15bf2710d1d916a287b797d118fbac24fa074e Mon Sep 17 00:00:00 2001 From: Simon Ochsenreither Date: Tue, 21 Jun 2022 11:54:46 +0200 Subject: [PATCH 018/116] add link to stop-using-angle-brackets-for-generics --- .../stop-using-angle-brackets-for-generics.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/_languages/stop-using-angle-brackets-for-generics.md b/_languages/stop-using-angle-brackets-for-generics.md index 28361765..2b94149f 100644 --- a/_languages/stop-using-angle-brackets-for-generics.md +++ b/_languages/stop-using-angle-brackets-for-generics.md @@ -43,8 +43,10 @@ instance.foo(); _C#_ and _Kotlin_ tried to retain a more consistent syntax by introducing unlimited look-ahead: Their parser just keeps reading input after the `<` until it can make a decision.[^csharp] -For decades, _C++_ required adding spaces to nested closing generics to allow the compiler to -distinguish between the right-shift operator `>>` and the end of a nested generic type definition.[^cpp] +_C++_ suffers from a plethora of `<>`-related issues.[^cpp1] +The only issue addressed by the C++ committee after decades was the requirement to add spaces to +nested closing generics to allow the compiler to distinguish between the right-shift operator `>>` +and the end of a nested generic type definition.[^cpp2] All other issues appear to be unfixable. _Rust_ is forced to use the hideous "turbofish" operator `::<>` to distinguish between the left side of a comparison and the start of a generic type, introducing syntactic inconsistency between generics in @@ -59,9 +61,9 @@ let vec: Vec = Vec::::new(); #### 3. It allows `[]` to be (ab)used for syntax "conveniences" Many languages used `[]` to add syntax for collection literals (`[1, 2, 3]`) or array lookup -(`array[0]`), adding pointless complexity to the language for very little benefit – as such built-in -syntax usually becomes dead weight a few years down the road, as the preferred choice -of data structure implementation evolves.[^javalit][^jslit] +(`array[0]`), adding pointless complexity to the language for very little benefit – in many cases +such built-in syntax became dead weight after the languages' preferred choice of data structure +implementation evolved.[^javalit][^jslit] Using `[]` for generics instead of `<>` shuts down this possibility for good, and encourages the use of standard method call brackets (`()`) for these use-cases instead:[^nim] @@ -88,7 +90,8 @@ map("name") = "Joe" /* instead of */ map["name"] = "Joe" #### Coda -Thankfully, the number of languages using `[]` for generics seems to increase lately – with Scala, Python, Nim and Go joining Eiffel, which was pretty much the sole user of `[]` for decades. +Thankfully, the number of languages using `[]` for generics seems to increase lately – +with Scala, Python, Nim and Go joining Eiffel, which was pretty much the sole user of `[]` for decades. It remains to be seen whether this turns into tidal change similar to the widespread [adoption of `ident: Type` over `Type ident`](https://soc.me/languages/type-annotations) in modern languages. @@ -96,7 +99,8 @@ It remains to be seen whether this turns into tidal change similar to the widesp [^related]: [Parsing Ambiguity: Type Argument v. Less Than](https://keleshev.com/parsing-ambiguity-type-argument-v-less-than) is a similar article focusing on some of these issues in more depth. [^java]: Java: The syntax inconsistency is due to the difficulty a compiler would have to tell whether some token stream of `instance` `.` `foo` `<` is the left side of a comparison (with `<` being the "less-than" operator) or the start of a generic type argument within a method call. [^csharp]: C#: See [ECMA-334, 4th Edition, §9.2.3 – Grammar Ambiguities](https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf) -[^cpp]: C++: See [Wikipedia – C++11 right angle bracket](https://en.wikipedia.org/wiki/C%2B%2B11#Right_angle_bracket) +[^cpp1]: C++: See [What are all the syntax problems introduced by the usage of angle brackets in C++ templates?](https://stackoverflow.com/questions/7304699/what-are-all-the-syntax-problems-introduced-by-the-usage-of-angle-brackets-in-c) +[^cpp2]: C++: See [Wikipedia – C++11 right angle bracket](https://en.wikipedia.org/wiki/C%2B%2B11#Right_angle_bracket) [^javalit]: Java pretty much abandoned arrays – they never integrated them with collections in 1.2, let alone generics in 1.5. [^jslit]: JavaScript stopped giving out new collection literals almost immediately after its first release – no collection type added since received its own literals (`Set`, `Map`, `ByteBuffer`, ...). [^nim]: Nim uses `[]` for generics, but employs [a hack to _also_ use `[]` for lookup](https://nim-lang.org/docs/manual.html#procedures-method-call-syntax). From 07acc963eec9b9781d7a0261cdf730e39ba0fbe0 Mon Sep 17 00:00:00 2001 From: soc Date: Thu, 23 Jun 2022 15:57:02 +0200 Subject: [PATCH 019/116] add JVM Anatomy Quarks --- index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/index.md b/index.md index 309fe5d7..39ffb8fa 100644 --- a/index.md +++ b/index.md @@ -116,6 +116,7 @@ layout: index +
    Cranelift Backend:
    Languages - +
    Design Principles: + +
    Easy wins: