00:00:00 --- log: started forth/17.05.15
00:15:06 --- quit: taij33n (Remote host closed the connection)
01:38:02 --- quit: dual (Ping timeout: 240 seconds)
01:39:39 --- join: true-grue (~true-grue@176.14.219.178) joined #forth
01:40:39 --- join: dual (~bonafide@104.254.68.254) joined #forth
01:53:57 --- join: Mat4 (~claude@ip5b411568.dynamic.kabel-deutschland.de) joined #forth
01:59:02 --- quit: Mat4 (Quit: Mat4)
02:28:51 --- quit: meta4 (Read error: Connection reset by peer)
02:29:41 --- join: meta4 (~jgw@c-24-8-47-119.hsd1.co.comcast.net) joined #forth
03:16:36 --- quit: nighty-- (Quit: Disappears in a puff of smoke)
03:48:23 --- join: coelebs (viileppi@gateway/shell/blinkenshell.org/x-aslfrnxqsnuawuxo) joined #forth
04:01:30 --- join: nighty-- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth
04:15:02 --- join: GeDaMo (~GeDaMo@212.225.127.213) joined #forth
04:25:02 --- quit: dual (Ping timeout: 240 seconds)
04:26:39 --- join: dual (~bonafide@subzeroup.core.rzwireless.net) joined #forth
05:04:45 --- quit: wa5qjh (Remote host closed the connection)
06:24:47 --- quit: dual (Ping timeout: 268 seconds)
07:43:02 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth
07:45:03 --- join: dual (~bonafide@cpe-74-75-153-119.maine.res.rr.com) joined #forth
07:47:06 --- quit: roundsf (Ping timeout: 272 seconds)
07:49:06 --- join: roundsf (~user@2a00:2381:1a72:10:41ac:34cd:e565:8390) joined #forth
08:19:17 <zy]x[yz> so I've just started playing around with removing my headers by one level of indirection; instead of <header><code-field><params...>, I have <header><address of code-field><code-field><params...>.  I did this so that I could have multiple headers point to the same body (primarily because I wanted a word to be able to exist in multiple vocabularies, but also aliases can take advantage of this)
08:20:24 <zy]x[yz> since I'm going down this road, I wonder if I should start researching this idea I've seen mentioned about having an interpet-semantic field and a compilation-semantic field in lieu of an immediate flag
08:20:43 <GeDaMo> If you separate headers from code you may also improve cache efficiency since headers are only used during compilation
08:25:28 <zy]x[yz> well, for now I'm just trying to get something working that I'm happy with.  ultimately my long-term goal is to compile to headerless binaries, and then eventually to include symbol tables (or some kind of headers section) for dynamic linking
08:25:59 <zy]x[yz> that's like... very future fantasy stuff right now, though
08:27:20 <zy]x[yz> so for now, headers still land in the same linear dictionary space with everything else, but I'm sort of toying around with the idea of not even writing the header until after the body is finalized
08:28:29 <zy]x[yz> that means that last wouldn't be populated until after ;, though... but I think that only breaks recurse, and that could be dealt with
08:29:58 <zy]x[yz> but anyway, the rationale would be so that the headers are extensible
08:30:19 <zy]x[yz> which may be entirely not a useful feature at all.  I'm not sure yet..
09:10:42 --- quit: dys (Read error: Connection reset by peer)
09:23:10 <larsb> Sounds good.  Go wild!
09:23:15 <larsb> Your SYNONYM should be nice.
09:32:30 --- join: zincing (~zincing@2a03:1b20:4:f011::22de) joined #forth
09:33:30 --- quit: LeCamarade (Ping timeout: 272 seconds)
09:42:02 --- quit: Keshl (Read error: Connection reset by peer)
09:42:19 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth
09:46:17 --- join: dys (~dys@ip-109-40-0-255.web.vodafone.de) joined #forth
10:23:47 --- quit: neceve (Quit: Konversation terminated!)
10:37:29 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth
10:37:47 --- quit: Zarutian (Read error: Connection reset by peer)
10:38:30 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth
10:56:27 --- join: ACE_Recliner (~ACE_Recli@c-50-165-178-74.hsd1.in.comcast.net) joined #forth
11:32:18 <izabera> Write a piece of Forth code that expects two numbers on the stack (A and B, with B on top) and computes `(a-b)(a+1)'.
11:32:32 <izabera> : foo over 1+ rot rot - * ;            i wrote this
11:32:42 <izabera> what would a better forth programmer write?
11:33:47 <zy]x[yz> : izabera tuck 1+ -rot - * ;
11:34:04 <izabera> oh, -rot exists
11:34:07 <izabera> thanks
11:34:49 <izabera> at least i wasn't that far off
11:34:54 <zy]x[yz> oh, b was on top.  mine is wrong, sorry
11:35:09 <zy]x[yz> yours is fine, just replace rot rot with -rot
11:35:22 <GeDaMo> What about  over swap - swap 1+ *
11:35:55 <zy]x[yz> I always hate seeing over swap together, althought admittedly it probably is still faster than a rot or -rot
11:36:10 <izabera> i tried to write     : foo ( a b -- (a-b)(a+1) ) over 1+ rot rot - * ;
11:36:17 <izabera> but gforth didn't quite like it
11:36:29 <zy]x[yz> what did it not like about it?
11:36:44 <izabera> : Undefined word
11:36:46 <izabera> : foo ( a b -- (a-b)>>>(a+1)<<< ) over 1+ rot rot - * ;
11:36:51 <true-grue> omg
11:37:06 <izabera> i thought i could just write anything inside ( ) ?
11:37:22 <zy]x[yz> does gforth support nested ()s?
11:37:25 <GeDaMo> A comment is ( until the first )
11:37:48 <izabera> i thought the first ) had to be a separate word
11:38:47 <izabera> ok well, good to know, thanks
11:39:18 <zy]x[yz> seems like some implementations just read characters until the first ), and others (my preferred method) parse words until they find a balanced space-dilimited )
11:39:55 <true-grue> rstack is your friend
11:39:58 <GeDaMo> true-grue: what are you "omg"ing at? :P
11:40:08 <true-grue> over 1 + >r - r> *
11:40:34 <zy]x[yz> how is that better than two swaps?
11:41:31 <true-grue> Two swaps is even worse than single swap.
11:41:56 <zy]x[yz> and yet it's got to be better than moving between two stacks
11:42:56 <true-grue> True forther doesn't like swap, believe me. See Chuck's code. He's using push/pop in these situations.
11:43:31 <zy]x[yz> haha what
11:43:55 <zy]x[yz> are you also the guy who said that chuck says not to use ?dup ?
11:44:06 <zy]x[yz> but then provided absolutely no reason as to why
11:44:29 <zy]x[yz> I'm not interested in adopting forth as a religion
11:44:34 <koisoke> chuck uses hardware that does those operations in one cycle
11:45:51 --- quit: dys (Read error: Connection reset by peer)
11:46:13 <GeDaMo> Chuck's chips also have registers
11:48:07 <koisoke> on x86, (unoptimized) r> is something like: push eax;mov eax,[esi];lea esi,[esi+4]   and swap is something like xchng eax,[esi]
11:49:27 <koisoke> and rot is just painful
11:50:51 <koisoke> not sure of the performance of xchg reg,mem on current machines
11:51:18 <koisoke> looks like vfx does it with 3 movs
11:51:45 <GeDaMo> Yeah, I think I would avoid the xchg
11:53:19 <koisoke> *xchg
11:54:17 <izabera> do you get any exception support from fast compilers?
11:54:24 <izabera> like stack underflow/overflow
11:54:30 <izabera> division by 0
11:54:32 <izabera> idk
11:55:04 <koisoke> izabera: it varies
11:55:48 <true-grue> In fact, the performance is not the main reason here. With a spare stack it's much easier to code things like these. Why should one remember stack pictures for tuck, -not etc? It's ridiculous!
11:55:51 --- quit: DocPlatypus (Ping timeout: 255 seconds)
11:56:35 <GeDaMo> I remember a stack based language called AMPLE
11:56:45 <GeDaMo> It didn't have words for dup drop dwap etc
11:56:53 <zy]x[yz> because they have reasonably intuitive names and it's literally effortless to remember
11:57:05 <GeDaMo> It had #11 for dup, #212 for over, #22 for drop
11:57:35 <koisoke> were those hardcoded or could they be freely composed
11:57:37 <GeDaMo> The stack items were numbered from 1 down then the name was the stack picture you wanted
11:57:43 <GeDaMo> koisoke: I don't remember
11:57:51 <koisoke> sounds nice
11:57:57 <zy]x[yz> sounds terrible
11:58:01 <GeDaMo> :D
11:58:21 <true-grue> T. Hoare once said: "Debugging is harder than programming, so don't use all your cleverness to write the program". And I'll add: so don't waste your mind with things like tuck or rot, concentrate on your problem solving.
11:58:41 <koisoke> a optimizing compiler will need to generate that representation anyway, so one might as well have access to it
11:59:14 <GeDaMo> #221 would duplicate the second item in place
11:59:19 <zy]x[yz> this is extremism.  surely "tuck" is not "all your cleverness"
11:59:24 <izabera> GeDaMo: #22 seems wrong for drop
11:59:31 <zy]x[yz> and yeah that should be #2
11:59:35 <GeDaMo> izabera: you're right
11:59:50 <GeDaMo> #22 would be drop dup
12:01:49 <izabera> koisoke: can you elaborate a bit more on exception support?
12:02:22 <koisoke> e.g. vfx traps stack underflow when interpreting drop but not for compiled words
12:03:05 <izabera> sounds a bit unsafe?
12:03:43 <koisoke> it is
12:05:26 <GeDaMo> It appears AMPLE's stack operators were a fixed set
12:05:30 <pointfree> zy]x[yz: I was the guy that said Chuck says don't use ?DUP ...and I remember I did say why: ?DUP makes the stack unpredictable, which is a lot like adding hooks for functionality that doesn't exist yet or may never exist.
12:05:32 <pointfree> I'd rather view the forth code itself as a straightforward UI than as something that provides a separate layer of "user friendliness"
12:06:35 <pointfree> source: https://www.youtube.com/watch?v=NK0NwqF8F0k http://www.ultratechnology.com/1xforth.htm
12:07:50 <true-grue> The second step (after something like AMPLE) is to make "live" stack pictures. Like : dup { one -> one one } ; They can be used as a executable specifications too. But the you'll realize that it would be also nice to insert operations in these pictures. : foo { a b -> a b -  a } 1 + * ; You can see this as a reinvention of local variables, of course. Another variant, to think about it as of lambdas with single assignment values. In the latter case 
12:07:50 <true-grue> the compiler may do some interesting optimisations with them.
12:08:45 <GeDaMo> I have vague memories of a system which did something like the "live" stack images
12:10:11 <pointfree> GeDaMo: I posted something here from Forth Dimensions about that a long time ago.
12:10:54 <koisoke> true-grue: locals will give you all of that except easily automated stack diagram checking for a lot less complexity
12:11:21 <koisoke> (though one might want automated stack diagram checking)
12:12:29 <pointfree> true-grue suggested executable stack diagrams for my forth-as-hdl on the PSoC 5LP CPLD.
12:13:17 <true-grue> Here I proposed the combination of 3 different constucts in one: stack pictures + locals + lambdas.
12:13:54 --- join: DocPlatypus (~skquinn@2601:2c2:c300:ff70:2d4e:1d47:a285:1842) joined #forth
12:14:12 <pointfree> true-grue: lambdas for implicit parameters? 
12:14:50 <true-grue> pointfree, You name them on the left side. { a b -> a b - a }
12:15:52 <koisoke> oh, you were suggesting the { } be quotations one can pass around? :)
12:16:25 <true-grue> Sure. 
12:19:15 --- join: gravicappa (~gravicapp@ppp83-237-169-159.pppoe.mtu-net.ru) joined #forth
12:23:26 * crc can do things like:  :dup 'a 'aa reorder ;
12:45:30 --- join: dys (~dys@109.40.0.255) joined #forth
13:10:07 * zy]x[yz can do things like touch his toes (bending his knees only a little bit)
13:17:41 <crc> :)
13:35:17 --- quit: GeDaMo (Remote host closed the connection)
14:13:49 --- quit: gravicappa (Ping timeout: 240 seconds)
14:21:35 --- join: MrBismuth (~ArcMrBism@2602:306:8325:a300:c801:d7f:77e1:92be) joined #forth
14:25:28 --- quit: MrBusiness (Ping timeout: 272 seconds)
14:56:53 --- quit: zincing (Quit: Leaving)
15:14:56 --- join: wa5qjh (~Thunderbi@121.54.90.153) joined #forth
15:44:10 <izabera> why are floats not stored on the same stack?
15:45:28 <Zarutian> izabera: blame the 80 bit mantissa internal to most FloatingPointUnits, or some such.
15:45:52 <izabera> why not make everything a float?
15:46:14 <Zarutian> dec64 seems to be saner alternative to IEEE 754
15:47:08 <Zarutian> because floating point operations are so much slower than just integer operations?
15:47:40 <izabera> plenty of languages have floats only
15:48:04 <izabera> for instance js uses doubles everywhere
15:48:27 <izabera> forth is more complex than js, how does this make you feel
15:49:15 <Zarutian> yeah, and v8 uses hints like & 0xFF..FF to detect if it could do integer operations instead of floating point ones.
15:49:24 <izabera> v8 is cool
15:50:33 <Zarutian> iirc double precision IEEE 754 floating points take up 64 bits. Why not use dec64 instead? It is much saner floating point.
15:51:47 <Zarutian> izabera: you do know that forth originated on computers that did not have any floating point units. And is usually used on MCUs or similiar that often do not even have multiplication operation in its ALU.
15:58:29 <true-grue> Not a big deal. One could easy write Forth-like language with generic stack where you can place ints, floats, arrays, code etc. It's faster to implement it than to discuss about why Forth has not such feature.
16:10:06 <pointfree> izabera: I knew a guy who wrote a bignum-float only forth and performance was great. The separate floating point stack is primarily historical baggage. There is no reason to have a separate floating point stack these days, especially if you have hardware floats.
16:44:26 --- quit: wa5qjh (Remote host closed the connection)
16:47:59 --- join: wa5qjh (~Thunderbi@121.54.90.153) joined #forth
16:52:20 --- quit: wa5qjh (Ping timeout: 246 seconds)
17:05:26 --- join: vsg1990 (~vsg1990@static-72-88-80-103.bflony.fios.verizon.net) joined #forth
17:13:49 --- quit: Zarutian (Quit: Zarutian)
17:35:42 --- join: neceve (~ncv@79.113.69.183) joined #forth
17:35:42 --- quit: neceve (Changing host)
17:35:42 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth
17:37:22 --- join: cp__ (~nighty@d246113.ppp.asahi-net.or.jp) joined #forth
18:08:53 --- join: varuaa (~kvirc@pool-100-2-162-136.nycmny.fios.verizon.net) joined #forth
18:38:00 --- quit: varuaa (Ping timeout: 268 seconds)
18:45:26 --- quit: true-grue (Read error: Connection reset by peer)
19:26:13 --- join: varuaa (~kvirc@pool-100-2-162-136.nycmny.fios.verizon.net) joined #forth
20:28:11 --- quit: neceve (Quit: Konversation terminated!)
21:14:22 --- quit: proteusguy (Ping timeout: 246 seconds)
21:16:29 --- join: proteusguy (~proteus-g@2405:9800:b408:bc31:4a51:b7ff:fe38:d966) joined #forth
21:16:29 --- mode: ChanServ set +v proteusguy
21:24:13 --- quit: vsg1990 (Quit: Leaving)
21:24:58 --- join: LeCamarade (~revence@139.59.111.106) joined #forth
21:38:19 --- quit: josh5tone (Ping timeout: 260 seconds)
21:43:53 --- quit: varuaa (Ping timeout: 246 seconds)
22:14:46 --- join: josh5tone (~josh@99-51-169-74.lightspeed.nworla.sbcglobal.net) joined #forth
23:07:20 --- quit: ACE_Recliner (Ping timeout: 255 seconds)
23:20:58 <izabera> why is there +! but not *!
23:50:00 <larsb> Maybe adding things to memory is more common than multiplying.
23:59:59 --- log: ended forth/17.05.15