< 1751849461 558362 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement
> 1751849587 981013 PRIVMSG #esolangs :14[[07Smotslang14]]4 M10 02https://esolangs.org/w/index.php?diff=160989&oldid=159895 5* 03Clover-not-used 5* (-141) 10not lower
> 1751851230 132672 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03EsolangGUY 5* 10New user account
> 1751852382 430274 PRIVMSG #esolangs :14[[07User:Pifrited/Simple2DMachine14]]4 10 02https://esolangs.org/w/index.php?diff=160990&oldid=160935 5* 03Pifrited 5* (-76) 10
< 1751853426 741166 :ski!~ski@remote11.chalmers.se QUIT :Remote host closed the connection
> 1751853808 962412 PRIVMSG #esolangs :14[[07Extendable MiniLang14]]4 N10 02https://esolangs.org/w/index.php?oldid=160991 5* 03PrySigneToFry 5* (+4223) 10Created page with " Next time you create a language that is computable, write an interpreter for it! -- ISLPTNG
Extendable MiniLang is designed by PSTF and his AI friend. = Command Set = Can you believe that? It only has 6 commands! {| class="w
> 1751853835 160336 PRIVMSG #esolangs :14[[07Extendable MiniLang14]]4 10 02https://esolangs.org/w/index.php?diff=160992&oldid=160991 5* 03PrySigneToFry 5* (+81) 10
< 1751854266 844674 :ski!~ski@remote11.chalmers.se JOIN #esolangs ski :Stefan Ljungstrand
> 1751859172 409685 PRIVMSG #esolangs :14[[07UserEdited14]]4 10 02https://esolangs.org/w/index.php?diff=160993&oldid=159856 5* 03PrySigneToFry 5* (+593) 10
> 1751864876 497564 PRIVMSG #esolangs :14[[07Qwhy14]]4 10 02https://esolangs.org/w/index.php?diff=160994&oldid=129345 5* 03Stkptr 5* (+150) 10
> 1751864888 29221 PRIVMSG #esolangs :14[[07Qwhy14]]4 M10 02https://esolangs.org/w/index.php?diff=160995&oldid=160994 5* 03Stkptr 5* (+2) 10/* Computational class */
> 1751867257 891481 PRIVMSG #esolangs :14[[07User talk:PrySigneToFry14]]4 10 02https://esolangs.org/w/index.php?diff=160996&oldid=160949 5* 03None1 5* (+304) 10/* Any interests on joining our Esolang Tencent QQ group? */
< 1751870289 151825 :tromp!~textual@2001:1c00:3487:1b00:a424:5b9:4dc2:8889 JOIN #esolangs * :Textual User
< 1751872373 124598 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
< 1751873236 598614 :b_jonas!~x@88.87.242.184 QUIT :Quit: leaving
< 1751878641 336464 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1751878656 623405 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I figured my problem out – I think the thing I have is the ? exponential from linear logic
< 1751878668 30231 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which, if true, would be somewhat major news as I've never seen that thing in a programming language type system before
< 1751878754 859966 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I spent a couple of hours last night just trying to figure out what it even means in a programming language context
> 1751879901 613121 PRIVMSG #esolangs :14[[07User:Hotcrystal0/Chess piece strength14]]4 10 02https://esolangs.org/w/index.php?diff=160997&oldid=160929 5* 03PrySigneToFry 5* (+51) 10
< 1751880496 645596 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1751880532 551665 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: is this related to replacing rust references with something very similar but not quite the same?
< 1751880540 122746 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: yes!
< 1751880581 603599 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although it's actually true even for regular Rust references: I think a shared reference is, precisely, a ? of a mutable reference
< 1751880743 445424 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's a pattern in Rust where basically every function has to be written twice, once with shared references, once with mutable references
< 1751880761 742294 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I was trying to a) understand why and b) trying to describe the pattern mathematically so that it could be automated
> 1751880765 438883 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=160998&oldid=160926 5* 03Creepy 5* (+21) 10
> 1751880792 700169 PRIVMSG #esolangs :14[[07!Frontal Lobe Lobotomy14]]4 N10 02https://esolangs.org/w/index.php?oldid=160999 5* 03Creepy 5* (+10074) 10Created page with "= Frontal Lobe Lobotomy (FLL) = '''Frontal Lobe Lobotomy (1.1.0 COMPILER / 1.2.0 VM => FLL 1.1.0)''' is a '''x86-64''' esoteric programming language inspired by brain surgery metaphors 'Lobotomy'. It uses pointer-addressable neurons and suture levels to r
< 1751881005 811038 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"basically every function has to be written twice" => is this like those C++ functions that index into a collection or dereference an iterator, and can take either a C++ reference or C++ const reference to the collection or iterator and have to return a C++ reference or C++ const reference as the result? \
< 1751881020 772260 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: yes
< 1751881065 674398 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if the only thing you do on a reference is place-project it (which is what those iterators are doing), it's always the case that you get a const and a non-const version with identical code
< 1751881066 785913 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah, I've seen a few of those in rust, some functions are even written three times. it didn't bother me too much because it only comes up if you're writing a very generic library with lots of possible use cases.
< 1751881124 444339 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :x, x_mut, into_x
> 1751881157 457818 PRIVMSG #esolangs :14[[07!Frontal Lobe Lobotomy14]]4 10 02https://esolangs.org/w/index.php?diff=161000&oldid=160999 5* 03Creepy 5* (+246) 10
> 1751881235 665727 PRIVMSG #esolangs :14[[07!Frontal Lobe Lobotomy14]]4 10 02https://esolangs.org/w/index.php?diff=161001&oldid=161000 5* 03Creepy 5* (+10) 10/* Download Tooling */
< 1751881315 65202 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
> 1751881361 658035 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=161002&oldid=160960 5* 03Creepy 5* (+29) 10
< 1751881392 70880 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, I see, they started the page name with a ! to make it sort near the start of the list
> 1751881448 413658 PRIVMSG #esolangs :14[[07Symbolmathing14]]4 10 02https://esolangs.org/w/index.php?diff=161003&oldid=160986 5* 03Bebebe 5* (+563) 10
< 1751881509 662973 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
> 1751881522 583365 PRIVMSG #esolangs :14[[07!Frontal Lobe Lobotomy14]]4 10 02https://esolangs.org/w/index.php?diff=161004&oldid=161001 5* 03Creepy 5* (+101) 10
< 1751881528 620724 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :there are other cases when rust has a stronger type system with more distinctions than many other languages, and because of this library data types often need extra functions to convert from one type to another. like there's a impl Box<[MaybeUninit], A> { unsafe fn assume_init(self) -> Box<[T], A>; } function that compiles to an identity
< 1751881529 121662 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :function.
> 1751881596 997405 PRIVMSG #esolangs :14[[07!Frontal Lobe Lobotomy14]]4 10 02https://esolangs.org/w/index.php?diff=161005&oldid=161004 5* 03Creepy 5* (+6) 10
< 1751881981 779140 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: yes – in fact recently I've been writing an entire library of things that compile to the identity function
< 1751882014 991034 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at that point they are basically proofs rather than progrms
< 1751882018 250021 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* programs
< 1751882278 979180 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this one isn't a proof because it's unsafe, but there are safe functions like this too, such as impl Cell<[T]> { fn as_slice_of_cells(&self) -> &[Cell]; }
< 1751882398 746599 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :though the former one is sort of a proof in the sense that it guarantees an invariant about the representation of Box that an unconventional implementation could technically break, eg. one that may uses a different allocator for the argument and the resturn
< 1751882419 525771 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I mean invokes the allocator with a different layout
< 1751882449 246427 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
< 1751882460 643846 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1751882598 37119 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :eg. you could have a Box implementation that allocates a Box<[T]> into an arena that's usually read-only and made read-write for a short time during the allocation (on cpus that support this) but allocates Box<[MaybeUninit]> into a read-write arena, and the former stores the allocation metadata outside the arena while the latter stores it in
< 1751882598 536821 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :line
< 1751882635 251569 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it's not something that you're likely to do, but without this function in the library the user wouldn't know that this isn't the case
> 1751882651 840729 PRIVMSG #esolangs :14[[07User:Creepy14]]4 N10 02https://esolangs.org/w/index.php?oldid=161006 5* 03Creepy 5* (+12) 10Created page with "hi im creepy"
< 1751882732 641957 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :admittedly this might not be possible in rust because it would require impl specialization that can detect non-membership in a trait
< 1751883274 628503 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: the representation invariant is actually useful, e.g. Option can have a different representation from Option> sometimes, so you need a guarantee that Box doesn't do that
< 1751883342 761754 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ah yes, that's true for Option
> 1751883491 731038 PRIVMSG #esolangs :14[[07Symbolmathing14]]4 10 02https://esolangs.org/w/index.php?diff=161007&oldid=161003 5* 03Bebebe 5* (+1815) 10/* Interpreter */
> 1751883510 438996 PRIVMSG #esolangs :14[[07Symbolmathing14]]4 10 02https://esolangs.org/w/index.php?diff=161008&oldid=161007 5* 03Bebebe 5* (-1) 10/* Interpreter */
< 1751883795 520499 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs amby :realname
< 1751883921 298538 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :by the way I wonder if rust could add built-in types that contain an integer but the range is restricted at compile time, eg. to a union of some intervals. std::num::NonzeroU32 would be a special case of this. and I think it shouldn't be hard to implement this in the compiler because user-defined unit-only enums can do most of what this does. you'd
< 1751883921 799075 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :just have to support a range of more values than you could reasonably list in an enum declaration, plus checked and unchecked conversions from the underlying integer type.
< 1751884014 253276 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :you could implement this as a user as a wrapper over the base integer type, but a built-in would allow optimizations eg. inside Option or other enums.
< 1751884051 430966 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: https://gist.github.com/joboet/0cecbce925ee2ad1ee3e5520cec81e30
< 1751884089 116747 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ah, thank you, that is relevant
< 1751884125 16911 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :apparently hasn't been officially proposed, so it took me a bit longer to find than usual
< 1751884131 710179 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it's a fairly well-known pre-proposal
< 1751884208 517165 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :that one does rather more than what I'm asking for though
< 1751884308 644027 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and I think it's harder to implement
< 1751884366 933149 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think so – but I think the same sorts of type-system-related problems happen with any refinement type, and also suspect they will need the most implementation effort
< 1751884375 595233 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so doing the rest of pattern types probably isn't too hard once you have integer ranges
< 1751884484 58298 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
< 1751884539 167165 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 252 seconds
< 1751884563 499176 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it's not really the non-integer part that I'm worried there, but that one seems to allow you to implicitly convert a more restricted type to a less restricted one, and more type magic. what I'm proposing would make this an explicit wrapper with conversion functions, except the `as` operator would be used for conversion from restricted to base
< 1751884563 966620 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :integer type.
< 1751884564 831107 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life
> 1751884637 813064 PRIVMSG #esolangs :14[[07Symbolmathing14]]4 10 02https://esolangs.org/w/index.php?diff=161009&oldid=161008 5* 03Bebebe 5* (+2478) 10
< 1751884714 428576 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: the gist has some explanation as to why the conversion is implicit – the basic issue is that an explicit coercion would need to be guarded by a match, but if you have matches perform the coercion automatically and you don't have subtyping then you break all the existing match statements
< 1751884732 171267 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you'd need to do something like having an attribute on match arms that gets them to refine the type
< 1751884775 359693 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yes, and that could be a useful extension, but I think it's harder to implement it in the specification and compiler
< 1751884987 186155 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :at least we have unions now so I can use a struct(i32,union) to represent an enum with extra data in its discriminant, I just can't prove it typesafe
< 1751885129 204370 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I think there was a proposal for C-like bitfields for rust that could handle some of the use cases in a typesafe way, but I don't think it's in the language.
< 1751885411 717629 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it's kind of hard because you have to pack values into the discriminant in a way that you can't make references to them, but rust already has packed structs that do something like that
< 1751885779 65775 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: so I've been thinking about this (I've been thinking about just about everything reference-related)
< 1751885855 52448 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can make shared references work by having the reference fix the padding/unused bits as it reads (although in that case you can't convert the reference to a memory address because a pointer wouldn't act the same way)
< 1751885910 348820 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and for mutable references, you can mutate the value to fix the padding/unused bits as the reference is formed, then mutate it back when the reference is dropped (although this requires mutable references to have destructors and for the destructors to be guaranteed to run before the lifetime of the mutable reference ends)
< 1751885938 411557 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :both of these won't work in current Rust for obvious reasons, but they feel like things that a "fixed" version of Rust would allow
< 1751886468 868669 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but the reference wouldn't be of an ordinary reference type, right?
< 1751886492 42611 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I think rust currently doesn't let you pack three bools into a one-byte struct
< 1751886518 307687 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :that's one of those cases that should be possible, you just can't borrow the fields as an ordinary &bool, but you can still read or write them by value
< 1751886591 446799 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :"you can mutate the value to fix the padding/unused bits as the reference is formed, then mutate it back when the reference is dropped" hehe, that could work. The shared reference would have to point to a temporary.
< 1751886632 921921 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and I think even that wouldn't work if you like want to shared borrow both the whole structure and the fields
< 1751886656 806523 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but I don't really mind this, these are packed structs and small integer fields, I'm fine with them not being borrowable individually
< 1751887064 99883 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : but the reference wouldn't be of an ordinary reference type, right? ← so Rust is missing a type that acts like a shared reference, but stores a bitwise copy of the referenced memory rather than the address
> 1751887064 288915 PRIVMSG #esolangs :14[[07Mint remake14]]4 N10 02https://esolangs.org/w/index.php?oldid=161010 5* 03Hajunsheng 5* (+835) 10Created page with "= Mint remake = Ok, I'll make this quick, it's just mint esolang but remade because the first one didn't work. [https://scratch.mit.edu/projects/1195293853/ visit] = Defining = mint is a variable stack is a stack stuffs is a stack last means last of stack = Comm
< 1751887158 567866 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :they didn't manage to add the const-reference-or-value type into C++ yet either
< 1751887176 160301 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've recently (as in, today) come to the conclusion that Rust should support a type whose representation is "a copy of the referenced object" and whose semantics are "a shared reference except you can't get the address or write cells" and implement shared references as the new type applied to a mutable reference
< 1751887202 351880 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and by "a copy of the referenced object" I mean a bitwise copy, not a type-level copy
< 1751887224 108203 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :isn't that what you wanted to write an essay about already?
< 1751887228 68229 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes
< 1751887238 159001 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, well, I want to write several essays and the boundaries between them keep changing
< 1751887269 149381 :tromp!~textual@2001:1c00:3487:1b00:a424:5b9:4dc2:8889 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1751887270 808076 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've complained for a long time that being able to get the address from a shared reference is wrong
< 1751887288 332539 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, I've only recently realised just *how* wrong iti s
< 1751887320 39461 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :would the mut reference types remain unchanged?
< 1751887336 521505 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the mutable reference types are wrong in a number of ways, but fixing them would break too much code
< 1751887345 107611 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :too much existing code, that is
< 1751887352 955797 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I think they have to be kept around
< 1751887368 682731 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(interestingly, most of the ways in which they're bad don't matter if you treat them as shared references)
> 1751887540 365422 PRIVMSG #esolangs :14[[07User talk:PrySigneToFry14]]4 10 02https://esolangs.org/w/index.php?diff=161011&oldid=160996 5* 03Cycwin 5* (+32) 10/* Any interests on joining our Esolang Tencent QQ group? */
< 1751887788 471188 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the correct way to define a mutable reference type has really different semantics, and &mut is best as syntax sugar / as an efficient way to handle the common case
> 1751887792 233508 PRIVMSG #esolangs :14[[07User:Pifrited/Simple2DMachine14]]4 10 02https://esolangs.org/w/index.php?diff=161012&oldid=160990 5* 03Pifrited 5* (+344) 10
< 1751887826 90454 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: "address from a reference", you mean (...: &T) as *T?
< 1751887829 453407 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(in particular, I think the reference should "own the value it points to" in the sense that dropping the reference leaves you with an unusable value rather than a readable one)
< 1751887847 268496 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: right
< 1751887911 130169 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Well the attitude there is that addresses are just bit patterns and uses are unsafe, as far as the Rust compiler is concerned. There's the whole Miri business with an actual memory model that I haven't really looked at though.
< 1751887939 634151 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: yes, but it makes guarantees about things you can do soundly with the resulting references, using unsafe code
< 1751887943 367559 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, the resulting pointesr
< 1751888189 976268 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: the raw pointer rules have been documented recently, and described in https://doc.rust-lang.org/nightly/std/ptr/index.html#provenance . they also added a few extra functions to handle advanced raw pointer tricks in a way that's neither UB nor prohibits too many optimizations.
< 1751888273 387926 :int-e!~noone@int-e.eu PRIVMSG #esolangs :'the reference should "own the value it points to"' -- an important use case relies on this not being the case: invoking several fn foo(&mut self) methods in a row
< 1751888275 114288 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :these new rules are relevant mostly when you turn a pointer into an integer but later want to turn it back to a pointer.
< 1751888333 907515 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"maybe you want to be able to express fn foo(self), but pass it as a reference because the object is big"?
< 1751888339 591850 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: you need syntax sugar to make that work
< 1751888341 628426 :int-e!~noone@int-e.eu PRIVMSG #esolangs :misplaced the first quite
< 1751888345 990315 :int-e!~noone@int-e.eu PRIVMSG #esolangs :quote
< 1751888349 46155 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :one of the changes that are likely to come up in your code is that if you want an atomic field that stores either a pointer or an integer then you must use AtomicPtr instead of AtomicUsize
< 1751888349 106769 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if references own the value
< 1751888354 112236 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and a few other things too
< 1751888365 906975 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but I don't see how this raises to the level of Rust being *wrong*...
< 1751888423 253346 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: thanks, I felt that I had seen this but forgot the "provenance" keyword so I would never have found it again
< 1751888457 997113 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: although I realised this a while back, I have spent ages thinking about how to argue it convincingly
< 1751888502 588398 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this may be relevant to ais523 because he's the most likely to use atomics this way
< 1751888534 716976 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: I know it already
< 1751888543 607450 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but yes, I was attempting to write that code a while ago
< 1751888572 854082 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, strict provenance doesn't work well in code that is operating on smaller-than-pointer-sized references
< 1751888577 234581 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: I don't have full context as usual. You guys are writing a novel.
< 1751888593 374807 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it'd be fine if I could extract the provenances into ZSTs and store them there, but Rust doesn't let you do that, they have to be stored in pointers
< 1751888627 51125 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :this makes it hard to use the two pointer sized atomic compare-and-modify of x86, but rust doesn't have a type for that yet
< 1751888663 647843 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I used that as an example of why you might want to use #[repr(align)], when writing a Stack Overflow answer
< 1751888691 574258 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's a bit of a weird omission because lots of atomic algorithms need to atomically operate on a pointer + a counter
< 1751889749 536821 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Is this a fair first approximation of what you want? I think you want to separate tracking ownership from addresses (in the form of references) so that you can apply ownership at a finer than byte sized granularity, and also confer ownership through types that don't necessarily contain references?
< 1751889765 7833 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: yes, I think that's a good approximation
< 1751889855 872989 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a mutable reference is effectively a) a guarantee that the referenced data has a particular type, b) an address, c) provenance on the address, d) a way to mutate the data, e) a guarantee of exclusive access to the data, f) a promise to ensure that the referenced data will always have the correct type even if the mutable reference gets unexpectedly dropped
< 1751889870 468843 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I know for certain that I want to split some of those up, but am not yet sure what the correct split is
< 1751890088 950418 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Nod nod nod... wait, f)?
< 1751890117 954912 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep – a mutable reference doesn't let you leave the data targeted by the reference in an invalid state, even temporarily
< 1751890118 658730 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I mean, once all references are dropped the data can be moved or dropped)
< 1751890146 802926 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is most noticeable in the implementation of drop(), which requires that you leave the thing you're dropping in a valid state, so you can't, e.g., move out of the fields without moving a valid placeholder value in to replace it
< 1751890149 439773 :int-e!~noone@int-e.eu PRIVMSG #esolangs :oh, "always" is short-term intermediate states, not distant future
< 1751890156 184447 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah right, yes
< 1751890179 799262 :int-e!~noone@int-e.eu PRIVMSG #esolangs :that makes sense then
< 1751890220 611616 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the "correct" signature for drop eventually got figured out by the Rust community: it should a) take the value being dropped by value, and b) support a "deconstruction" operation that splits the object into its individual fields, together with a requirement to use it rather than dropping the object normally (which would cause drop to run recursively)
< 1751890262 598626 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :deconstruction is not currently supported by Rust for things with destructors, but several people (including me and at least one of the Rust developers) think it should be
< 1751890365 179071 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one nice consequence of that implementation is that dropping becomes a mirror of construction: a constructor does { …; rv = Self { field1, field2, … }; … ; rv } and a destructor is the opposite, |arg| { …; Self { field1, field2, … } = arg; … }
< 1751890482 714909 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are a few ways to make this sort of thing backwards-compatible, too (although all of them that I'm aware of are a little hacky)
< 1751890614 555725 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Okay, I'll agree that Rust is lacking there. But it might be hard to come up with something that's more expressive, but doesn't require an inordinate amount of boilerplate and/or type annotations. (As an analogy I have this complaint about dependent types... HM types hit a sweet spot where type inference works really well, and you also don't end up with dozens of differently annotated versions...
< 1751890620 564273 :int-e!~noone@int-e.eu PRIVMSG #esolangs :...of the same type, because such annotations largely don't exist. Now I'm also a fan of some extensions like higher rank types and, ironically, GADTs... but the trick with those is to use them sparingly.)
< 1751890636 495696 :int-e!~noone@int-e.eu PRIVMSG #esolangs :@quote dependable
< 1751890636 528813 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs :int-e says: I want dependable types.
< 1751890799 194125 :int-e!~noone@int-e.eu PRIVMSG #esolangs :There's momentum too; treating references as addresses is a well-trodden path.
< 1751890854 164690 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think most recently I've been thinking about addresses as something that some types of reference are able to provide, but aren't inherent in the idea of a reference – the ability to provide an address is sort-of like an extra trait that a reference could choose to provide
< 1751890882 744518 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, they do seem at least somewhat inherent to references that you can write through, so that you can reason about whether two references are writing the same memory or not
< 1751890947 905215 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but that might not necessarily be the case: you can imagine a "buffered mutable reference" which stores the values being written elsewhere, and only updates the original memory on drop
< 1751891119 876303 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Right that works if you don't have weird things like atomics... well maybe you'd have to completely rethink the "a shared reference conveys mutable access" story for those.
< 1751891150 505040 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the whole linear-logic-? thing that I posted this morning seems to allow for that case
< 1751891174 139116 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(you can't buffer atomics)
< 1751891196 855717 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, you can if you have an *exclusive* reference to them
< 1751891203 445807 :int-e!~noone@int-e.eu PRIVMSG #esolangs :sure
< 1751891204 836985 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's just shared references that struggle
< 1751891227 894846 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a ?T is like a T except that anything that consumes it has to be prepared to potentially be run as multiple copies, maybe in parallel, while it's consuming the T – in particular this means that it can't while consuming it make use of anything that isn't `Copy`
< 1751891242 746368 :int-e!~noone@int-e.eu PRIVMSG #esolangs :These comments are based on the current treatment of atomics in Rust, with shared references.
< 1751891266 774242 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, but the "buffered mutable reference" was based specifically on mutable references, so it doesn't interact with atomics
< 1751891301 665168 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Fair
< 1751891303 782175 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, I realised a while back that the current Rust *semantics* of UnsafeCell are that references that point to the outside of the UnsafeCell don't have provenance over the inside
< 1751891321 608133 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :not only does the whole API match that, the type-system-level behaviour seems to too
< 1751891375 215033 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you could replace an UnsafeCell with a Box> (assuming the box is appropriately-sized), with mutations happening inside the box, and nothing would semantically change
> 1751891742 646188 PRIVMSG #esolangs :14[[07User:Tommyaweosme14]]4 10 02https://esolangs.org/w/index.php?diff=161013&oldid=160817 5* 03Tommyaweosme 5* (+333) 10
> 1751891906 497794 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5* 10deleted "[[02Category:Sandies10]]": unapproved category, doesn't have a clear definition or use case
> 1751891943 708434 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5* 10deleted "[[02Category:Games10]]": category redirects don't actually work correctly, so they shouldn't be made
> 1751891968 682008 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5* 10deleted "[[02Category:Commands10]]": apparently created in error, but wasn't deleted until now
> 1751891994 282045 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5* 10deleted "[[02Category:Themed10]]": unapproved category, redundant to existing [[Category:Thematic]]
> 1751892498 353075 PRIVMSG #esolangs :14[[07Semi-serious language list14]]4 10 02https://esolangs.org/w/index.php?diff=161014&oldid=158199 5* 03Ais523 5* (+16) 10/* T */ +[[Turn Left]]: it has an interpreter now
< 1751892568 169415 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Remote host closed the connection
< 1751892584 777366 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse
< 1751893016 235046 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`unidecode &
< 1751893019 860038 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :[U+0026 AMPERSAND]
< 1751893103 422325 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`unidecode ⅋
< 1751893106 300083 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :[U+214B TURNED AMPERSAND]
< 1751893527 482558 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
> 1751893802 131411 PRIVMSG #esolangs :14[[07User:Pifrited/Simple2DMachine14]]4 M10 02https://esolangs.org/w/index.php?diff=161015&oldid=161012 5* 03Pifrited 5* (-9) 10/* Commands */
< 1751893918 841356 :tromp!~textual@2001:1c00:3487:1b00:dc8d:bec7:d518:96e2 JOIN #esolangs * :Textual User
> 1751894351 736436 PRIVMSG #esolangs :14[[07User talk:Pifrited/Simple2DMachine14]]4 10 02https://esolangs.org/w/index.php?diff=161016&oldid=160933 5* 03Pifrited 5* (+197) 10
> 1751894373 317397 PRIVMSG #esolangs :14[[07User talk:Pifrited/Simple2DMachine14]]4 M10 02https://esolangs.org/w/index.php?diff=161017&oldid=161016 5* 03Pifrited 5* (+1) 10
< 1751895644 645177 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1751895798 496871 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: but what happens when the type that the reference points to has interior mutability like an UnsafeCell field? you can't use a bitwise copy for that instead of the original one.
< 1751895815 320792 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :similarly for an Atomic field
< 1751896087 827449 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But conceptually, given a mutable reference, you can move the value out, modify it, and move it back in. Unless the object is pinned.
< 1751896147 707538 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Operationally that move can be done by making a copy and relying on the fact that nobody can touch the original.
< 1751896181 204101 :int-e!~noone@int-e.eu PRIVMSG #esolangs :The thing that you break is that the mutable reference stops pointing to a valid object (it becomes stale) while you're working with the copy.
< 1751896234 92244 :int-e!~noone@int-e.eu PRIVMSG #esolangs :("thing" - a guarantee that Rust currently has. Well, I'm taking ais523's word for that.)
< 1751896728 115873 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: totally unrelated, I've started actually toying with the wire things in shapez 2 and there's a huge change in how signals are propagated. It's no longer feeding the old wire states into the components and combining the outputs on the connected wires each tick; signals propagate much further in a single tick. Which breaks my shapez 1 edge triggers. OTOH a not gate feeding into itself...
< 1751896734 125444 :int-e!~noone@int-e.eu PRIVMSG #esolangs :...will still flicker, so maybe signal propagation stops when it comes a full circle. Details are unclear to me. Maybe every logic gate is updated at most once per tick?
< 1751896851 722126 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: I was thinking of such a system for a hypothetical game, but in a way that explicitly allows you to introduce delays
< 1751896860 559969 :int-e!~noone@int-e.eu PRIVMSG #esolangs :On the plus side, my not+transistor+or RS-flip-flop still works. Which coupled with a clock should be enough to bootstrap clocked circuits.
< 1751896900 941233 :int-e!~noone@int-e.eu PRIVMSG #esolangs :yeah a D flip-flop would be helpful
< 1751896902 823360 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :is there no explicit memory cell or delay or similar object?
< 1751896917 987332 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :possibly behind later research
< 1751896951 330239 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I have all the research. The only explicit delay I've found is the global communication, which has a half second delay or so.
< 1751896951 498817 :ais523!~ais523@user/ais523 QUIT :Quit: sorry about my connection
< 1751897020 547356 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I see
< 1751897033 823983 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Anyway. It's a change. There's an up-side to it too, obviously; deeper circuits are no longer slow.
< 1751897055 841782 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I'll keep experimenting.
< 1751897096 569400 :int-e!~noone@int-e.eu PRIVMSG #esolangs :a transistor feeding into itself will still keep a value alive at least.
< 1751897113 424226 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1751897144 958174 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :do transistors consistently add a delay, eg. for just the control input?
< 1751897151 254262 :int-e!~noone@int-e.eu PRIVMSG #esolangs :nope
< 1751897158 520876 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : ais523: but what happens when the type that the reference points to has interior mutability like an UnsafeCell field? you can't use a bitwise copy for that instead of the original one. ← indeed, writing to a cell needs the address
< 1751897176 923019 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(tried that. that was my (and I suppose everybody else's) default delay in shapez 1 after all)
< 1751897190 110432 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it conceptually works because the data inside the cell isn't part of the copy – it's referenced by the copy – but doesn't physically work because the computer doesn't know where the cell actually is
< 1751897198 246451 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: reading from the cell needs the address too, if you don't exclusively own the cell
< 1751897208 306347 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes
> 1751897887 991824 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=161018&oldid=161002 5* 03PrySigneToFry 5* (+26) 10
< 1751899309 778353 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: Oh no! The order in which you place the gates matters now. And pasting blueprints doesn't preserve it.
< 1751899325 669232 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :uh
< 1751899403 276137 :int-e!~noone@int-e.eu PRIVMSG #esolangs :though you can tweak the order in which buildings are in the blueprint by changing its orientation when you create the blueprint
< 1751899412 855684 :int-e!~noone@int-e.eu PRIVMSG #esolangs :this might not be fun.
< 1751899477 817417 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :in games like this you often can't really make the rules symmetric to all the reasonable symmetries in all cases
< 1751899501 362756 :int-e!~noone@int-e.eu PRIVMSG #esolangs :right but shapez 1 was an exception as far as the wire layer was concerned
< 1751899521 250878 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but ideally you want to make it not matter too much for the player, at least if the player keeps certain rules that don't restrict them too much
< 1751899585 129669 :int-e!~noone@int-e.eu PRIVMSG #esolangs :huh I wonder whether loading and saving breaks this too then
< 1751900094 320855 :int-e!~noone@int-e.eu PRIVMSG #esolangs :well saving and loading certainly changes something
< 1751900096 14016 :int-e!~noone@int-e.eu PRIVMSG #esolangs :UGH
< 1751900319 815686 :int-e!~noone@int-e.eu PRIVMSG #esolangs :https://int-e.eu/~bf3/tmp/shapez2-wire-trouble.jpg -- this is after saving and loading; the left variant started out as a copy of the right one. 5 work fine (one can store a provided value in the single transistor loop) but for the other three it doesn't work.
< 1751900367 224776 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I tried the shapez 1 demo but didn't enjoy it
< 1751900388 654872 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in general, that sort of game seems like it would be more interesting if you do the computation with the same pieces that you make the shapes out of, rather than having an entire separate system
< 1751900438 892635 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I think what changes is the order in which the not gate and the two transistors are evaluated, and I currently conjecture that the update process starts with a changed signal and propagates changes from there, but only ever updating any gate once.
< 1751900514 853277 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Not because I can confirm it experimentally but because it's a plausible implementation. I could maybe check whether DAGs update consistently in a single cycle.
< 1751900711 3338 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: in the demo, did you reach the two puzzles, which is how to make the last two upgrade shapes? because that's I think one of the interesting parts of this game.
< 1751900712 110665 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Eh it's not primarly a model of computation. It's support for automation, with the specific goal that the game can request a shape and there's enough logic to disect it and guide production accordingly.
< 1751900763 624758 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(Does the demo even have the wire layer? I forgot.)
< 1751900949 360551 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: the new version of the demo definitely doesn't; I think the old version doesn't either but I don't remember for sure how far it goes
< 1751900956 297445 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
< 1751901122 556157 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I really don't think of shapez (1 or 2) as a programming game. Obviously there are aspects to it that appeal to programmers... making modular reusable designs, mostly. And there's a strong golfing component to it too if you're so inclined. But then it's a sequence of puzzles, figuring out recipes to make certain shapes. And finally using the wire layer for automation, and then the only thing...
< 1751901128 563514 :int-e!~noone@int-e.eu PRIVMSG #esolangs :...that's left is either tinkering with those things endlessly or making up your own tasks in a sandbox.
< 1751901528 685055 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: also maybe I misunderstood... the wire layer absolutely can simulate the production part; it's not just 0s and 1s, wires can carry (virtual) shapes.
< 1751901589 385765 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I'm just not playing with that right now because I'm more worried about state management / control flow.
< 1751901742 373242 :int-e!~noone@int-e.eu PRIVMSG #esolangs :And sure, you could restrict the wires to only have shapes, but you'd probably not change it significantly; you'd want to encode a conditional somewhere, and in a non-esoteric fashion because making it complicated would reduce your audience to a dozen people who enjoy this kind of thing and play the game. :P
< 1751901825 669058 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I've seen people struggle with the wire layer as it is, with its very mundane logic signaling part.)
< 1751901842 174046 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Anyway. You dislike it and that's okay :-P
< 1751901959 805790 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: I was thinking more of using the production part to simulate the wire layer
< 1751901980 611451 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, having machines that turn on and off based on whether you paint them red or blue, that sort of thing
> 1751902024 283092 PRIVMSG #esolangs :14[[07User:Aadenboy14]]4 M10 02https://esolangs.org/w/index.php?diff=161019&oldid=160982 5* 03Aadenboy 5* (+19) 10/* VSCode Box Drawing */ I got a review!
> 1751902108 230437 PRIVMSG #esolangs :14[[07Semi-serious language list14]]4 10 02https://esolangs.org/w/index.php?diff=161020&oldid=161014 5* 03PkmnQ 5* (+60) 10Add a few queue-based languages (may add more later)
< 1751902132 457943 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: yeah that would be a completely different type of game
< 1751902218 115514 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it seems so superflous to have two different types of thing (wire signals and manufacturing components) when one would do
< 1751902290 414430 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess the extreme version of this viewpoint would be to be able to put machine components on the belts (including belts) so that your machine could manufacture itself
< 1751902319 474762 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and create a make-anything-machine that handles all the tasks it's ever been given simultaneously, rather than switching from one goal to the next
< 1751903004 860532 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I /think/ the wire stuff does a topological sort (but breaking loops in an unpredictable way, well, unpredictable to me)
< 1751903019 438150 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it might be arbitrary, I guess?
< 1751903036 864624 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :based on something like iteration order over a hash table
< 1751903040 216664 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's what tsorts do by "default"
> 1751903070 265018 PRIVMSG #esolangs :14[[07User:Hotcrystal0/Chess piece strength14]]4 10 02https://esolangs.org/w/index.php?diff=161021&oldid=160997 5* 03Hotcrystal0 5* (+17) 10
< 1751903187 456 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm, no, that isn't right. Under that theory my basic memory cell should work fine.
< 1751903203 187630 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(in isolation)
< 1751903533 893644 :tromp!~textual@2001:1c00:3487:1b00:dc8d:bec7:d518:96e2 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1751904299 863359 PRIVMSG #esolangs :14[[07Talk:YOUR TAKING TOO LONG14]]4 N10 02https://esolangs.org/w/index.php?oldid=161022 5* 03PlaceReporter99 5* (+151) 10Created page with "So this is just a derivative of [[bf]]? ~~~~"
< 1751905362 147140 :tromp!~textual@2001:1c00:3487:1b00:dc8d:bec7:d518:96e2 JOIN #esolangs * :Textual User
< 1751905796 955212 :b_jonas!~x@88.87.242.184 JOIN #esolangs b_jonas :b_jonas
< 1751906094 440619 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: people have used Factorio belts (and splitters and undergrounds, but without circuit signals or other tricks) to simulate arbitrary logic circuit. this is rather inefficient and so esoteric. I'm not sure how hard it would be in shapez.io 1, because shapez.io 1 doesn't have convenient priority merges. but this uses only where the items are on the belt rather than where they are. for shapez 1, if
< 1751906100 440891 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :you want to add new builtins to make it easier to use the belts for computation, you have to be careful that they don't cook shapez1's puzzles or make the game too much easier. .
< 1751906152 909863 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess I considered the puzzles I saw sufficiently easy to not consider them to add to the game
< 1751906189 297925 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am not sure whether I saw all of them or not
< 1751906197 506124 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :in my head the idea is that logic computation should be free, but producing specific shapes on belts, especially in large numbers quickly, is the task that you need to solve, and so shouldn't be free.
< 1751906221 657580 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: there's really only two of those fixed level shapes that stump people, both variations on the same idea
< 1751906257 984302 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the existence of an MAM also implies the existence of a simple algorithm for constructing any given shape
< 1751906304 714476 :int-e!~noone@int-e.eu PRIVMSG #esolangs :one is https://viewer.shapez.io/?RuCw--Cw:----Ru-- and the other one is https://viewer.shapez.io/?CbCuCbCu:Sr------:--CrSrCr:CwCwCwCw and both feature things that aren't directly supported from below.
< 1751906318 139348 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: that's why I'm asking if you produced the last two upgrade shapes, https://viewer.shapez.io/?RuCw--Cw:----Ru-- and https://viewer.shapez.io/?CbCuCbCu:Sr------:--CrSrCr:CwCwCwCw . these are puzzles where you have to experiment to learn what exactly the rules for the cutter and stacker are, and then figure out how to use them to build those shapes, especially in large numbers without manual
< 1751906324 630103 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :intervention
< 1751906327 181732 :int-e!~noone@int-e.eu PRIVMSG #esolangs :the rest of the game up to the MAM stage is just building
< 1751906346 537739 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :these are also level goal shapes, but those levels aren't in the demo, only the upgrades are.
< 1751906368 754216 :int-e!~noone@int-e.eu PRIVMSG #esolangs :oh I had not considered that you could still go for all those upgrades in the demo
< 1751906371 944972 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OK, so the challenge in the first one is to construct the higher-level corner without it falling down?
< 1751906373 63292 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and find the shapes that way
< 1751906380 6899 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes
< 1751906442 84585 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah, I think in that case the puzzle is understanding what the game mechanics are – I expect the solution to be simple but not necessarily easy to find as you might have to determine the mechanics by experiment
< 1751906452 129958 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: I realized that back when I recommended the game to tom7, because he makes the kind of puzzles where you have to experiment to learn the rules.
< 1751906478 899262 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes
< 1751906488 185286 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wouldn't expect variations to the game to break the puzzle, in that case
< 1751906609 333087 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :not having the game open or really remembering the rules, I would guess that the solution would be something like "create a shape with an arbitrary nonempty right half at the lowest level, a white quarter-circle in the top-left and nothing in the bottom-left; stack the bottom half of a gray square on it; then cut off the right half and replace it with the correct right half"
< 1751906640 71756 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as that's the sort of solution for which I can imagine rules where that's the simplest solution, whereas most rules I'm considering make it either trivial or impossible
< 1751906740 378206 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :as for "to be able to put machine components on the belts (including belts) so that your machine could manufacture itself" => that's what Factorio does. Factorio has the severe restriction that almost any building has to be constructed using one type of item (usually just one instance of the item but that's not strict), rather than assembled in place at construction time from multiple types of items.
< 1751906746 525643 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that's mostly to make the vanilla game an interesting challenge and simple, but it sort of hurts modded variants. if you want to construct buildings from multiple types of items then you have to play Settlers.
< 1751906854 374591 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: I did get some entertainment out of the puzzle mode dlc, which focusses on finding recipes and golfing. (Puzzles are crowd-sourced, but there's a reasonably functional difficulty assessment that looks at how many people who try a puzzle actually solve it and maybe also at the time taken.)
< 1751906876 337358 :int-e!~noone@int-e.eu PRIVMSG #esolangs :they inevitably suffer from overused themes of course
< 1751906906 864574 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"difficulty assessment that looks at how many people who try a puzzle actually solve it and maybe also at the time taken." => ah, the Mario Maker difficulty system
< 1751906943 590383 :int-e!~noone@int-e.eu PRIVMSG #esolangs :one such theme is... people have figured out that you can encode number link with just producers, goals, and belts, disallowing everything else, so there's a *ton* of number link puzzles in there.
< 1751906988 943223 :int-e!~noone@int-e.eu PRIVMSG #esolangs :so... it's flawed
< 1751907277 99833 :tromp!~textual@2001:1c00:3487:1b00:dc8d:bec7:d518:96e2 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1751907578 181608 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I'll also remark that for me personally, shapez 1 was the first conveyor belt factory game that I playes, as such it's a gateway drug into Factorio. and since shapez 1 has a definite goal that you can reach in a not too long playtime, it works as such a gateway drug for other players too.
< 1751908063 231185 :tromp!~textual@2001:1c00:3487:1b00:dc8d:bec7:d518:96e2 JOIN #esolangs * :Textual User
< 1751910330 852928 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :About puzzles that you will have to experiment to figure out the rules, for games that include the source codes the way would be to examine the source codes to figure out the rules.
< 1751910404 318558 :shikhin!~shikhin@offtopia/offtopian QUIT :Quit: Quittin'.
< 1751910510 942248 :shikhin!~shikhin@ahti.space JOIN #esolangs * :shikhin
< 1751910588 834129 :shikhin!~shikhin@ahti.space CHGHOST ~shikhin :offtopia/offtopian
< 1751910719 161609 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :In the case of some Hero Hearts puzzles (e.g. SUPERHRO:384-403), it says there are tricks that you will have to work hard to discover, and also objects hidden behind other objects. The original game engine is not FOSS but the source code for the implementations of the classes is available (actually they are stored as P-code and decompiled when you want to edit them).
< 1751910749 565919 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :So, sometimes behaviours (including unintended consequences of them) can be found from examining these codes.
< 1751911058 775595 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :The documentation does have some details about the internal working of the game engine, but I have found it to be incomplete and incorrect in many ways. I have made experiments to figure out the actual working and reimplemented it, now as FOSS, so that now the rules can actually be read and figured out that way.
< 1751911390 549774 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zzo38: yes, and I did eventually examine the source code of shapez.io to learn how freeplay shapez are rolled, and later the rules for stacking too.
< 1751911541 594461 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :(I also implemented the ability to right-click on a grid cell to display a list of all of the objects in that grid cell, so that it is a game of complete information.)
< 1751912716 454199 :ais523!~ais523@user/ais523 QUIT :Quit: quit
< 1751913735 59492 :APic!apic@apic.name PRIVMSG #esolangs :Good Night
< 1751916782 114196 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Regarding linear logic: we can quickly check whether a modality is one of the two canonical exponentials by asking if they satisfy universal laws. For the ? modality, the relevant law is that it's a monad; X o- ?X and ??X o- ?X naturally for any X.
< 1751916824 487231 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :So a shared ref of a shared ref would still be a shared ref. Seems plausible. Indeed, this seems like something that would have arisen in the literature already, although most folks study ! instead since ! is required for the intuitionistic-linear bridge.
< 1751916922 297490 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, those lollys should be the other way around, X -o ?X and ??X -o ?X. Whoops.
> 1751920355 885335 PRIVMSG #esolangs :14[[07Ougsoeei14]]4 N10 02https://esolangs.org/w/index.php?oldid=161023 5* 03Bebebe 5* (+221) 10Created page with "{{infobox proglang |name=Ougsoeei |author=[[User:bebebe]] |year=2025 }} {{wip}} Ougsoeei is from [[User: bebebe]](this is a nickname). bebebe's goal was to create a highly illogical and inconsistent esolang for people."
> 1751921266 881970 PRIVMSG #esolangs :14[[07Qdeql14]]4 10 02https://esolangs.org/w/index.php?diff=161024&oldid=53701 5* 03Stkptr 5* (+20) 10
> 1751921276 774561 PRIVMSG #esolangs :14[[07Queuenanimous14]]4 10 02https://esolangs.org/w/index.php?diff=161025&oldid=156777 5* 03Stkptr 5* (+12) 10
> 1751923365 690952 PRIVMSG #esolangs :14[[07Main Page14]]4 10 02https://esolangs.org/w/index.php?diff=161026&oldid=155804 5* 03Bebebe 5* (+2) 10
> 1751923411 422324 PRIVMSG #esolangs :14[[07Main Page14]]4 10 02https://esolangs.org/w/index.php?diff=161027&oldid=161026 5* 03Bebebe 5* (-2) 10
< 1751923790 29111 :tromp!~textual@2001:1c00:3487:1b00:dc8d:bec7:d518:96e2 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1751923833 582229 PRIVMSG #esolangs :14[[07Ougsoeei14]]4 10 02https://esolangs.org/w/index.php?diff=161028&oldid=161023 5* 03Bebebe 5* (-184) 10
> 1751924590 899056 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Dmitry samorodyuk 5* 10New user account
< 1751925878 873448 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
< 1751927362 644437 :janewila!~janewila@2607:fb90:bd10:97b7:8591:1cb7:4609:df3c JOIN #esolangs * :[https://web.libera.chat] janewila
< 1751928321 116225 :janewila!~janewila@2607:fb90:bd10:97b7:8591:1cb7:4609:df3c QUIT :Quit: Client closed
< 1751929977 725311 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement