←2018-11-27 2018-11-28 2018-11-29→ ↑2018 ↑all
00:00:41 <zzo38> O, I found a Python program at https://github.com/shmup/mtgsqlive which is made for converting Magic: the Gathering card data from JSON to SQLite and vice versa
00:01:05 <b_jonas> how old? does it work with the Scryfall format?
00:02:35 <zzo38> It says MTGJSON format, although maybe it might be possible to modify to work with Scryfall format
00:22:56 -!- Phantom_Hoover has quit (Read error: Connection reset by peer).
00:32:47 -!- Melvar has quit (Ping timeout: 240 seconds).
01:14:55 -!- Sgeo has joined.
01:16:24 -!- Sgeo_ has quit (Ping timeout: 250 seconds).
01:20:30 -!- imode has joined.
01:27:49 -!- Melvar has joined.
01:31:52 <shachaf> oren: I'm still not sure how that proposal works but I like it more now.
01:44:34 -!- danieljabailey has quit (Ping timeout: 250 seconds).
01:49:26 -!- imode has quit (Ping timeout: 268 seconds).
01:54:55 -!- imode has joined.
02:00:10 -!- imode has quit (Ping timeout: 250 seconds).
02:11:05 -!- danieljabailey has joined.
02:37:02 -!- ais523 has quit (Quit: quit).
02:39:10 -!- Melvar has quit (Ping timeout: 250 seconds).
02:41:14 -!- imode has joined.
04:00:00 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
04:52:46 -!- Melvar has joined.
05:26:33 -!- oerjan has joined.
05:39:12 <zzo38> One idea about UNIX kernels is adding a new kind of kill() function that requires a timestamp, and if the target process started after the specified time then it is an error and no signal is sent.
05:52:32 -!- xkapastel has quit (Quit: Connection closed for inactivity).
06:43:50 -!- hexfive has joined.
08:01:24 -!- AnotherTest has joined.
08:18:38 -!- pikhq has quit (Ping timeout: 244 seconds).
08:31:56 <izabera> interesting
08:32:39 <izabera> i like the idea of making pid_t an always-increasing 64bit number
08:32:47 <izabera> no pid reuse ever occurs
08:40:24 <shachaf> pids are scow
08:43:18 <shachaf> no way to avoid the race
08:47:05 <izabera> what race?
08:49:15 <shachaf> Between getting a pid and killing it
08:51:53 <shachaf> E.g. in Windows you get a handle to a process, which is more like a fd (I think?)
08:57:03 <izabera> nonreusable pids would totally avoid any race
08:59:53 <shachaf> Sure
09:11:23 <oren> yeah pids are annoying because in the time it takes to do 'ps', read the pid you need, and 'kill' it, the process could potentially end, and the pid could be reused
09:13:57 <shachaf> I mean, you potentially want to hold a pid for much longer than that.
09:14:12 <oren> that too
09:15:39 <oren> also, it's possible to mistype a pid and kill the wrong process, which is why I think there should be a more interactive tool for looking at and killing processes
09:16:09 <oren> like if 'top' had a way to select a process and kill it
09:17:43 -!- sftp has quit (Excess Flood).
09:18:08 -!- sftp has joined.
09:19:50 <b_jonas> zzo38: oh, I've actually been asked about something like that, outside of #esoteric, as in, how to use a pid (in kill or otherwise) without accidentally targeting the wrong process
09:21:27 <b_jonas> izabera: sadly we can't just change pids to 64-bit, there are a lot of kernel-process abis that expect them to be 32-bit. the only thing we could do is add a second kind of pid and consistently call it a different name than pid. but there are like three dozen system calls and all of /proc that's based on pids, so that's not an easy change.
09:21:54 <b_jonas> or technically we could start a new architecture, but even then there'll be badly programs that use an int instead of a pid_t.
09:22:32 <shachaf> unix is scow anyway
09:22:33 <shachaf> scrap it
09:23:06 <b_jonas> oren: there's a little bit of protection top could do, but I don't know of a complete protection. let me check that old email where someone asked me this.
09:26:31 <b_jonas> I think, instead of a new pid, it might be easier to add new interfaces that allow you to do various process operations like kill, sigqueue, setpriority etc given a directory handle into /proc, sort of like the openat family of functions
09:37:56 <b_jonas> yup, we didn't find a good workaround
09:39:24 <b_jonas> I mean, we know some partial workarounds, but nothing that really guarantees to solve the problem in worst case when someone forks really quickly, the scheduler is against you, and you don't want potentially bad side effects
09:41:33 <shachaf> Is fork even a good API? Is it worth all the trouble?
09:41:43 <shachaf> What's the benefit of it?
09:44:32 -!- pikhq has joined.
10:04:02 <oerjan> . o O ( sounds like a challenge, ms. ambrose )
10:13:45 <Taneb> oerjan: dehydrated space rations are soemthing I could well concieve a michelin-starred restaurant serving
10:23:00 <oerjan> they'd just turn it into foam first
10:23:25 <oerjan> shave ->
10:36:02 -!- pikhq has quit (Read error: Connection reset by peer).
10:36:29 -!- pikhq has joined.
10:38:11 <b_jonas> shachaf: IMO it's worth, though some of its design has led to hard to track down bugs. look at the complicated structures that the Win32 API has to use to define all the state that the new process gets.
10:38:37 <b_jonas> shachaf: bugs for fork include accidentally ignored signals inherited by subprocesses, file descriptors leaked by multithread race conditions, etc.
10:39:42 <b_jonas> but some of those aren't a problem with fork. file descriptors should have started out not inheritable *on exec* by default (which is what Win32 does; inheriting through fork is fine)
10:47:32 -!- imode has quit (Ping timeout: 250 seconds).
11:05:28 -!- rain1 has quit (Ping timeout: 245 seconds).
11:11:17 -!- b_jonas has quit (Quit: leaving).
11:27:21 <oerjan> the last panel here is looking more and more like a chekhov's gun at this point http://www.girlgeniusonline.com/comic.php?date=20180326
11:29:30 <oerjan> ...and today mezzacotta loaded instantly for once.
11:43:36 -!- xkapastel has joined.
11:49:52 -!- oerjan has quit (Quit: Later).
13:35:40 -!- sebbu2 has joined.
13:39:21 -!- sebbu has quit (Ping timeout: 252 seconds).
15:03:50 -!- arseniiv has joined.
15:06:05 -!- AnotherTest has quit (Ping timeout: 268 seconds).
15:19:26 -!- AnotherTest has joined.
16:11:03 -!- rain1 has joined.
16:29:09 -!- imode has joined.
17:02:48 -!- imode has quit (Ping timeout: 250 seconds).
17:04:07 -!- nfd9001 has quit (Ping timeout: 240 seconds).
17:05:35 -!- imode has joined.
17:20:29 -!- AnotherTest has quit (Ping timeout: 246 seconds).
17:31:24 -!- AnotherTest has joined.
17:36:03 -!- sebbu2 has changed nick to sebbu.
17:47:46 <esowiki> [[Special:Log/newusers]] create * Abc123mewot * New user account
18:05:47 -!- arseniiv has quit (Quit: gone completely :o).
18:12:00 <esowiki> [[Talk:Capuirequiem]] https://esolangs.org/w/index.php?diff=58509&oldid=9562 * Nthern * (+212) /* Implementation Source */ new section
18:18:37 -!- arseniiv has joined.
18:23:10 -!- Essadon has joined.
19:11:11 -!- Phantom_Hoover has joined.
19:20:58 -!- sleepnap has joined.
19:48:56 <esowiki> [[User:DMC]] M https://esolangs.org/w/index.php?diff=58510&oldid=58507 * DMC * (+101)
20:08:10 -!- imode has quit (Quit: WeeChat 2.3).
20:14:31 <zzo38> Maybe one way is to reserve one process ID number for a timestamp PID, and one function takes a timestamp and PID and always returns the timestamp PID number; any call in the same thread which is using timestamp PID will use the remembered timestamp and PID.
20:15:04 <zzo38> (This is not important for waitpid() which is only for child processes; it is used when you want to deal with processes other than child processes.)
20:18:14 <esowiki> [[User:DMC]] M https://esolangs.org/w/index.php?diff=58511&oldid=58510 * DMC * (-6)
20:19:02 <esowiki> [[User:DMC]] M https://esolangs.org/w/index.php?diff=58512&oldid=58511 * DMC * (+10)
20:19:06 -!- imode has joined.
20:19:41 -!- imode has quit (Client Quit).
20:20:45 -!- imode has joined.
20:25:13 -!- MDude has quit (Quit: Going offline, see ya! (www.adiirc.com)).
20:25:30 <zzo38> I did think of using /proc too
20:26:45 <zzo38> So, that is another possibility to do, using the functions like openat() and so on
20:33:25 <zzo38> (If you use that then you can check the timestamps)
21:02:40 -!- b_jonas has joined.
21:06:30 <shachaf> b_jonas: fork also requires a complicated implementation with copy on write
21:06:40 <shachaf> And it precludes or nearly precludes having a single address space
21:07:32 <shachaf> b_jonas: It seems to me that maybe better APIs for operating on other processes would be better than the fork approach?
21:07:45 -!- Lord_of_Life has joined.
21:07:45 -!- Lord_of_Life has quit (Changing host).
21:07:45 -!- Lord_of_Life has joined.
21:09:06 <zzo38> There is vfork() but it is deprecated and the way of its working is different on different systems.
21:10:28 <b_jonas> shachaf: so? we already need full copy on write for mmap MAP_PRIVATE, probably even for MAP_SHARED as an optimization, for loading a writable but initialized data segment of an executable, etc. The problem isn't the complicated, but that some people complain that forking can take a long time if the forking process has a lot of memory associated to it.
21:11:04 <b_jonas> But the answer to that is just "then don't do that". Prefork from a smaller parent process, not from the database server process that mmaps your hundred gigabyte database read-write and starts a hundred threads.
21:11:58 <b_jonas> Fork is simply more general, because if you want, you can still make a spawn-like model by having a fork server process and serializing only the state you want the child to have to it from the controlling process through some controlling channel.
21:11:58 <shachaf> That's kind of a silly answer, why shouldn't the database process be able to run programs?
21:12:05 <b_jonas> But you couldn't do it the other way.
21:12:45 <b_jonas> shachaf: the database server can, but not from the large process. if you have such a huge process, it doesn't cost much to have a smaller watcher process. that can do other things too, like log fatal failures of the big process or whatever.
21:13:17 <b_jonas> I'm not saying that you should always fork. By all means, use a single spawn server process with clean state if you want.
21:13:56 <shachaf> The fact that MAP_PRIVATE requires copy-on-write when you specifically request it doesn't mean that you should just give up and COW all the time everywhere.
21:14:29 <b_jonas> But don't expect the kernel itself to have a small and simple spawn function, because the kernel doesn't know what the "sane defaults" for the new process are, if there were sane defaults they'd be obsolete in three years, and there's not much point to have a huge spawn function that takes a hundred arguments to set all process state.
21:14:55 <shachaf> I'm not saying there should be one-size-fits-all defaults.
21:14:59 <zzo38> You could do that kind of prefork, it could be helpful
21:15:06 <shachaf> But it's a long way to go from that to fork.
21:15:20 <b_jonas> shachaf: there are library wrappers over that, if you want. ones with and ones without pre-forking.
21:15:29 <b_jonas> shachaf: heck, I think they even added one to posix
21:15:49 <shachaf> posix_spawn?
21:15:50 <b_jonas> shachaf: and if COW is really your problem, then cheat with vfork, but that's _hard_.
21:15:56 <b_jonas> shachaf: something like that, yes.
21:16:08 <pikhq> b_jonas: posix_spawn is expected to use a vfork-analog, FWIW.
21:16:14 <pikhq> (and on common systems, actually *does*)
21:16:18 <b_jonas> and then good luck setting up whatever process state that particular spawn doesn't support.
21:16:55 <pikhq> Yeah, posix_spawn is definitely somewhat limited in the state it can set up.
21:17:13 <pikhq> I believe it has enough to set up the state a POSIX shell would need to, but not much more.
21:17:17 <b_jonas> exactly. and every spawn will be, unless it takes huge tables emulating every system call ever.
21:17:33 <shachaf> What's the argument in favor of fork? That it's convenient to set up a particular process state after forking?
21:17:46 <pikhq> The "easy" workaround is to use a helper binary to do more.
21:18:27 <pikhq> shachaf: It was easy to implement back in the day, while obviously being sufficiently general to serve the task.
21:18:29 <b_jonas> shachaf: that, and fork isn't hard to implement by the kernel once it already wants that and multithreading and general mmaps and shared memory
21:18:46 <b_jonas> it's still easy to implement now
21:19:04 <shachaf> Some Win32 functions let you operate on a different process. For example VirtualAllocEx lets you allocate memory in another process's address space.
21:19:16 <shachaf> I wish Unix had that.
21:19:31 <shachaf> For debuggers if nothing else.
21:19:32 <b_jonas> and if you complain about the speed, just look at how slow in practice it is to spawn a thousand simple small programs from a simple small program on win32, and on unix. unix still wins by like two orders of magnitudes.
21:19:51 <b_jonas> shachaf: linux has most of that, with a combination of /proc and ptrace
21:19:58 <pikhq> I think if I were designing a thing now, I'd set it up so you could create a "zygote" process, use system calls on it to set the state, and then start the process.
21:20:09 <shachaf> pikhq: Yes, that's what I was thinking.
21:20:13 <b_jonas> ptrace and much of /proc are definitely for debugging only
21:20:14 <shachaf> b_jonas: How do you mmap in a child process?
21:20:16 <b_jonas> but they're very general
21:20:40 <pikhq> But, to be honest, I wouldn't design a thing now. There's no fucking way it'd do anything more than be personally entertaining.
21:21:08 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
21:21:27 <b_jonas> shachaf: hmm, yes, that in particular might be hard and it may be good if there was an interface for it. you'd probably have to take over a little spare space in the process to bootstrap that, save its contents and the registers, and run an mmap call in there. and catch all signals during.
21:21:50 <b_jonas> and if that process has no writable page, you're screwed.
21:22:04 <shachaf> ptrace can write to non-writable pages
21:22:13 <b_jonas> what? no way
21:22:14 <shachaf> It converts them from MAP_SHARED to MAP_PRIVATE if necessary
21:22:17 <shachaf> In Linux at least.
21:22:20 <b_jonas> wtf
21:23:51 <b_jonas> shachaf: still, it can be hard to restore it to MAP_SHARED later if you can no longer acquire a handle to the underlying file or shared memory segment or bsd shared memory segment from /proc
21:24:09 <shachaf> Right.
21:24:10 <zzo38> You can use ptrace for system call emulation and other stuff like that too and does not have to be only for debugging
21:24:22 <b_jonas> s/or shared memory segment or bsd shared memory segment/or sysv shared memory segment or posix shared memory segment/
21:25:04 <b_jonas> oh yeah!
21:25:20 <b_jonas> hmm no
21:25:25 -!- Lord_of_Life has joined.
21:25:25 -!- Lord_of_Life has quit (Changing host).
21:25:25 -!- Lord_of_Life has joined.
21:25:33 <b_jonas> I think you still need a little bit of writable memory in the process address space for that
21:26:02 <b_jonas> if you're planning to debug, you can probably just arrange to set aside a little space for that
21:26:53 <b_jonas> zzo38: the system call emulation is the opposite of what we want
21:27:58 <b_jonas> zzo38: system call emulation means that the traced process calls for a system call, but you ask linux not to perform that call, instead you do whatever you want and set then registers in the traced process to pretend whatever result you want from the system call and continue it. you could jump away to run other code for that if you want.
21:28:10 <b_jonas> that thing is heavy, you rarely want to do that, but it's possible
21:28:18 <b_jonas> usually there are better ways for most special cases
21:28:44 <b_jonas> like replacing library functions or fuse
21:31:22 <zzo38> Sometimes you might want to override some system calls, such as to change the time that the program knows, or to use a proxy server for all network connections if the program does not implement that, or to change things in a program that you do not have the source code to be able to recompile it, etc
21:43:43 <oren> c++ gore:
21:44:03 <oren> cout << "percent errors: ";
21:44:24 <oren> printf("%f\n", errors/entries);
21:45:06 <imode> is that in an actual codebase.
21:45:11 <oren> it is yes
21:45:14 <imode> gross.
21:45:34 <oren> note that it isnt even a percent
21:45:49 <imode> LOL.
21:45:59 <shachaf> perone errors
21:47:01 -!- MDude has joined.
21:48:09 -!- AnotherTest has quit (Ping timeout: 268 seconds).
21:48:55 <oren> shachaf: my brain insists that perone is pronounced as if it was an italian loanword
21:49:03 <shachaf> perunit errors
21:51:12 <oren> /pɛroʊneɪ/
21:51:59 <oren> I changed it to ""
21:52:10 <oren> nobody reads this output anyway
21:55:45 <oren> or, at least, they shouldn't. they should be looking at the json
21:56:08 <shachaf> hiren
21:56:23 <shachaf> I heard a rumor structured logs and structured errors might be good.
21:56:27 <shachaf> Do you do something like that?
21:58:03 <oren> shachaf: yes
21:58:31 <oren> but a lot of code still has terminal outputs
21:58:37 <shachaf> What's it like?
21:59:23 <oren> shachaf: annoying because I have to write a bunch of database code and manage an internal tool to display things nicely
21:59:40 <shachaf> whoa, why?
21:59:44 <oren> but, since I'm the only one who understands that system
21:59:58 <shachaf> Seems like it should be no worse than string logs because you can always just print it as a string
22:00:42 <oren> shachaf: well, the json is uploaded to an internal server which has a web tool on it that displays pretty graphs showing how much better we are today than last year
22:01:04 <shachaf> That... Oh.
22:01:21 <shachaf> seems problematic if you can't just run the program hth
22:01:36 <oren> and the only other person who knows how that works just quit
22:01:55 <shachaf> you should ask for more money hth
22:16:58 -!- imode has quit (Quit: WeeChat 2.3).
22:29:12 <zzo38> How I would make timestamps to work in version 12 of X window system protocol, is that you have 64-bit timestamps which must be nonzero and that it is guarantee all timestamps after some request or event are greater than all timestamps before that request or event, so that it is monotonic (but the timestamps do not necessarily correspond to any specific interval of time; this is implementation dependent).
22:34:48 <b_jonas> zzo38: yeah. but, in particular, changing the time the program knows is really hard, because time is reflected in like a shitton of system calls, ones that put timestamps in various data structures, plus some /proc or /sys files may have to be rewritten too
22:35:22 <b_jonas> so that's one of the hardest things to do consistently without at least a full user-mode-linux or similar OS emulation or full system emulation
22:35:51 <b_jonas> it's one of those cases like invisibility in HHGG
22:36:06 <b_jonas> 99 out of 100 times it's easier to actually change the system time and do with it
22:36:32 <b_jonas> shachaf: structured logs and structured errors => I say ask zzo38
22:37:07 <zzo38> Yes, although it can be helpful when you need it. It should be a user library to deal with these things as needed and then programs that need it can use the user library, calling the kernel only to call ptrace() and do the other stuff in the user mode
22:53:48 -!- sleepnap has left.
23:26:26 <b_jonas> wow, oerjan edited https://esolangs.org/w/index.php?title=La_Weá back.
23:27:30 <b_jonas> argh, stupid firefox
23:27:44 <b_jonas> https://esolangs.org/wiki/La_We%C3%A1
23:27:56 <b_jonas> it only copy-pastes the url properly if you select ALL of it
23:28:02 <b_jonas> I hate this
23:28:23 <shachaf> Is there a reasonably low-level language (lets you specify memory layout, no hidden allocations, etc.) that has single-argument functions where you just pass one struct by value for multiple arguments?
23:28:48 <shachaf> And maybe also has flexible struct literals to allow all kinds of things like keyword arguments, default arguments, varargs, etc.
23:29:04 <shachaf> It seems like it should be possible and also nicer than most languages, but I'm not sure about the details.
23:29:07 <b_jonas> shachaf: we talked about this at some point on #esoteric I think
23:29:28 <shachaf> That makes sense. Though I've been wondering about this flexible struct literal thing more generally.
23:29:32 <b_jonas> may be in the logs
23:30:42 <shachaf> A lot of languages have flexible integer literals, for example, right?
23:31:21 <shachaf> Where maybe integer types are 32-bit or 64-bit, but integer literals are unbounded, and you implicitly coerce a literal to a type with a runtime representation.
23:31:45 -!- Essadon has quit (Quit: Qutting).
23:32:21 <b_jonas> I think it's not that many languages that have that. That only works if the compiler can derive types. So rust and haskell does it, and perhaps SML, I'm not sure.
23:32:52 <b_jonas> Some other languages like C and C++ just have some easy conversions of integers to other integer types, plus explicit notations for some types of integer literals.
23:32:52 <shachaf> Haskell doesn't do it.
23:33:05 <b_jonas> "So rust and haskell does it, and perhaps SML"
23:33:13 <b_jonas> haskell and Haskell are the same language
23:33:17 <b_jonas> but yeah
23:33:19 <shachaf> I'm pretty sure I've seen languages that do it though I don't remember which one.
23:33:22 <shachaf> What?
23:33:22 <b_jonas> haskell in fact does even more
23:33:29 <shachaf> I said Haskell doesn't do it.
23:33:38 <b_jonas> what?
23:33:41 <shachaf> What?
23:33:43 <b_jonas> haskell _doesn't_ do it?
23:33:45 <b_jonas> no way
23:34:03 <shachaf> No, the literal "123" is a value with a runtime representation.
23:34:29 <shachaf> In particular it's the value "fromInteger (123 :: Integer)"
23:34:46 <b_jonas> shachaf: sure. that works
23:34:54 <shachaf> I'm talking about literals that can exist only at compile-time.
23:35:21 <b_jonas> I think there was one other language that does that, maybe golang or D, I dunno
23:35:51 <shachaf> Anyway, I'm thinking of extending a thing like that to struct literals.
23:36:02 <b_jonas> even more than rust in fact, in the sense that expressions with certain simple arithmetic operations from integer literals are computed to full precision and are allowed to overflow the largest runtime integer type
23:36:13 <shachaf> So maybe you have "struct T { int x; char y; };"
23:36:32 <shachaf> And you have the literal value "[x=5, y='a']", which doesn't have a runtime representation
23:36:52 <shachaf> But you can write "T t = [x=5, y='a'];"
23:37:07 <b_jonas> shachaf: I'm not sure why the Haskell way is that much different from the Rust way. The main difference is that in Haskell, you can define new integer types, and that there's a library bigint type.
23:37:10 -!- Phantom_Hoover has quit (Read error: Connection reset by peer).
23:37:47 -!- arseniiv has quit (Ping timeout: 246 seconds).
23:38:17 <shachaf> b_jonas: The point is that there's a runtime representation of these bigint values, so the whole "literal that only exists at compile-time" thing doesn't come up.
23:38:22 <b_jonas> shachaf: there is one proposal for rust for something like that, but only for untagged structures, not for tagged ones
23:39:33 <shachaf> If you have struct Args { int x; int y; char c = 'q'; };, and void f(Args args);, you could write something like f[x=5, y=8], or f[5, 8, 'z'], or so on
23:39:55 <b_jonas> in the sense that (x,y) is an untagged tuple-like structure, P(x,y) is a tagged tuple-like struct after a declaration like struct P(T0,T1); Q{a:x,b:y} is a tagged non-tuple-like struct, and they want non-tagged non-tuple-like structs,
23:40:18 <b_jonas> with named members, but no tag. would need some weird rules, but seems possible.
23:40:31 <shachaf> Where these things are just specified with regard to literal->struct conversion rules, not anything specific to function application.
23:40:59 <shachaf> Flexible struct literals seem useful anyway for all sorts of reasons.
23:41:05 <b_jonas> and the proposal recommends that they can be implicitly converted to smaller untagged structs that miss some members, but such _implicit_ conversion (as opposed to an explicit cast) seems fishy to me
23:41:44 <b_jonas> they would be flexible in the sense that you can use dot-dot notation to include members from another non-tagged struct, possibly adding new members or replacing existing members
23:41:49 <b_jonas> in the constructor that is
23:42:14 <b_jonas> you can't use default values of course, because there's no declaration of the tagged type that would define the default values
23:42:15 <shachaf> Why does it seem fishy?
23:42:37 <shachaf> This isn't a cast between types, to be clear. It's only a "cast" from literals to values.
23:43:05 <b_jonas> shachaf: dunno... doesn't seem very rust like. I'm not entirely sure, could work with a smart enough compiler that gives a warning for typical mistakes where you add an extra member that the function you are calling doesn't support.
23:43:07 <shachaf> So if you have struct A { int x; }; and struct B { int x; };, you can't write A a; B b = a;
23:43:18 <shachaf> I don't particularly care about Rust?
23:43:28 <shachaf> I'm wondering about this kind of feature in general.
23:44:05 <b_jonas> like, you could call f({x:3,y:0,z:1}) but f actually takes an {x:i32,y:i32} argument so the z value will get ignored, silently or with a warning
23:44:22 <shachaf> Oh, sure, that should be an error.
23:44:23 <b_jonas> shachaf: you were the one who asked about any low-level language, sorry
23:44:41 <b_jonas> shachaf: yes, that's what I think too. it should be possible to cast explicitly, perhaps with the as operator
23:45:07 <b_jonas> should I dig up the RFC?
23:45:08 <shachaf> Sure, but "this isn't compatible with language X" is a different claim from "this is a bad feature"
23:45:36 <b_jonas> shachaf: no, I think it would be bad in any language, but perl is already like that
23:46:15 <shachaf> OK, what's an example of a place where it would be bad or confusing?
23:46:16 <b_jonas> I'm not saying "compatible", more like it's not in the kind of mindset that rust wants, catching as many errors in compile time as possible, sort of like Haskell
23:46:17 <oren> b_jonas: perl5 has the option to declare arguments tho
23:47:04 <b_jonas> shachaf: um, I just said one. I said only the implicit upcast is what would be a bad feature, because f({x:3,y:0,z:1}) would silently throw away the z:1 member, when the caller might think the function does handle that argument
23:47:17 <shachaf> When you say "cast", what do you mean?
23:47:48 <b_jonas> shachaf: an explicit conversion to a different type. like a C-style cast, but with a slightly more agreeable syntax than a C-style cast.
23:48:25 <shachaf> But it's important that I'm only allowing implicit conversions from literals to values here.
23:48:27 <b_jonas> and for struct values only, not references
23:48:47 <b_jonas> shachaf: yes, I understand, but doesn't {x:3,y:0,z:1} count as a literal?
23:48:47 <shachaf> That means everything can be checked at compile-time, because literals don't exist at runtime.
23:49:13 <shachaf> Sure, but I specified that that's an error.
23:49:18 <b_jonas> right
23:49:37 <b_jonas> and if this change gets accepted to rust (though it likely won't be), then they'll probably change that part
23:49:52 <b_jonas> or at least that's my guess
23:50:12 <oren> wait in what sense do literals only exist at compile time?
23:50:26 <shachaf> You said this would be a bad feature in every language, so I'm not sure why you keep bringing up Rust.
23:50:31 <shachaf> I'm wondering what makes it a bad feature.
23:50:45 <b_jonas> shachaf: it's only that implicit conversion that would be a bad feature
23:50:47 <oren> I always thought of literals as nameless consts
23:51:07 <shachaf> b_jonas: OK, but in the context I'm specifying this the implicit conversion is very important.
23:51:11 <b_jonas> I'm not certain the rest of the proposal, that is, untagged (undeclared) structs with named members, would be a good or bad feature
23:51:14 <shachaf> So where would it be a bad feature?
23:51:39 <b_jonas> shachaf: so what kind of implicit conversion do you want? a conversion to a tagged struct?
23:52:22 <shachaf> A conversion from a struct literal to any struct.
23:52:40 <shachaf> Assuming it passes checks like the one I mentioned.
23:53:03 <b_jonas> there was actually a plan, perhaps already landed in rust now, to make a struct constructor for tagged structs where you don't give the struct name (which is only the constructor name, like in Haskell), and it's only valid if the typechecker can figure out the struct type expected, otherwise it's an error
23:53:23 <b_jonas> I'm not sure what the syntax was, it's a funny looking one but one that makes sense
23:53:28 <b_jonas> let me check
23:55:19 <shachaf> I must be asking my question badly because it seems like you have something in mind for why this would be bad but you keep talking about Rust instead
23:58:47 <b_jonas> shachaf: I know this isn't completely the same, but I might also be misunderstanding you because I'm tired
23:59:47 <shachaf> You said this would be bad in any language and I'm trying to figure out why.
←2018-11-27 2018-11-28 2018-11-29→ ↑2018 ↑all