IRC log started Sun Jan 16 00:00:01 2000 what's "specializing", though? maybe this is trivial or something in smalltalk it calls a version of the method based on the types of its arguments [msg(TUNES)] permlog 2000.0116 you define a version of the method specifically to handle certain types of arguments oh, that's implicit for self * eihrul/#tunes nods. its the first thing i saw yuck that it does it implicitly i agree that it should be implicit but you could use multi-methods to implement lazy compilation like that :) yeah, that's an implementation technique, i agree it would be hackish, but it'd be a fun hack :) but it should not be in the language itself * eihrul/#tunes nods. its just doing what the programmer would do and probably better at that though there are other uses of multi-methods (that is not one of the uses, just a possible interpretation of multi-methods) i don't think my syntax idea for messages will allow multi-methods... at least i hope it doesn't i.e. if you wanted to make a + method that would concatenate two objects of any type actually, as long as there are no static types or declarations, it won't to the type of the first object a multi-method could be useful :) well, in smalltalk/self, methods are defined assymetrically i.e. per-class its only a small change to method lookup that means the reciever of the message does any 'type-checks' what is? well, methods in smalltalk/self already specialize on the first object (though its probably far simpler to do that :>) right, and specialization on the second, third, etc is done dynamically which of course isn't really specialization compile time message lookup and inlining.... mmm oh yeah, classes would also be used to describe algebras and finite-state machines any object with an algebraic protocol would be a member of the appropriate class 12:10am and oh yes, i have to deal with mutability for values versus objects, as in the integers, reals, etc er... that didn't come out right agreed well, it just means that the primitive objects of the language will need to fit into the language model without breaking it hopefully, new objects could be added this way, like values for complex numbers, etc well, primitive types should make some attempt at looking like non-primitive objects that way you wouldn't have to constantly refer to your complex number objects internally as ordered pairs (even if they aren't implemented as such) right i don't think the self/smalltalk family does that right actually, they do, but they don't have immutable objects by default hm (4 add: 3) == 7 the problem is that 3==3.0 wtf is the colon for? air: shush the colon designates the message as requiring an argument that is dumb water: so that 3 no longer appears as a unique object? like (myStack pop) vs (myStack push: a) eih: not sure i follow well... you can few integers as immutable objects why dont u make a language that is powerful yet easy to use??? every integer being a unique immutable object air: shut up now, 3 happens to be such an object but 3.0 is a different object completely in this scheme you can't assign to 3 or ask 3 for its value it has no state 12:20am well, the 3.0 is another problem as well :) well, why does a 3 need state? but you *can* ask for a realnumber version of 3 and 3 will answer with 3.0 its signifigant is merely its particular uniqueness and its relation with respect to the other unique integer objects right that's one of the reasons i like the idea of a class it doesn't need a state, it doesn't need a value, it doesn't need to be assigned so all you need is its address (its name) (not the usual one, the one we're debating) yep, and to know its protocol as well which includes its algebra and its conversion methods * water/#tunes looks into the squeak code for a moment well, you have tagged pointers which allow an exceptionally short representation for a fixed number of types sure (which can then refer to some larger representation outside of the object) actually, numbers have a quite intricate protocol yeah, but that can be accounted for you jsut have a particular case where a particular pointer tag, say 0, says that the prototype for this class can be found in a specific location :) rather than found by dereferencing the pointer for it yeah, most are operators, functions, or relations hm though it'd be nice if there was a more generalized way to handle such but the only useful thing you can represent in 30 bits is a fixed precision number anyway :) hm lots of wrapper methods for printing er... low-level encoding to files or ports etc though you can't represent a pointer with an integer, which is a drag :) (atleast not a fixed precision one) unless you have a model for the memory system supported by the implementation of course * eihrul/#tunes nods. actually, you could since the only interesting pointers are those to objects which only need 30 bits (so you could easily represent one with a 30 bit integer) hm 12:30am well, there always are unbounded integers in any good high-level oo lang as i said (atleast not a fixed precision one) :> oh yeah heh i'm just thinking out loud here :) well, the class idea would allow you to characterize types without worrying about internal state of the values... the class would be implemented by a representation system types, of course, being coherent behaviors bound to "values" instead of objects in general hm... maybe classes shoulld define the notion of values... values exist because the class specifies how they are reached of course, this doesn't clash with normal oo, except that normal oo considers the word "class" to apply to object templates oh yeah, did you grok that blurb on predicate objects? well, in a system like self values *are* classes yah, well enough i think... not sure i follow 12:40am well, the predicate object idea allows you to write simpler code, imo, by having the condition check be implicit to the relevant methods for handling the condition by over-riding normal methods well... er... basically, you can write methods for special cases without explicit state-checks within the method there, that sounds right you have a slot that refers to a parent object that represents the object's prototype of course which is pretty much that same as having a number s/that/the how so? numbers are objects uh what does that have to do with it? they're the only interesting state you can have :) uh sure but perhaps i'm rambling out the rear yeah, i think you are :) okay.... have recollected thoughts :) heh there's conceptually little difference between a parent slot and a value slot except in such cases, you treat the value slot as a parent slot of sorts ok, except that the parent slot influences method-lookup yes... but the value slot also influences it (if you have specialization by value) well, sure, by being passed around until the method is resolved into primitives it acts as a sort of parent specifying certain traits of an object thats inheriting that value eihrul: have you read about the idea that Self objects' parents are really "shared parts"? havne't read that far but that's something that just seems obvious to me it addresses that well 12:50am but, allowing to specialize on value would be equivalent to treating a given value slot as the parent that was my whole values *are* classes thing :) oh you were talking about self, so i didn't get what you meant by "class" okay, i should have said prototypes sorry for confusion np i waste my time in much worse ways :) though, a true object can specify functionality whereas a value starts having problems with that.... hm ok the difference in instantiating an object as an object and an object as a function is that the latter readily deletes the object when the return value is obtained (when the object terminates) yeah, just a variable optimization (get rid of unused variables) and it seems there would be effects of meta-objects on this functionality in the case that its not mentioned anywhere then the compiler can simply never create it hm right if its passed to another method or returned, then the compiler has no choice but to let it live even if the method it passes it to is done with it by the time it returns (unless its inlined and you know what the method does with it) this directly affects the immutable object idea though, its more a question of where you allocate it than if :) since every object state in the stream(s) is linked with its neighbors by objects acting as functions (operators in the case of unchanging type) since methods need to be allocated, they're just allocated based on their specific liveliness policy, which happens to be very conspicuously modeled by a stack :) water: i got a question for u about self eih: heh :) air: shoot water: when u call a self method it must get a pointer to the objects prototype and then lookup the method and then call it which is slow water: what would be nice though if you didn't explicitly need to so much tell the system to need the stack air: not always water: especially if the method is many prototypes up the chain how do u optimize that? some kinda cache? water: getting rid of the stack notion altogether could be feasible with copy collection or such air: yep water: though GCs would be more frequent :) you compile the methods JIT or beforehand and self usually has polymorphic inline caches 01:00am for the common cases water: though... if you added in a general heuristic to explicitly free the object if the compiler knows its not being used, you can have stack behavior almost by default eih: hm eih: well, lets leave gc implementation for later oh self has a compiler? air: defiinitely water: its not GC so much as making the implementation of methods as similar to objects as possible thought it was interpreter thingy air: otherwise they wouldn't have benchmarks on it for up to 50% of optimized c water: making the implementation even treat them similarly eih: yes that would be desirable 50%?? that sucks lol rather than allocating methods on a stack (objects that don't happen to use the self), or objects (those that do use self) get put on the heap air: without static compilation, that's great... only runtime type-checking and just having one unified place for allocating both objects that behave like methods and objects :) air: self is about dynamic programming ya i know eih: that's a wierd concept but we might have to do that not so weird why not? you're doing it at the language level hm so if i can somehow get a 'stack-like' behavior to dump out of such a unification at the implementation level all the better :) maybe multiple stacks or one stack per thread and a heap per memory space although without proper care, we'd thrash the cache well, if you can just have one heap :) yeah, keep it simple, i know :) so, the local variables of functions would correspond to object state and who knows, maybe it'd be beter for cache behavior 01:10am because heap objects and stack objects would just be heap objects hm but then you couldn't do certain things with compilation since x86 is heavily biased towards stacks call/ret would be no good if we use the self idea of only allowing state-changes through messages to self, then every update to a function's local variables would be via messages to self x86 stacks suck * eihrul/#tunes nods. stacks are rampant :) how does self handle assignment to local variables? i never realized how bad the x86 architecture was to code for until i worked on a 3d graphics engine for ppc objects send messages to themselves i.e. erm, *local* variables :) if i have an object X with variable g, "self g: x" sets g to x but the self syntax allows you to skip the "self" keyword for brevity you can make variables into constants by hacking into the object and deleting or disabling the message that invokes the variable-update primitive and no object can force another's state to change except by message-passing but then, that allows other objects unrestricted access to other objects' variables iirc how? and why cant u declare constants? i could call "X g: x" from a method in Y 01:20am because declaring constants would have required more language features and self has no declarations you *could* provide state-protection by having two objects represent one, and making one exhibit the public protocol, while the other has the full access to the variables or just using closures.... but that assumes that other objects will only call the "public" object hm yes and not giving the outsider access to the namespace otherwise i don't use object closures very often if the message handler to modify the variable is disabled then how could other objects access it? s/access/modify/ well, i guess i should've said that other objects were no more restricted to use an object's varialbes as the object itself that would be a more correct statement security is overrated anyhow :) well, self assumes all the source code is available if u disable the message handler isnt that like disabling telnet into yer machine? how could someone get in? except for imported objects from c++ :) lol just hack back into the object and add the accessor method hmm or clone the object and then hack *that* object er... hack the clone but then yer hacking a clone what purpose does that serve? duh it allows you to get and change the state without affecting the original result that would be like someone downloading (cloning) a text file from my web page and then modifying it. modifying the clone doesnt affect the original well, like i said, just hack the original if you want to change it into a changeable object 01:30am silly :) i notice that i explicitly said that you had two options there even in a distributed environment, you can change someone else's object, but you have to talk to the object's environment to do it, and that allows the owner to intercept the message-send and check it against a security protocol which in self or smalltalk means you can implement any security (or insecurity) system you want eihrul: i think it would be desirable to have implicit that the input and output types of every function be a single object eihrul: in the case of "multiple variable" input or output, the different variables would just be part of the expression passed. the top cons cells would be the *actual* arguments hm. in the slate system, constants could merely be functions that don't depend on input beta does the same thing 01:40am why is comp.os.research only used for CFPs? cause no one has anything to ask i suppose 01:50am -:- SignOff air: #TUNES (BRiX [http://www.qzx.com/brix] :: sleep) hm anyone still here? yes k yes * water/#tunes tries to figure how to turn tonights discussion into specs 02:00am and i must write tril and the author of icct hcf, eihrul: just so you know, the class idea is very similar to the major intended application of graphs k "SELF is implemented in 33,000 lines of C++ code..." :) that's less than pretty too big a project for you? :) well they didn't have a lot of practical goals in mind e.g. portability well, i mean the C++ part :) 02:10am 33,000 lines isn't too nasty especially for what it is oh. heh its quite small actually abi: self? self is, like, a prototype-based object system, at http://self.sunlabs.com/ or mirrored at http://www.cs.ucsb.edu/oocsb/self/ its alive! its alive! * eihrul/#tunes cackles like Dr. Frankenstein. cool lol sunlabs, i mean * Fufie/#tunes wakes up from his small nap eih: i know oh wow. only two actual lurkers must be a record :) fufie: have any practical suggestions for language implementation method? 02:20am water: well, i'm willing to help in whatever grunt-ways necessary :) heh thanks yeah i guess it would look good for you when you get to college to say that you've implemented an advanced programming language :) well, i've already implemented lisps... how more advanced do you get? :) uhh though none of them were serious water: I think eihrul is doing the right thing by implementing it in lisp eh its not an implementation fufie: ok, i just wondered about how to go about a compiler in the right way i was just toying with the functions-as-objects-as-functions concept water: as it it sexp-based using lisp will let you get the whole tree and make it easy to write an interpreter fufie: sure eihrul: it's still a route to implementation going from interpreter to compiler is ok because then you know that things are correct hm there are complete compiler generators for clisp? as eihrul has PAIP, he might want to check out the two chapters in the end how Scheme is implemented in common lisp and how the compiler is written sure, but there's the fun aspect to it :) just writing a slate2lisp translater is not very 'sexy', but i can brave it for now :) your language is experiemental, no? it's a long tiem as I see it till you should fight outside a lisp well, until we get the reflection system going, it'll be just an experiment as far as i'm concerned Fufie: all i'm doing right now is researching languages myself :) although i have no intention of *not* making the reflection system both of you should read the two scheme-chapters in paip to see how it is customary to build simple languages in lisp yeah i've got sicp that a good substitute? sicp is nice, but it doesn't have all the tools common lisp has so a normal lisper will use slightly different tools * water/#tunes wonders why the f*** the lisp gurus in tunes aren't helping what lisp gurus? :) there's umm... fare there's fufie... fare etc but who else? :) yes i suppose that they're all we have * Fufie/#tunes has no time for slate in weeks oh well I can help out with ideas and give advice on what to read -:- dalvarez [ircusr@212.68.72.98] has joined #tunes (as I do) gee thx greetings hi alvarez 02:30am you interested in tunes? hey, i exist man! abuse me! >:) I'm was looking for EuLISP implementations this morning that could serve the project (think it was eihrul who mentioned s.th. yesterday) but it seems there doesn't exist anything that completely accomplishes the specification uh sure oh! alvarez: you on the mlist? water: nope dalvarez: that was fufie eihrul: ack Fufie: i noticed that from eulisp standard was conspicuously absent read, eval, macro characters, etc :) and (compile) dalvarez: eulisp was for the implementation, check out common lisp or scheme to get working implementations you can experiment with I found some papers describing the standard together with come existing implementations eihrul: READ and COMPILE will be added, don't worry :-) s/come/some .... you see, Fufie - I'm leaning Fufie: oh, that and you can't use any macros defined in the same module! dalvarez: that is good, but I think you misunderstood me slightly.. use CL or Scheme to learn stuff.. I suggested eulisp as a base for implementing the tunes language there seems to be no end to self papers.... eih: yup. quite a few phd's based on it eih: and numerous random papers well, i can have a phd education without the fuss of graduate school :) > (i intend to be a professional student FYI) heh. remember you're talking to a dropout :) the specifications are @ www.aiai.ed.ac.uk/~jeff/lisp/eulisp.html abi eulisp? eulisp is http://www.bath.ac.uk/~masjap/EuLisp/eulisp.html and http://www.aiai.ed.ac.uk/~jeff/lisp/eulisp.html and ftp://ftp.maths.bath.ac.uk/pub/eulisp/ oh good its there tricky... lycos found ot for me ( whould have been more tricky to ask abi first) s/ot/it/ how is abi tricky to use? abi: abi? hmmm... i am the little girl borg with a big brain or #tunes' infoslut don't doubt how big 'big' is! -:- SignOff water: #TUNES (Leaving) abi is omniscient! 02:40am abi anal masturbation? i don't know, dalvarez -:- water [water@tnt-9-124.tscnet.net] has joined #tunes not at all. aihrul the #linuxhelp faqs gets it and says s.th. like anal retentive rmm, abi knows all worth knowing abi gf? dalvarez: i don't know again, abi is female -:- SignOff water: #TUNES (Leaving) -:- bod [bod@203.101.1.221] has joined #tunes abi god and the world abi god and the world ? i don't know, dalvarez -:- bod [bod@203.101.1.221] has left #tunes [] again abi is wise eihrul: :) took long that, think it's fake abi ai dalvarez: nah, just lag