00:00:00 --- log: started forth/21.07.17
01:06:18 --- join: Glider_IRC__ joined #forth
01:09:10 --- quit: Glider_IRC_ (Ping timeout: 120 seconds)
11:02:43 --- quit: cbridge_ (Connection closed)
11:03:00 --- join: cbridge_ joined #forth
11:35:47 --- quit: blackbeard420 (Quit: ZNC 1.8.2 - https://znc.in)
12:30:42 --- mode: ChanServ set +o :mark4
12:30:42 --- quit: mark4 (Changing host)
12:30:42 --- join: mark4 joined #forth
12:30:42 --- mode: mark4 set +o :mark4
13:06:16 --- join: Glider_IRC_ joined #forth
13:09:10 --- quit: Glider_IRC__ (Ping timeout: 120 seconds)
13:26:08 <cbridge_> <veltas> siraben: Yeah small world (okay the community of people that comment on HN and care about axiom of choice is probably not that large, to be fair)
13:26:20 <cbridge_> <veltas> I'm reading the B manual
13:27:14 <cbridge_> <veltas> You can define a simple external variable by naming it, and then provide a value to initialise it, like:   name 0;
13:27:41 <cbridge_> <veltas> But if you add more values after it, they just get put directly after previous values in memory
13:27:55 <cbridge_> <veltas> So you can create a vector by just doing:   vals 0 1 2 3 4;
13:28:05 <cbridge_> <veltas> And then access the vector through &vals
13:28:20 <cbridge_> <veltas> Oh sorry with commas between the values
13:28:43 <cbridge_> <veltas> Anyway it just struck me this syntax and functionality is extremely similar to Forth
13:29:31 <cbridge_> <eris[m]1> yup
13:35:05 <cbridge_> <veltas> I'm trying to think about how to make a nice B successor without types (i.e. not C)
13:36:27 <cbridge_> <veltas> I think the way to go might be to have a[b] <=> *(a + CELL*b)
13:37:34 <cbridge_> <veltas> The reason I'm thinking about this is because B did not have pointers, it just had addresses, and it was designed for a word-addressed system
13:38:16 <cbridge_> <veltas> So all the code broke on byte-addressed systems, and C was part of the effort to make B intelligent enough to still look mostly the same but generate good code
13:38:56 <cbridge_> <veltas> And interestingly to me the interim B compiler they wrote for the byte-addressed PDP-11 was pretty much like a threaded forth implementation inside
13:51:33 <cbridge_> <veltas> eris[m]1: What does the [m] mean? I've seen this on other nicks too
13:51:48 <cbridge_> <eris[m]1> matrix!
13:51:56 <cbridge_> <veltas> Oh right
14:00:16 <cbridge_> <eris[m]1> id love to see a modern B
14:00:39 <cbridge_> <eris[m]1> would compile p well to C, maybe
14:06:25 <cbridge_> <veltas> Some kind of regex might be able to convert it
14:07:01 <cbridge_> <veltas> extrn to extern, put braces around initializer lists (and square brackets around automatic vector sizes)
14:07:35 <cbridge_> <veltas> But I think the advantage of a modern B is it would be very easy to write an *actual* compiler for it
14:10:44 <cbridge_> <veltas> I used to think that C++ was just C with more stuff and really bad taste for syntax
14:10:59 <cbridge_> <veltas> Now I realise C is just B with more stuff and really bad taste for syntax
14:22:10 <cbridge_> <eris[m]1> does B tail call optimise?
14:22:53 <cbridge_> <eris[m]1> also, B's syntax is p nice
14:23:17 <cbridge_> <eris[m]1> considering any extensions for B?
14:42:33 <cbridge_> <veltas> eris[m]1: I want to change some semantics to make addresses work 'nicely'
14:42:48 <cbridge_> <veltas> And also the point of octal was that it was natural on the original machine
14:43:08 <cbridge_> <veltas> So hex is more natural on current architectures, so I will just have 0 prefix be hex, rather than 0x
14:43:30 <cbridge_> <veltas> So getting rid of octal completely
14:43:59 <cbridge_> <veltas> I am considering making ++ add CELL rather than 1
14:44:23 <cbridge_> <veltas> So you can use a++ to go to next address, but NOT use it to add 1
14:45:05 <cbridge_> <veltas> And I am planning on using it with the C preprocessor
14:45:47 <cbridge_> <veltas> "does B tail call optimise" I don't know, I'm sure some implementation might have. There were a number of implementations.
14:46:43 <cbridge_> <eris[m]1> i think a 0 prefix and another prefix would be nice yea
14:46:54 <cbridge_> <eris[m]1> i like ++ and -- as CELL+ and CELL-
14:50:17 <cbridge_> <eris[m]1> keep me updated on this
14:50:37 <cbridge_> <veltas> Okay lol
14:51:17 <cbridge_> <veltas> The updates will run out soon when I lose motivation
14:59:08 <cbridge_> <eris[m]1> and i'll try and take over!
15:00:11 <cbridge_> <MrMobius> wasnt B interpretted?
15:02:01 <cbridge_> <eris[m]1> that wouldnt makw sense
15:21:01 <cbridge_> <veltas> MrMobius: No, the PDP-11 version compiled to threaded code like Forth (so sort of interpreted)
15:21:08 <cbridge_> <veltas> The original was compiled to machine code I belive
15:21:55 <cbridge_> <veltas> The PDP-11 version did this because the language stopped making sense natively on that architecture
15:24:59 <cbridge_> <veltas> I think another extension would be permitting constant expressions rather than just constants (B/C terminology for 'literal') in initializers
15:25:27 <cbridge_> <veltas> Because I'm planning on doing basic constant folding in expressions already at least
16:25:46 <cbridge_> <dave0> maw
16:46:24 --- quit: mark4 (Ping timeout: 120 seconds)
17:50:13 <cbridge_> <eris[m]1> b's function array stuff is wau better than c's
18:10:50 <cbridge_> <eris[m]1> like god
18:10:54 <cbridge_> <eris[m]1> function pointers in c
19:32:25 <cbridge_> <dave0> re maw
20:40:11 <cbridge_> <MrMobius> whats wrong with function pointers?
21:37:01 <cbridge_> <siraben> function pointers are neat
21:57:49 --- quit: Glider_IRC_ (Connection closed)
21:59:05 --- join: Glider_IRC_ joined #forth
22:01:29 --- quit: Glider_IRC_ (Connection closed)
22:02:37 --- join: Glider_IRC joined #forth
23:59:59 --- log: ended forth/21.07.17