IRC log started Sun Feb 13 00:00:01 2000
[msg(modtunes)] permlog 2000.0213.mod
-:- hcf [nef@me-portland-us202.javanet.com] has joined #modtunes
-:- mode/#modtunes [+o hcf] by ChanServ
-:- water [water@tnt-9-153.tscnet.net] has joined #modtunes
-:- mode/#modtunes [+o water] by ChanServ
<hcf> i /invite'd him to #osdev and he joined it, which i didnt expect
<hcf> anyway, get eih in here
<water> ok
-:- eihrul [lee@usr5-ppp114.lvdi.net] has joined #modtunes
<eihrul> yes...
<water> did you follow what i was saying?
<eihrul> but i always thought this would be automagically handled by a meta-object some how :)
<water> yes but the syntax has to handle it or we'll get infinite regression and inconsistencies
<eihrul> by just modifying lookup appropriately for method arguments
<water> "appropriately"?
<water> you have to specify the namespace
<eihrul> appropriate such that it accesses a given namespace...
<water> yes, but which one?
<eihrul> which in itself seemed tricky
<water> exactly
<eihrul> because something has to know which one :)
<water> yep
<eihrul> the method needs to know which namespace it belongs to
<water> and methods are just objects by a different name
<eihrul> and it could belong to many...
<eihrul> theoretically
<water> well, we just need to know how to manipulate namespace-context explicitly
<water> or, as necessary to make it work
<water> of course, cleanness is good, but we need building blocks
<water> let me show an example
<water> myObject (setVar1 foo)
<water> as it is, the first parenthesis pops the object's namespace onto the stack
<water> so that "setVar1" gets looked up and can access meta etc
<water> and it gets identified properly as part of myObject's namespace, not the global one, avoiding conflict
<water> the problem occurs when 'foo' gets encountered
* eihrul/#modtunes almost sees this as a thread-local attribute.
<water> naturally, we want to grab 'foo' from the global namespace by default, unless we want another variable from myObject
<water> if we want a variable from myObject, we can still use the global namespace to get it via (self Var3)
09:30pm
<water> actually, this would require the self binding to remain in effect even as we access the global namespace
<water> er... s/global/enclosing/
<water> hm... thread-local
<water> well anyway it seems obvious to me that we need a special syntactic operator to access this namespace
<eihrul> though i don't have any idea how thread-local data would fit into slate :)
<water> e.g. myObject (setVar : foo)
<water> well, we'll see about threads soon enough
<eihrul> because a thread must enter into a namespace to access its data
<eihrul> which could be conceptually modelled by a namespace stack
<water> i used the colon because it reminds me of smalltalk and it seems the appropriate context in which the operator would be used
<water> yes, that's true
<eihrul> though, it ruins the uniformity of object-namespace handling :)
-:- lar1 [larman@sdn-ar-018casfrMP017.dialsprint.net] has joined #modtunes
-:- lar1 [larman@sdn-ar-018casfrMP017.dialsprint.net] has left #modtunes []
<eihrul> however...
<eihrul> you have a stack of objects that have been looked up
<water> well, maybe threads should be later
<eihrul> by default
<eihrul> selectors are looked up in the top...
<water> not sure i follow dude
<eihrul> por ejemplo...
<eihrul> (namespace (myObject (setVar : foo))
<eihrul> as the evaluator descends into the tree, to foo
<eihrul> it looks up each selector, namespace, myObject, setVar, 
<eihrul> by default...
<eihrul> selectors are looked up in the last object to be looked up at the front of an expression
<eihrul> if you look at this as a stack
<eihrul> then its merely looking up selectors in the top of the stack
<eihrul> which suggests they can be looked up from other objects residing on this stack
<eihrul> perhaps by binding some syntactic name to it
<eihrul> and using it later to override 
<water> yikes slow down
<eihrul> whoa, lag burst
<water> ok
-:- mode/#modtunes [+v eihrul] by hcf
-:- mode/#modtunes [+mn] by hcf
09:40pm
<water> i'm still not sure i follow you precisely
<water> i mean, i understand cascaded look-up
<eihrul> basically
<eihrul> binding a name to a previously looked up object
<eihrul> and using this name later to override where a selector is looked up
<water> how, though? you'd still need some primitive syntax operator
* eihrul/#modtunes nods.
<water> so we have two proposals
<eihrul> it's not the cleanest or well-thought out of ideas
<eihrul> but it's an idea :)
<water> well we can use the *nix file system syntax
<water> e.g. "..", ".", "/" , etc
<water> it works
<water> (at least it works, that is :)
<water> and we wind up merging namsespaces with a sort of file-system
<water> i actually used this idea extensively in my old design in college
<water> i even used it for the inheritance hierarchy, though with different operators
<water> ult: check logs to catch up
<eihrul> though it's readability may suffer :)
<water> well, certain of the namespace operators will be less successful than others
<water> .. will definitely be common
<water> root itself could access modules or something
<eihrul> water: you still need a special syntactical operator for accessing the bottom of the stack of 'directories' :)
<water> hell, you might even do regexp searches :)
<eihrul> but i suppose that's what '/' would be....
<water> yes
<water> it happens to also be why i named the root of the inheritance tree "root" :)
<water> i can't believe i didn't even recall this until an hour ago
<water> this system even allows for "proc" to be semantically meaningful
<water> >:)
<water> so there! :)
<water> does it sound like it'll have any problems?
<water> i think it even obviates the need for a 'self' pseudo-variable
09:50pm
<eihrul> not quite...
<water> ./?
<eihrul> because self may be relative to root in an undescribable way...
<water> what about ./?
<eihrul> and using combinations of .. is not exactly intuitive...
<water> ahem
<water> ./
<eihrul> aka current directory...
<eihrul> but if you have nested sexp
<water> yep
<eihrul> then you have to go back down the stack to access self :)
<water> well, we could use parentheses explicitly for namespace contexts
<water> instead of the lisp version where parenthesis use is liberal
<water> well hm
<water> i think we would *need* to go back down the stack to get "self" no matter what
<water> because otherwise self would just refer to the message selector :)
<eihrul> well, i think being able to bind a name to a specific object is useful for this
<water> how do you mean?
<eihrul> well, instead of referring to something relatively
<eihrul> you bind a specific name to a looked up variable as explained earlier
<eihrul> an ad-hoc example using an off-the-top-of-my-head-syntax:
<water> hm like a symlink?
<eihrul> (foo=bar (baz bar:x))
<eihrul> foo is looked up, and bound to the symbol bar
<water> dude you gotta get better names
<eihrul> which can then be used later to override where x is looked up in
<eihrul> foo bar and baz are so versatile :)
<water> they suck, dude
<water> especially in o-o
<water> so foo would represent ... ?
<water> and where would it be bound?
<eihrul> (objectSelector=overrideSymbol (methodSelector overrideSymbol:argumentSelector))
<water> not much better, but it's a start
<water> so describe what this does
10:00pm
<eihrul> it binds overrideSymbol to the result of looking up objectSelector...
<eihrul> only so much as syntactically
<eihrul> the compiler already knows where the looked up result is
<water> but within what namespace?
<water> i want to know where that binding is
<eihrul> its completely syntactic :)
<water> wow. zero-info there dude
<water> sometimes you really surprise me :)
<eihrul> the bindings could reside somewhere
<water> well, it seems like you're just using the equivalent of a symlink
<eihrul> but i don't see how that's ultimately useful
<eihrul> not necessarily
<water> prove the difference
<eihrul> well, the name is available to any enclosed directory
<eihrul> whereas a symlink is just an alias within a specific directory :)
<water> ok i already assumed that
<water> s/directory/namespace/
<water> er... vice versa
<water> whatever doh!
<eihrul> much more similar to the lambda calculus than the file system :)
<water> sure
<water> but it's still about nested scopes
<water> which imo, file systems should be, but that's beside the point
<water> so have we agreed on a set of operators at least in terms of semantic requirements?
<eihrul> i don't know...
<eihrul> my conscience is saying there's something inelegant about this :)
<water> well we have a metaphor at least
<water> what irks you about the metaphor?
<eihrul> complexity
<water> huh?
<water> i'm not proposing a posix file-system, just a metaphor
<eihrul> its one of those situations that's easier to single out as wrong but harder to suggest a correction :)
<water> hm gee thanks
<eihrul> if i had a solution, i'd let you know :)
<water> i think its just a case of you thinking a word is mispelled when it isn't :)
10:10pm
<water> well you have to agree that we need mechanisms for handling namespaces no matter what, and that namespaces make it complicated to access remote code
<water> i'm just saying that accessing self, parent, and meta involve namespaces too
<eihrul> yeah, i'll ponder over it tonight
<water> and the more unified a system we provide, the better
* eihrul/#modtunes nods.
<eihrul> i just can't help but look for something more aesthetically pleasing though...
<water> we already know how to do block-scoping with inheritance
<water> what could possibly be more pleasing?
<eihrul> well
<water> maybe if we removed the restriction on the shape of namespace relations
<eihrul> my mind is foggy with the buzz of a head-ache
<eihrul> and tiredness
<water> ah
<eihrul> so i really need to sleep on this :)
<water> yes, i agree
-:- mode/#modtunes [+v ult] by water
<water> what do you think, ult?
* ult/#Modtunes thinks unified systems are great.
<water> what about using namespaces using directory operators?
<water> and possibly even inheritance hierarchies using a similar set of operators?
(ult/#Modtunes) Well...it's certainly a novel idea...but wouldn't that incur a bit of overhead?
<water> i don't think so... smalltalk and self have the same operators under different names
<water> but i could be wrong
(ult/#Modtunes) Heh, And self claims speeds up to 50% of that of C!
<water> well, that's a different kind of claim
<water> i mean, they only get that because of a lot of compiler tricks
<water> even though the tricks can be used on other systems
<water> hm so i've wound up "dirtying" the syntax a little in exchange for a fully-usable syntax
<water> and we seem to have gotten the namespace system working i think
(ult/#modtunes) Does it do what you want it to do, though?
<water> hm
(ult/#modtunes) Don't compromise, that's what makes languages suck.
<water> well we can send messages to self, which wasn't possible before
<water> and we got rid of our previous infinite recursion with syntax, which of course is good
<water> unfortunately, we don't have absolutely pure o-o
10:20pm
<water> well we still have it, but with namespaces
<water> i mean, now we can't get rid of namespaces no matter what
* ult/#modtunes nods
(ult/#modtunes) So they really ought to be intuitive, most importantly.
<water> and hell, in college, i needed *four* hierarchies instead of *two*
<water> yes i need to make sure they make sense
<water> well syntax sugar could be overlaid by macros
<water> macros just being transformers of trees of symbols
<water> wow. it's been a good day, then. i'll write all this up
<water> thanks everybody :)
<hcf> water: hey
<water> hcf: yes?
<hcf> ur gonna do up a code page right?
<water> yes, with eihrul's evaluator for now
<water> thx for reminding me
<hcf> get /tmp/slate/* and re-ast
<water> right
<hcf> note
<hcf> re-ast means ast'ing all the files
<hcf> otherwise some will differ :/
<water> yes i have them cached on the server
<hcf> changes:
<hcf> removed <small>
<hcf> added navbar link to slate-code.html
<water> ok
<hcf> cool
* hcf/#modtunes is away: (afk)
10:30pm
<water> alright well i don't think i have anything more to add here
<water> so, if you don't mind, ....
-:- mode/#modtunes [-v eihrul] by water
-:- mode/#modtunes [-v ult] by water
10:40pm
[msg(modtunes)] newlog 2000.0214.mod
IRC log ended Mon Feb 14 00:00:01 2000