Logs: freenode/#haskell
| 2020-11-18 17:40:30 | hackage | spake2 0.4.3 - Implementation of the SPAKE2 Password-Authenticated Key Exchange algorithm https://hackage.haskell.org/package/spake2-0.4.3 (rkrishnan) |
| 2020-11-18 17:41:39 | <dolio> | What do you mean? It allows perfectly for my 128-bit machine characters. |
| 2020-11-18 17:42:38 | <merijn> | dolio: Sure, but that wasn't even what I was getting at |
| 2020-11-18 17:42:49 | <dolio> | Yeah, I know. |
| 2020-11-18 17:43:03 | <hekkaidekapus> | |> coefficient (scientific 010 2) |
| 2020-11-18 17:43:08 | × | the-smug-one quits (~user@h188-122-129-70.cust.a3fiber.se) (Remote host closed the connection) |
| 2020-11-18 17:43:14 | <hekkaidekapus> | |> 10 -- idnar |
| 2020-11-18 17:43:23 | <merijn> | C is close to the metal...as long as you don't acknowledge your "metal" changed into a superscalar, deeply pipelined, out of order, speculatively executing CPU about 2 decades ago :p |
| 2020-11-18 17:43:37 | <texasmynsted> | merijn: What do you use for close to the metal projects? Mostly I see C an assembly. |
| 2020-11-18 17:44:10 | <int-e> | vhdl? |
| 2020-11-18 17:44:16 | <merijn> | What I use is C or C++, but don't go around those are much closer to the metal than Haskell or Rust |
| 2020-11-18 17:44:32 | <dolio> | C is heavily-optimized-for. |
| 2020-11-18 17:44:40 | <merijn> | texasmynsted: See also: https://queue.acm.org/detail.cfm?id=3212479 |
| 2020-11-18 17:44:51 | <merijn> | Which is conveniently titled "C Is Not a Low-level Language" ;) |
| 2020-11-18 17:44:56 | <texasmynsted> | I have found C++ is too bulky and difficult to control. |
| 2020-11-18 17:45:05 | → | cads joins (~cads@ip-64-72-99-232.lasvegas.net) |
| 2020-11-18 17:45:17 | <merijn> | texasmynsted: In my experience there are two C's |
| 2020-11-18 17:45:26 | <texasmynsted> | okay. I am listening |
| 2020-11-18 17:46:00 | <merijn> | texasmynsted: 1) C, the language that 90% of C programmers *think* they are writing, and 2) C the actual language as defined by the spec and that compilers attempt to implement |
| 2020-11-18 17:46:13 | <merijn> | These two things are, surprisingly *massively* different |
| 2020-11-18 17:46:50 | <merijn> | But you don't notice those difference and if no one ever told you anything about modern CPU design *nor* modern compilers, then I can understand how you might imagine that 2 is like 1 |
| 2020-11-18 17:46:58 | <p0a> | the interface with the metal is the compiler, not the language |
| 2020-11-18 17:47:28 | <int-e> | . o O ( 2) is the thing that turns every C program into a puzzle whether it contains undefined behavior or not ) |
| 2020-11-18 17:47:32 | <texasmynsted> | p0a +1 |
| 2020-11-18 17:48:10 | <merijn> | p0a: Right, but that just means it becomes impossible to know what code does without also knowing which *exact* version of which *exact* compiler people were using |
| 2020-11-18 17:48:16 | <int-e> | . o O ( or, more realistically, into a puzzle to figure out *why* it contains undefined behavior ) |
| 2020-11-18 17:48:29 | <merijn> | The point of having a spec is that you can write code and know what it does *without* error prone trial and error |
| 2020-11-18 17:48:33 | <dolio> | Yeah, the answer is almost always, "it does," no? :) |
| 2020-11-18 17:48:45 | <texasmynsted> | what p0a says aligns with my experience. Typically a manufactured chip has a compiler that will compile a "subset" of C for the chip. |
| 2020-11-18 17:48:49 | <merijn> | dolio: Some cases are super fun, though |
| 2020-11-18 17:48:59 | <merijn> | dolio: Like "whether this code is undefined is implementation defined" |
| 2020-11-18 17:49:04 | <merijn> | dolio: No joke! |
| 2020-11-18 17:49:29 | <dolio> | Really? I didn't notice that when I was reading, but I didn't think too hard. |
| 2020-11-18 17:49:35 | <merijn> | texasmynsted: Right, but then you're not writing C, you're writing a custom ad hoc underspecified DSL that happens to resemble C |
| 2020-11-18 17:49:36 | × | alp quits (~alp@88.126.45.36) (Ping timeout: 256 seconds) |
| 2020-11-18 17:49:47 | <texasmynsted> | yes. I understand your point now. |
| 2020-11-18 17:49:48 | × | conal_ quits (~conal@64.71.133.70) (Quit: Computer has gone to sleep.) |
| 2020-11-18 17:49:57 | <merijn> | dolio: Signed integer overflow is UB, right? |
| 2020-11-18 17:50:03 | <dolio> | Yeah. |
| 2020-11-18 17:50:15 | <merijn> | dolio: Fun fact: the signedness of "char" is implementation defined :) |
| 2020-11-18 17:50:20 | <dolio> | Oh, and you don't know how big they are. |
| 2020-11-18 17:50:24 | → | bitmapper joins (uid464869@gateway/web/irccloud.com/x-xpsufctbszodgohs) |
| 2020-11-18 17:50:47 | <merijn> | dolio: So you can construct code the is signed overflow if char is signed, but whether it is, is implementation defined |
| 2020-11-18 17:50:53 | <texasmynsted> | most things are "implementation defined". The sizes are defined by the chipset |
| 2020-11-18 17:51:02 | <merijn> | texasmynsted: I wish |
| 2020-11-18 17:51:07 | <dolio> | Ah, yeah. |
| 2020-11-18 17:51:20 | → | britva joins (~britva@2a02:aa13:7240:2980:7da5:a1a0:c038:90b4) |
| 2020-11-18 17:51:22 | → | conal joins (~conal@64.71.133.70) |
| 2020-11-18 17:51:24 | <merijn> | If we took the C spec as-is and said "all undefined behaviour is implementation defined" we'd be massively better off |
| 2020-11-18 17:51:43 | × | conal quits (~conal@64.71.133.70) (Client Quit) |
| 2020-11-18 17:51:44 | <int-e> | implementations with sufficient fire-proofing use unsinged characters |
| 2020-11-18 17:51:45 | <texasmynsted> | Or turn it around. |
| 2020-11-18 17:52:09 | <texasmynsted> | Okay. I am all in. What language do you propose? |
| 2020-11-18 17:52:24 | <merijn> | int-e: That's massively inconsistent, though, because all other integers without a sign specifier default to signed |
| 2020-11-18 17:52:27 | <texasmynsted> | Because it will not be C and it will not be Rust and it will not be Haskell. |
| 2020-11-18 17:52:31 | <int-e> | ("unsinged" may be my most common typo when writing C) |
| 2020-11-18 17:52:36 | <merijn> | texasmynsted: For what purpose? |
| 2020-11-18 17:53:19 | × | jb55 quits (~jb55@gateway/tor-sasl/jb55) (Remote host closed the connection) |
| 2020-11-18 17:53:21 | <int-e> | merijn: Yes, I agree that was an awful choice. |
| 2020-11-18 17:53:32 | <texasmynsted> | Firmware development. Close enough to the metal that the only code running on the chip is what it specifically written. |
| 2020-11-18 17:53:40 | → | jb55 joins (~jb55@gateway/tor-sasl/jb55) |
| 2020-11-18 17:53:42 | <merijn> | texasmynsted: Ivory? :) |
| 2020-11-18 17:53:43 | <geekosaur> | I think I made my editor autofix that one |
| 2020-11-18 17:53:47 | <int-e> | 5 compiler writers in a room, all trying to ensure that their own compiler is standards-compliant. |
| 2020-11-18 17:53:51 | <merijn> | texasmynsted: Haskell based DSL that generates C |
| 2020-11-18 17:53:52 | <dolio> | I think the point was not, "don't use C," but, "don't perpetuate myths about C." |
| 2020-11-18 17:54:07 | <merijn> | dolio++ |
| 2020-11-18 17:54:31 | texasmynsted | facepalm |
| 2020-11-18 17:55:05 | <Chousuke> | I don't see why you couldn't use Rust for firmware development. People seem to be rather interested in doing just that. |
| 2020-11-18 17:55:08 | <dolio> | Because the myths are part of what keep people from developing viable alternatives to C. |
| 2020-11-18 17:55:09 | <texasmynsted> | I have never heard of Ivory. I need to check this out. |
| 2020-11-18 17:55:11 | <merijn> | texasmynsted: dolio: Well, to be fair "don't perpetuate myths" was the mainpoint, but "don't handwrite C whenever you can possibly help it" was a solid 2nd point |
| 2020-11-18 17:55:21 | <texasmynsted> | Is it strict? |
| 2020-11-18 17:55:21 | × | jakob_ quits (~textual@p200300f49f162200855785b1c0c4761c.dip0.t-ipconnect.de) (Quit: My Laptop has gone to sleep. ZZZzzz…) |
| 2020-11-18 17:55:42 | <merijn> | texasmynsted: It was developed specifically for embedded/systems stuff where you want statically validated properties, but the tooling requires C |
| 2020-11-18 17:56:06 | <srk> | only ivory-backend-c |
| 2020-11-18 17:56:14 | <merijn> | texasmynsted: https://ivorylang.org/ivory-concepts.html |
| 2020-11-18 17:56:16 | <srk> | which uses language-c |
| 2020-11-18 17:56:26 | → | nut joins (~user@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2020-11-18 17:56:29 | <srk> | there are other backends for verification purposes |
| 2020-11-18 17:56:33 | → | jakob_ joins (~textual@p200300f49f1622000c6d85cd02bcc449.dip0.t-ipconnect.de) |
| 2020-11-18 17:56:39 | <texasmynsted> | Soooo you are writing in a "different" C DSL. |
| 2020-11-18 17:56:46 | <Chousuke> | I mean, the fact that often you *have* to use C for firmware development doesn't mean C is particularly well suited for the task. That's just how it happens to be, for mostly historical reasons. :/ |
| 2020-11-18 17:56:52 | <texasmynsted> | that compiles to a C DSL |
| 2020-11-18 17:57:01 | <merijn> | texasmynsted: No, you are writing in *Haskell* DSL :) |
| 2020-11-18 17:57:08 | ← | gecko_ parts (~gecko@2001:19f0:5:10f4:5400:3ff:fe0f:15cb) () |
| 2020-11-18 17:57:25 | × | dcoutts_ quits (~duncan@33.14.75.194.dyn.plus.net) (Ping timeout: 240 seconds) |
| 2020-11-18 17:57:26 | <texasmynsted> | Okay. You are writing in a Haskell DSL that compiles to a C DSL. |
| 2020-11-18 17:57:30 | hackage | zydiskell 0.1.0.1 - Haskell language binding for the Zydis library, a x86/x86-64 disassembler. https://hackage.haskell.org/package/zydiskell-0.1.0.1 (nerded) |
| 2020-11-18 17:57:33 | <srk> | compiles to C |
| 2020-11-18 17:57:34 | <merijn> | texasmynsted: Developed by a company that develops tools specifically for crypto/embedded stuff |
| 2020-11-18 17:57:36 | <texasmynsted> | And this is better why? |
| 2020-11-18 17:57:41 | <srk> | safe |
| 2020-11-18 17:57:56 | <srk> | and.. embedded in Haskell! :) |
| 2020-11-18 17:58:03 | <maerwald> | why is it safe? |
| 2020-11-18 17:58:04 | × | brisbin quits (~patrick@199.66.179.204) (Read error: Connection reset by peer) |
| 2020-11-18 17:58:06 | <merijn> | texasmynsted: Because that compiler and the people who wrote it are better at C than you are |
| 2020-11-18 17:58:13 | <srk> | (bunch of other things as well) |
| 2020-11-18 17:58:23 | <texasmynsted> | Because if this can sell, the F*** Rust. |
| 2020-11-18 17:58:23 | <merijn> | maerwald: No null pointers (or really heap allocation, tbh) |
All times are in UTC.