00:00:00 --- log: started forth/11.04.02 00:04:28 how do i fill an array that i'm creating with create does>? i don't know how to get the addresses of the stuff that i'm currently allocating 00:06:21 --- join: Joseph__ (~Joseph@200-122.adsl.umnet.umich.edu) joined #forth 00:09:27 --- quit: Joseph_ (Ping timeout: 264 seconds) 00:11:38 --- join: Deformative (~Joseph@200-122.adsl.umnet.umich.edu) joined #forth 00:15:24 --- quit: Joseph__ (Ping timeout: 252 seconds) 00:17:44 --- quit: Monevii (Remote host closed the connection) 00:21:21 --- join: Joseph_ (~Joseph@200-122.adsl.umnet.umich.edu) joined #forth 00:22:16 --- join: Joseph__ (~Joseph@200-122.adsl.umnet.umich.edu) joined #forth 00:24:11 --- quit: Deformative (Ping timeout: 252 seconds) 00:24:17 --- join: Deformative (~Joseph@200-122.adsl.umnet.umich.edu) joined #forth 00:26:25 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 00:26:26 --- quit: Joseph_ (Ping timeout: 276 seconds) 00:27:44 --- quit: Joseph__ (Ping timeout: 276 seconds) 00:29:41 --- quit: Deformative (Ping timeout: 252 seconds) 00:33:57 haole: you don't. 00:34:16 haole: don't use "does>", it makes everything much simpler. 00:34:46 ASau`: i've done it using , but i don't know if it is guaranteed that my indexes will be allocated in consecutive memory addresses 00:35:22 ASau`: but what should i use to define data structures and such? 00:35:35 ASau`: is create does> bad practice? i'm a beginner in forth 00:38:07 Use "struct% ... end-struct%" 00:38:24 There's a controversy around "does>". 00:38:50 Sometimes it may be good, but it has its drawbacks. 00:39:04 Some consider "does>" a bad practice. 00:40:59 haole: do you know what "closure" is? 00:42:31 ASau`: it has something to do with functional programming, right? i don't know how to define it 00:43:23 You have closures in imperative programming since at least 1960. 00:43:25 Algol. 00:43:27 ASau`: like when you have functions that don't have side effects... something like that 00:43:45 Closures have side effects, that's why they exist at all. 00:43:59 could you define them for me, then? :D 00:44:31 Which programming languages do you know besides Forth? 00:45:02 And besides archaisms like "C". 00:45:56 Though I can explain it in "C" too... 00:46:12 ASau`: scheme... but I don't have a background in lambda calculus yet 00:46:42 Nice. 00:47:24 (let ((n 0)) (lambda () (set! n (+ n 1)) n)) 00:47:42 This is it. 00:48:02 inner function accessing outer function data? 00:48:13 It isn't "outer" data. 00:48:14 by data i mean free variables 00:48:22 It isn't free variable. 00:48:28 It is bound by "let". 00:48:31 like pascal with embedded procedures 00:49:03 sorry, i don't get it... feeling stupid! :D 00:49:20 ya, he's not splaining well 00:49:52 think on recusive functions where you can access caller's data 00:50:12 ok... i can imagine that :) 00:50:14 recursive 00:50:23 x86 enter..leave opcodes 00:50:37 it's global and local data 00:51:07 "lexical" means only parent caller can be peeked; unrelated fun's data cant be read 00:51:08 You have a function that accesses its own private environment, which is persistent across invocations. 00:51:19 which is "static" in C 00:52:15 or private 00:52:30 i think i'm starting to get it... i'm reading wikipedia while you explain 00:52:34 k 00:52:51 It is possible to explain it via static, only it erodes the way how it is done. 00:53:03 well, that doesnt matter to him yet 00:53:20 The word you define with "create ... does> ..." is creating such closures. 00:53:30 Only statically. 00:53:57 When you call these closures, their environment is "automagically" passed to them on TOS. 00:54:56 If you understand how you program with closures, you'll understand drawbacks in "does>". 00:55:00 but if i create a word with create does> and then call it, won't i be just accessing its execution token? 00:55:20 No. 00:55:43 hum... i think my first misconception is this one 00:56:00 that's probably why i'm failing to do what i want 00:56:23 reda leo brodie's books; google 00:56:27 read 00:56:31 No, don't read them. 00:56:38 They're basically useless. 00:56:41 oh definately read them now 00:56:50 one scoffer 00:56:55 :) 00:57:01 haole: what are you trying to accomplish? 00:57:02 i've read thinking forth 00:57:06 good 00:57:25 making a vector of floats (yeah, they need to be floats... its a requirement) initiated with random numbers 00:57:41 i had some free time so i'm using this opportunity to sharpen my forth 00:57:57 create v 10 floats allot ( here's your vector ) 00:57:58 vector = array 00:58:22 damn... lol 00:59:10 gforth initialized it with 0.0 00:59:15 marker done : init 10 0 do frandom v i floats + ! loop ; init done 00:59:45 Or convert it to pointer style, if you like it so. 01:00:27 You have to implement "frandom" yourself. :) 01:01:08 i did... i got a stack underflow in the second init 01:01:22 "f!" of course. 01:01:30 oh... right 01:01:39 Because Forth is stupid. 01:02:05 Any modern language helps you with such problems. 01:02:29 worked like a charm 01:02:52 although i didn't understand the implementation... don't know 'marker', 'done' and 'init' 01:02:54 gonna study about them 01:03:18 You define "done" and "init" yourself, see above. 01:03:26 forth seems very nice... its just that you have to implement some very basic stuff before abstracting your problem 01:03:42 oh, you are right 01:04:36 "Abstracting" 01:04:37 Ha! 01:04:51 Good luck with abstracting your problems in Forth :) 01:05:00 Barmin patch is better solution. 01:06:19 there is even an oo extension! :D 01:06:29 i think i'm pissing you off lol 01:06:41 Several incompatible toys. 01:06:50 Right. 01:07:08 Have you used Scheme in production? 01:08:17 only in academic context, but the work was published 01:08:32 in work i use - guess what - c, c++ and... delphi 01:08:38 i know... i'm ashamed, but orders are orders 01:08:57 * ASau` has bad words about all three. 01:09:10 from those 3, c gives me less headaches 01:09:26 I can't say it gives less headaches. 01:09:38 c++ makes it easy for me to hurt myself 01:09:42 and delphi is just gross 01:09:46 You're always fighting with lack of modularity and with powerless abstractions. 01:10:30 why lack of modularity? 01:10:52 What "why"? 01:11:29 You have one single global namespace for all your functions. 01:13:18 that doesn't affect modularity... it will just add cumbersome prefixes to your functions... lack of modularity would be, in my vision, if you couldn't create functions or something bizarre like that 01:14:06 any programming language that i know allows you to me as modular as you want... not is not always good, though, as in some cases modular code makes a program slow, with a lot of calls and such (implementation dependent, of course) 01:14:12 It's rather funky approach to modularity. 01:14:35 Why, you think, do you have to add those prefixes to names? 01:15:02 to avoid function name collisions, no? 01:15:26 Yeah, but why do you have function name collisions? 01:16:03 It isn't hard to create local functions. Many languages support it just fine. 01:16:59 C won't allow local functions... or am i wrong? 01:17:28 Yes, exactly. C doesn't support modularity. 01:18:09 i think i'm getting where you were headed with the closure talk 01:18:10 You have only two name spaces for your functions: file local and all-global. 01:18:32 oh, just one more question... the forth code you provided has a problem 01:18:40 This is far from being sufficient for practical work. 01:18:55 the call to frandom will populated all positions of the array with the same random number, like 0.897 0.897 0.897... 01:19:12 populate* 01:19:28 If you implement "frandom" as a constant, sure. 01:21:01 gforth doesn't seem to provide RNG. 01:21:19 i did it like this: http://pastebin.com/jdaakv5T 01:22:13 and gforth provides it through random.fs: http://www.complang.tuwien.ac.at/cvsweb/cgi-bin/cvsweb/gforth/random.fs?rev=1.2;content-type=text%2Fx-cvsweb-markup;sortby=date;f=H 01:23:16 Does your "wrandom" generate random sequence? 01:24:02 * ASau` shrugs at LCG. 01:24:05 don't know what you mean... if i call it over and over, the numbers will be random and different from each other 01:26:06 they get placed at my float stack 01:26:20 How do you inspect the array after you filled it? 01:26:41 oh, you are right... i was using the old does> syntax 01:27:03 0 v, 1 v... need to do v 1 floats +, v 2 floats + 01:27:31 Rigth. 01:29:19 thanks! let me ask one last question: what do you think that limits forth from being the best tool to develop a practical work? when you talked about C, the namespaces issue was unbearable to you... what about forth? what would be it? 01:30:14 Forth has another large set of drawbacks. 01:30:26 First, it doesn't have good practical compilers. 01:30:35 Second, it doesn't have good practical libraries. 01:31:03 Third, almost all the code is written in horrible style. 01:31:25 It is buggy and non-reentrant. 01:31:47 Then there's no common approach to modularity. 01:33:02 Then there's a lack of programming tools. 01:33:35 Though Emacs support is fine, it isn't enough. 01:33:38 i see... 01:34:03 Forth would benefit a lot from a static analysis tools. 01:34:14 Even applied to a restricted language. 01:35:43 Note that GCC is just fine for C. 01:36:08 C has libc which is rich enough to be almost practical. 01:36:32 GCC ships with profiling and coverage tools. 01:36:55 You have lint and other analyzers. 01:37:17 your answer is similar to what i think about forth... although it is very nice to program embedded with it 01:37:27 i wonder what would chuck moore say about those arguments lol 01:38:04 He's weirdie. 01:39:01 He happened to discover a coding technique that has its momentum when technology was rather new. 01:39:13 s/has/had/ 01:39:38 but forth probably is the best language to implement new concepts in computation, because it is extensible like no other 01:40:20 he had a point there... the problem, in my opinion, is that forth can be used in some many different styles that the vast majority of code written is it is of very bad quality 01:40:28 Nowadays if you follow this, you're confined to toys like 01:40:28 the world was back in time when the IT was new. 01:41:04 haole: http://google.com/search?q=lisp+evolution+hopl2+uncut 01:41:47 Read the paper, you'll learn many new things. 01:42:21 ok... thanks for the talk 01:42:27 gotta sleep :) bye 01:44:36 --- quit: haole (Quit: Ex-Chat) 01:46:29 --- nick: schme -> schmrkc 02:11:40 lisp is actually better for implementing new ideas than forth 02:13:22 10:24 C won't allow local functions... or am i wrong? 02:13:23 10:24 Yes, exactly. C doesn't support modularity. 02:13:31 wrong, nested functions are legal in C99. 03:14:13 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 03:24:52 --- join: dvdk (~dvdkhlng@g225046007.adsl.alicedsl.de) joined #forth 03:44:18 --- quit: MayDaniel () 04:56:38 --- quit: gogonkt (Ping timeout: 260 seconds) 04:57:17 --- join: gogonkt (~gogonkt@2001:c08:3700:ffff::6:b9cd) joined #forth 06:19:10 --- quit: ygrek (Ping timeout: 246 seconds) 06:33:00 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 07:08:23 --- join: I440r (~mark4@108-64-168-250.lightspeed.wepbfl.sbcglobal.net) joined #forth 07:56:49 --- quit: dvdk (Read error: Connection reset by peer) 08:17:12 --- join: Monevii (~Monevii@67.224.130.75) joined #forth 09:10:31 --- quit: Fox78 (Ping timeout: 252 seconds) 09:23:02 --- join: Fox78 (~fox@123.115.211.170) joined #forth 10:38:24 --- quit: ygrek (Remote host closed the connection) 11:00:49 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 12:44:47 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 13:31:08 --- part: harlan left #forth 13:42:42 --- quit: ASau` (Remote host closed the connection) 13:43:50 --- join: ASau` (~user@93-80-218-22.broadband.corbina.ru) joined #forth 14:00:44 --- quit: MayDaniel (Read error: Connection reset by peer) 15:25:19 --- quit: ygrek (Ping timeout: 246 seconds) 16:06:24 --- quit: DocPlatypus (Quit: Leaving) 16:52:00 --- quit: gogonkt (Read error: Operation timed out) 17:00:05 --- join: gogonkt (~gogonkt@2001:c08:3700:ffff::8:2baa) joined #forth 17:03:08 --- join: DocPlatypus (~skquinn@dsl253-084-031.hou1.dsl.speakeasy.net) joined #forth 17:39:11 --- join: kernalogs (~jacko@nat76.mia.three.co.uk) joined #forth 17:51:31 --- quit: I440r (Ping timeout: 250 seconds) 19:04:40 --- quit: kernalogs (Quit: Leaving) 21:00:58 --- quit: DocPlatypus (Ping timeout: 240 seconds) 21:03:21 --- join: DocPlatypus (~skquinn@dsl253-084-031.hou1.dsl.speakeasy.net) joined #forth 21:32:03 --- quit: malyn (Remote host closed the connection) 21:32:44 --- join: malyn_ (~malyn@server.strangegizmo.com) joined #forth 21:32:44 --- quit: malyn_ (Changing host) 21:32:44 --- join: malyn_ (~malyn@unaffiliated/malyn) joined #forth 21:33:07 --- nick: malyn_ -> malyn 22:51:45 --- quit: Monevii (Remote host closed the connection) 23:39:13 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 23:59:59 --- log: ended forth/11.04.02