00:00:00 --- log: started retro/07.07.04
00:18:40 --- join: nanstm (n=Ray_stma@adsl-68-95-161-155.dsl.rcsntx.swbell.net) joined #retro
00:44:58 --- part: nanstm left #retro
01:06:02 --- join: nanstm (n=Ray_stma@adsl-68-95-161-155.dsl.rcsntx.swbell.net) joined #retro
01:15:48 --- part: nanstm left #retro
01:18:33 --- join: nanstm (n=Ray_stma@adsl-68-95-161-155.dsl.rcsntx.swbell.net) joined #retro
01:18:57 --- quit: nanstm (Client Quit)
02:37:43 --- join: Cheery (n=cheery@a81-197-54-146.elisa-laajakaista.fi) joined #retro
04:13:35 --- quit: Shain (Remote closed the connection)
05:03:26 --- join: Cheery_ (n=cheery@a81-197-54-146.elisa-laajakaista.fi) joined #retro
05:15:05 --- quit: Cheery (Read error: 110 (Connection timed out))
06:19:46 --- quit: Cheery_ (Remote closed the connection)
08:35:09 --- quit: virl ("Verlassend")
09:41:33 <foucist> crc: its tomorrow, have you read it yet!
09:41:34 <foucist> :P
10:12:49 <crc> it does look like an interesting way to approach OOP
10:27:23 * crc still has no motivation to work on any "real" oop in forth
10:41:20 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-131-016.pools.arcor-ip.net) joined #retro
10:49:35 --- quit: Snoopy42 (Read error: 145 (Connection timed out))
10:49:51 --- nick: snoopy_1711 -> Snoopy42
12:24:11 --- join: Cheery (n=cheery@a81-197-54-146.elisa-laajakaista.fi) joined #retro
13:54:25 --- quit: Cheery (Remote closed the connection)
16:54:41 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #retro
17:26:09 --- join: Shain (i=steve@adsl-75-30-112-206.dsl.pltn13.sbcglobal.net) joined #retro
19:05:24 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #retro
20:25:21 <foucist> crc: hmm, if you used Ruby, you'd see how nice oop can be..  i.e. not ugly and crappy like it is in C/C++/Java 
20:26:09 <crc> oop is pretty nice in smalltalk
20:29:28 <foucist> in ruby its so nice, there's no types, but everything is an object, so   "123".to_i would convert that to a number
20:29:33 <foucist> provided it has that method
20:29:46 <foucist> "123" being an object of the string class
20:30:20 <foucist> and ruby is so compact
20:30:26 <foucist> and readable
20:30:29 <foucist> heh
20:30:43 <foucist> anyways, i thought that a delegation-based oop would fit forth really well
20:30:58 <foucist> and perhaps really inspire more forth development
20:31:33 <foucist> perhaps the best way to do delegation-based oop would be to have every object be a micro-forth implementation 
20:31:39 <foucist> within the overall forth
20:31:42 <foucist> if you get what i mean..
20:31:46 <foucist> dunno if thats the best approach
20:32:03 <foucist> but the whole message passing
20:32:44 <foucist> the microforth implementation could be common to all the objects, so its not duplicated all over the place
20:32:46 <timlarson> I would like message passing + lightweight forth threads...reflecting erlang features
20:32:53 <foucist> yeah
20:33:06 <foucist> erlang is the other thing that inspired the microforth idea
20:33:28 <foucist> or i guess forth threads is the proper way of thinking about it
20:34:54 <timlarson> I am not at the point of implementing those features yet, but am having fun implementing a forth version of term-rewriting from the Bertrand language :)
20:35:07 <timlarson> ...and using it also as the parser.
20:36:17 <foucist> timlarson: how 1X forth is your forth
20:36:44 <timlarson> could you expand on that question?
20:36:54 <foucist> do you know about the 1x forth concept ?
20:37:09 <foucist> how 1xish is your forth
20:37:11 <timlarson> I am not exactly implementing a "forth", just something that happens to swallow forth features.
20:37:45 <foucist> http://www.ultratechnology.com/1xforth.htm
20:38:09 <foucist> actually ignore that shit
20:38:22 <timlarson> I have read it but had to review to remember what the term refered to
20:38:31 <foucist> worrying about complexity/perfectionism like that can stall a programmer ;)
20:39:12 <foucist> Don't Complexify
20:39:12 <foucist> Simplify the problem you've got or rather don't complexify it. I've done it myself, it's fun to do. You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the problem that you actually had.
20:39:18 <foucist> Ten times code means ten times cost; the cost of writing it, the cost of documenting it, it the cost of storing it in memory, the cost of storing it on disk, the cost of compiling it, the cost of loading it, everything you do will be ten times as expensive as it needed to be. Actually worse than that because complexity increases exponentially.
20:39:24 <foucist> 10x Code
20:39:26 <foucist> 10x Cost
20:39:29 <foucist> 10x Bugs
20:39:31 <foucist> 10x Maintenance
20:39:36 <timlarson> I am putting certain purposefully-kept-simple mini-paradigms together so I can use the strengths of each: e.g. term-rewriting, functional, and imperative
20:39:40 <foucist> 10x has an overall cost of 10000x
20:40:33 <foucist> timlarson: is it a good approach to build all the paradigms separately and hook it together?  or to have 1 central idea that makes it easy to be multiparadigm
20:40:45 <foucist> forth, lisp, ruby, smalltalk, they're all multiparadigm
20:40:52 <timlarson> are you familiar with toka's "quotes"?
20:40:55 <foucist> but built on one idea, more or less 
20:40:56 <foucist> nope
20:41:20 <timlarson> you write code like this:    [ abc def ghi ] is froggy
20:41:46 <timlarson> code between [ and ] is an anonymous function, which you can name if you wish
20:42:26 <timlarson> I just use [someword ... ] differenciated quotes to express the different paradigms,
20:42:32 <timlarson> all sharing the same datatypes, etc.
20:42:49 <timlarson> each type is simple and can embed the others
20:42:59 <foucist> i think that the best programming language is the most readable one
20:43:11 <foucist> a readable language forces conciseness
20:43:20 <crc> in toka, quotes are used for definitions, program flow (loops, conditionals), etc.
20:43:21 <foucist> and forces a lot of other requirements
20:43:59 <foucist> wheres the quote
20:44:05 <foucist> [ ] is the quote?
20:44:22 <foucist> sounds like its teh same thing as : ;
20:44:24 <timlarson> yes, a code-quote rather than just a string-quote
20:44:34 <foucist> so a quote is a word
20:44:45 <timlarson> yeah
20:45:03 <crc> foucist, quotes can be nested
20:45:12 <crc> so it's not quite the same as : ;
20:45:23 <foucist> is toka forth ?
20:45:25 * crc does have a small forth implemented in toka
20:45:35 <crc> I don't consider toka to be a forth
20:45:47 <crc> it's like forth in some respects, but differs in others
20:45:53 <foucist> oh, you coded toka
20:46:09 <foucist> forgot about toka
20:46:22 <crc> see http://charleschilders.com:9812
20:46:26 <foucist> yeah i'm there
20:47:42 <foucist> why is toka not a forth?
20:48:06 <foucist> going into forth and renaming all the primitives and getting rid of : ; and creating [ ]  does not change the fact that it is a forth
20:48:34 <foucist> altho i guess the name change is for convenience ?
20:48:46 <foucist> trying to make a better forth with better names?
20:48:50 <foucist> better terminology?
20:49:06 <timlarson> writing another syntax with another paradigm does not make your language not be a turing complete language ;)
20:49:10 <timlarson> pointless argument
20:49:14 <crc> trying to make a forth-like language that meets my current needs (which include portability) 
20:50:22 <crc> consider it forth if you like
20:50:40 <foucist> k
20:50:41 <timlarson> or postfix lisp, or ...
20:56:38 <timlarson> sorry for my sour attitude...just saw so-so fireworks with kids saying "this is boring" and them being right :(
20:56:47 <timlarson> I will try to sweeten up :)
20:56:58 <foucist> timlarson: if the implementation is both an interpreter and a compiler, can be easily done in 5 kilobytes, is easily understood by one programmer, and is stack-based, would you call it a lisp? :P
20:57:19 <foucist> even a postfix lisp?
20:57:31 <crc> foucist, if that's what it was... :)
20:57:36 <timlarson> you need some list handling then
20:59:41 <foucist> actually, i really would like a better language than forth, something that is stack-based, reveals the machine like forth does, and is very simple in implementation
21:00:31 <foucist> any ideas?
21:00:46 <foucist> by better i mean, more readable, easier to code
21:01:11 <timlarson> I hope mine will be, but don't hold your breath waiting for a finished implementation ;)
21:01:33 <foucist> something to make it easier to work on my evolutation ideas, to evolve an evolutation system that adapts to taking full advantage of the machine
21:01:52 <crc> goodnight
21:01:57 <foucist> crc: night
21:02:02 <foucist> scared you off eh
21:02:04 <timlarson> I searched for what I wanted and just flat out could not find it, hence this effort
21:02:06 <timlarson> gn crc
21:02:39 <timlarson> the term-rewriting/constraint-language aspect looks like it will be a big help towards this.
21:03:23 <timlarson> sorry you cannot find much good info online about the Bertrand constraint language...I had to interlibrary loan a book about it.
21:03:31 <foucist> can you give me an example of term-rewriting
21:04:17 <timlarson> bertrand does it roughly like this:
21:04:22 <timlarson> head { body }
21:04:42 <timlarson> the head is a pattern with variables that the system tries to match,
21:04:57 <timlarson> and when it matches then it replaces it with the body
21:05:39 <timlarson> you can do things like tell it the formula for converting temperatures from C to F and from F to K,
21:06:21 <timlarson> and then give it a temperature in any one of these scales and it will give it back to you in either of the other two as requested.
21:07:17 <timlarson> you can also have the body portion write code, the book gives examples of generating both lambdas and assembly code
21:08:29 <timlarson> think of it somewhat like fancy functional code, except it lets you usually eliminate having to tell when to call which function because the system figures this out on its own via pattern matching.
21:09:52 <timlarson> the language consists of just three things: a pattern matcher, an instantiator (replaces the matched data with the of a rewrite rule), and a namespace manager for types and values.
21:10:12 <timlarson> the book has a sample implementation written in scheme
21:10:24 <timlarson> pretty short code as languages go
21:11:35 <foucist> sounds pretty neat
21:11:51 <foucist> pattern matching is a big deal
21:11:59 <foucist> unfortunately forth sucks ass in that respect
21:12:05 <foucist> a serious limitation
21:12:11 <timlarson> yes, but you pretty much need the book to get the full picture...online info is pretty scarce
21:12:29 <foucist> well no worries
21:12:40 <foucist> this stuff ain't exactly a priority for me
21:12:48 <timlarson> "Constraint Programming Languages: Their Specification and Generation" by Wm Leler
21:12:48 <foucist> except for the evolutation stuff
21:12:55 <foucist> k
21:13:11 <foucist> maybe i'll check that out for ideas for coding evolution-based stuff
21:13:19 <foucist> dunno
21:13:35 <foucist> i guess the hard part is coming up with a language to solve my problem
21:13:44 <timlarson> I mentioned it because I am working on it and because it seems it would be a benefit to evolutation efforts.
21:13:49 <foucist> yeah
21:14:28 <timlarson> and since it can *very easily* generate either functional or imperative code it makes a nice match to a forth-like system
21:15:08 <timlarson> and you can flip it around easily as well to have forth-like code build up rewrite rules also.
21:16:02 <timlarson> tying two very simple-implementation and simple-expanation languages together that have very different strengths, to compliment each other.
21:16:03 <foucist> cool
21:16:28 <foucist> timlarson: what are you implementing this forth-like thing in ?
21:17:03 <timlarson> with this plus erlang-style message passing and lightweight threads for resilient distributed processing and I think I will have a winner.
21:17:08 <timlarson> coding it in C
21:17:38 <foucist> because if you're implementing this in C/C++/Java, that is going to bias you, in a bad way..
21:17:49 <timlarson> and with term rewriting it is *very* easy to make DSL's
21:18:28 <timlarson> I am using call threading (a word is mainly an array of C function pointers)
21:18:36 <foucist> for example i haven't seen any good forths that were coded in C, they've all been quite bloated
21:18:47 <foucist> its probably more a bias than the C language
21:19:04 <foucist> but i think every language has a bias
21:19:07 <timlarson> and I found a way to code most of the logic in the being-created language syntax from within C.
21:19:52 <timlarson> with this technique it is almost like ... not coding in C :)
21:20:22 <foucist> most forth implementations in C are kinda done in that style already i believe
21:20:29 <foucist> so becareful ;)
21:21:10 <timlarson> c("forth-word-name"); // compiles a call to a forth word into the currently-being-compiled word
21:21:38 <timlarson> p("forth-word-name"); // similar but compiles a postponed execution of the word
21:22:26 <timlarson> and drifting toward something like toka's word-classes, where c() and p() know whether to call a word as a macro or compile it for later, etc.
21:23:16 <timlarson> if I want to do an asm implementation later I will probably use the term-rewriting system to generate auto-optimized asm code for me.
21:28:32 <timlarson> time for me to sleep, good dreams to all in a similar sleep cycle :)
21:55:26 --- quit: Shain (anthony.freenode.net irc.freenode.net)
22:09:44 --- join: Shain (i=steve@adsl-75-30-112-206.dsl.pltn13.sbcglobal.net) joined #retro
23:59:59 --- log: ended retro/07.07.04