IRC log started Mon Mar  6 00:00:25 2000
[msg(modtunes)] permlog 2000.0306.mod
-:- Closing Link: modtunes[bespin.dhs.org] by asprin.openprojects.net (Ping timeout for modtunes[bespin.dhs.org])
-:- Connection closed from irc.ca.openprojects.net: Success
-:- Use /Server to connect to a server
-:- Connecting to port 6667 of server irc.ca.openprojects.net [refnum 0]
-:- Unable to connect to port 6667 of server irc.ca.openprojects.net: No route to host
-:- Connecting to port 6667 of server irc.ca.openprojects.net [refnum 0]
-:- Unable to connect to port 6667 of server irc.ca.openprojects.net: No route to host
-:- Connecting to port 6667 of server irc.ca.openprojects.net [refnum 0]
-:- BitchX+Deb1an: Servers exhausted. Restarting. [137]
-:- BitchX+Deb1an: For more information about BitchX type /about
-:- Welcome to the Internet Relay Network modtunes 
-:- Your host is asprin.openprojects.net, running version u2.10.05.18.(ipcheck4-5) 
-:- This server was cobbled together Wed Apr 28 1999 at 12 02:19 EDT
-:- asprin.openprojects.net u2.10.05.18.(ipcheck4-5) dioswkfcg biklmnopstv 
-:- [local users on irc(1)] 100%
-:- [global users on irc(1)] 100%
-:- [invisible users on irc(0)] 0%
-:- [ircops on irc(0)] 0%
-:- [total users on irc(1)]
-:- [unknown connections(1)]
-:- [total servers on irc(1)] (avg. 1 users per server)
-:- [total channels created(0)] (avg. 0 users per channel)
!asprin.openprojects.net Highest connection count: 8 (7 clients)
!asprin.openprojects.net Welcome to Open Projects!  You are on 1 ca 1(2) ft 14(14) tr.
-:- Mode change [+f] for user modtunes
-:- Mode change [+iws] for user modtunes
-:- JOIN activated by "modtunes #modtunes tunes@bespin.dhs.org "
-:- modtunes [tunes@bespin.dhs.org] has joined #modtunes
-:- [Users(#modtunes:1)] 
[@modtunes  ] 
-:- Channel #modtunes was created at Mon Mar  6 14:25:46 2000
-:- BitchX+Deb1an: Join to #modtunes was synced in 6.846 secs!!
-:- Mode change [-ws] for user modtunes
-ChanServ(s@ChanServ)- This channel has been registered with ChanServ.
-:- mode/#modtunes [-o modtunes] by ChanServ
-:- water [water@tnt-9-94.tscnet.net] has joined #modtunes
-:- mode/#modtunes [+o water] by ChanServ
-:- tcn [r@cci-209150250172.clarityconnect.net] has joined #modtunes
-:- mode/#modtunes [+v tcn] by water
-:- SignOff tcn: #modtunes (Ping timeout for tcn[cci-209150250172.clarityconnect.net])
-:- tcn [r@cci-209150250039.clarityconnect.net] has joined #modtunes
<tcn> modtunes.. eh?
<water> yes what about it?
-:- mode/#modtunes [+v tcn] by water
-:- mode/#modtunes [+mnt] by water
<tcn> just another channel?
<tcn> less crowded
<water> no, it's logged and used for moderated tunes discussion
<water> it's supposed to boost signal-to-noise ratio when really needed
07:20pm
<tcn> ah, that's why the +v.. giving me a voice :)
<water> which is not terribly often
<tcn> irc isn't a great medium for designing anything :)
<water> it depends on the people involved
<water> when tril and beh are here with me, stuff gets done
<tcn> slate/lisp stuff?
<tcn> what's beholder working on?
<water> unios
<tcn> oh yeah :)
<water> also akos
<water> btw, abi is not here since not needed for the kind of discussion this channel was meant for
<tcn> :)
<water> if we need to insert a url into the discussion we do it manually
<tcn> reading web pages ain't exactly real-time
<water> hm i actually have something to ask
<tcn> hard to read in depth, and still participate in a discussion
<water> do you see the lll as one reflective language or just any language that the hll is (re-)implemented upon via reflection?
<tcn> umm... not necessarily either... let me explain
<water> maybe the latter can be seen as a set of primitives
<water> k
<tcn> I see it as something like an exokernel and a monitor/programming interface
07:30pm
<tcn> the HLL need not be layered over the LLL; it could bypass the LLL
<tcn> *should* bypass at least part of it
<water> i don't see it that way at all
<tcn> what are you thinking?
<water> of course, i'm a fan of "language to the machine"
<water> to me, the lll just reflects the current implementation of the hll
<water> it represents the kind of atomic things that the hll uses for control constructs, i/o, etc
<water> but i don't see tunes as having one lll, but many, dynamically-implemented lll's
<tcn> dpending on the hardware, right
<water> no not just that
<tcn> s/hardware/platform/
<water> even on the same platform, i see the beneficial use of several different kinds of primitives
<water> optimized for different kinds of semantics or performance directions
<tcn> right, especially for experimentation.  I.e., paging vs. non-paging
<water> well what about forth vs tiny lisp?
* water/#modtunes tries to think of a more useful example
<tcn> forth handles the really low-level stuff better... it makes sense to consider lisp/scheme the HLL-
<water> i disagree
<tcn> on forth, lisp, or both? :)
<water> "better" is just a matter of what you want out of it
<water> either
<water> er both
<water> forth might handle low-level stuff better, but what if you want a different kind of system?
<water> what if you want to manipulate state-machines in lisp in order to low-level program?
<tcn> you'd want both languages
<water> both doesn't make sense
07:40pm
<water> what if i really want a minimal lisp vm to do this with?
<water> on the bare hw as opposed to defined in forth?
<tcn> If I could only have one I'd choose Forth and add some list stuff
<water> yes *you* would
<tcn> hehe
<water> tunes is not your private project, and it isn't mine either
<water> i happen to like forth, actually
<tcn> I actually have a rationale for doing forth, then scheme, then whatever HLL
<water> although i think i prefer "until"
<water> i don't care about the rational
<water> rationale
<water> i'm sure they are excellent and true arguments, but they must have some implicit assumptions that will break
<tcn> well.. it's better to do both than neither
<water> simply because someone will have different assumptions
<water> well here's my take:
<water> i don't care how the hll is initially implemented because the whole point is to re-implement it on top of the lll
<water> and again and again on different lll's
<water> which is why i have completely avoided discussing lll on the tunes mlist because to me it's totally irrelevant
<water> you might as well s/forth/uK/
<water> :)
<tcn> right.. you're an HLL guy
<tcn> ? :)
<water> i'd like to think of myself as a tunes guy, but ok
<water> i consider the lll aspect of tunes to be a library issue
<water> it's just a different way of re-compiling the compiler's interface to the machine
<water> which is part of the compiler's source code
<water> written in the hll
<water> so you see, i don't care about forth until someone writes it in the hll, which of course requires someone to define & implement the damn thing
<tcn> hmm
<water> i actually want the entire hw spec as tunes hll objects
<water> i don't think the web site advocates that
07:50pm
<tcn> this HLL is supposed to understand Forth (or something better), and LISP, and more, and translate between them all...?
<water> no not quite
<tcn> agreed, everything should be an object.. with the exception of maybe a few K of boot code
<water> no, even the boot code
<water> i want it all in the hll >:)
<tcn> in one sense
<water> i'm looking more at having a forth system written in hll that could be compiled into binary code that does the same thing as a "on the bare machine" forth implementation
<tcn> you can't really modify the boot code in-place.. you have to reboot, or at least stop everything and JMP to it.
<water> right
<water> but that doesn't stop you from having an object to deal with it conceptually
<tcn> we can't take all the 'touchiness' out of 'kernel hacking'
<tcn> right :)
<water> trust me, i'm working on all this stuff in slate
<tcn> cool
<water> yeah it's a real pain in the neck
<tcn> objects... shall we pad them all to be some power of 2?  except objects that rarely grow
<water> huh?
<water> i don't care, that's for the compiler writers
<water> and it doesn't sound very efficient at all
<water> even squeak doesn't do that :)
<tcn> for speed, not space
<water> even so
<tcn> i've heard good things about that method; that's enough for now
<tcn> i'll give it a try
<water> ok sure
<tcn> I bet the OS you're using now does it too :)
<tcn> anyway, about this forth written in hll..
<water> well forth consists of stack operations
<water> you can look at it as a way of creating abstractions over the hardware or a virtual machine itself
<water> both work fine
08:00pm
<tcn> are you familiar with forth 'metacompilers'?
<water> a little
<tcn> i guess you have to write one before it really hits you :)
<water> i guess so
<water> sorry, i have about 50 languages i keep traack of and have tried to grok
<tcn> yeah
<tcn> anyway, in a nutshell:
<water> have you tried until, btw?
<tcn> until?
<water> grr abi forgot
<tcn> i thought it was a typo :)
<tcn> must be a language
<water> a fellow wrote it up in a book on small languages
<water> it's a type of forth with dictionaries that are somehow more modular
<tcn> hmm.. i've had some discussions about that sort of thing.  allowing different types of dictionaries, for example.
<tcn> a normal dictionary is in RAM as a list/tree/hash.. and other dictionaries can be listed as words in that dictionary, creating a hierarchy (links are possible too)
<water> http://www.forth.org/compilers.html
<water> at the bottom of the page
<water> yeah i know
<water> i think this one allows dynamic unloading/loading perhaps?
<tcn> right, stuff like that.. and a dictionary using an 'external' searching technique, as a filesystem.
<water> hm ok until is just a forth that uses the os features
<water> (like persistence of unloaded dictionaries)
08:10pm
<tcn> it's easy to use different 'dictionary engines'... we can incrementally move from a simple dictionary to a persistent object store dictionary
<water> anyway, metacompilers in a nutshell?
<tcn> oh yeah
<tcn> it's how Forth compiles Forth
<water> that's it?
<tcn> the host compiles/assembles the target's words, starting with the lowest level and defining the higher level words from those
<water> "host" "target"?
<tcn> it's not that complicated
<tcn> for me, host=gforth, target=retro
<water> how do you compile in forth? the usual way right?
<tcn> and when retro implements all the words used by the metacompiler, the host can also be retro
<water> hm ok
<tcn> how do you compile?... 
<tcn> you mean, : WORD ... ;
<water> uh sure
<tcn> If : is the compiler, the metacompiler is T: (target compiler)
<water> i don't know WORD
* water/#modtunes slaps himself
<water> duh
<water> n/m
<tcn> : <word you're definiing> <code> ;
<tcn> hehe
<water> yeah no kidding
<water> i missed the colon
<tcn> anyway, I should get moving here..
<water> i thought "word" meant a special declaration type
<tcn> good talking to ya
<water> k
<tcn> I have renewed hope for tunes :)
<water> you should have talked to me sooner ;)
<tcn> didn't have time :)
<water> use the mlist more
<water> i've become a bit reclusive
08:20pm
<tcn> are you on tunes-lll?
<water> no
<tcn> some activity there, after my question about the necessity of MMUs
<tcn> but you don't care, it's lll :)
* water/#modtunes shrugs
<water> yeah pretty much
<water> i categorize it with c and all those other crappy languages
<tcn> the responses are encouraging
<tcn> that's all you'd care to know
<water> heh
<tcn> wow.. ashley winters, out of the blue :)
<tcn> a lurker speaks :)
-:- SignOff tcn: #modtunes (Core dumped)
08:30pm
-:- mode/#modtunes [+o hcf] by ChanServ
[msg(modtunes)] newlog 2000.0307.mod
IRC log ended Tue Mar  7 00:00:01 2000