I'm implementing Scheme dialect with OOP, default argument values and some other features. How readable is it for you?
(define (fib n (memo . #{ (0 . 1) (1 . 1) }))
(let ((memoized (: memo get n)))
(if memoized (cdr memoized)
(let ((result (+ (fib (- n 1)) (fib (- n 2)))))
(: memo set! (n . result))
result))))
>>3
I've already thought about that way, but I want to be able to distinguish between function call and object's method call. >>4
>Pure Scheme will never see use in industry
ftfy >>6
I have also tried this, but it looks ugly and I want to make object itself callable.
Name:
Anonymous2012-06-17 4:56
I'VE ALREADY THOUGHT ABOUT THAT WAY, BUT I WANT TO BE ABLE TO DISTINGUISH BETWEEN FUNCTION CALL AND MY ANUS
Name:
Anonymous2012-06-17 5:47
>>12 but I want to be able to distinguish between function call and object's method call.
>>14
>why?
Because I think that code should be consistent and predictable. If you see something like this:
(define Foo
(class ()
(slots (cons (self arg) (display arg) (newline)))))
(cons (new Foo) 1)
what do you expect to get?
I expect to get a pair: (#<object> . 1)
If using cons will print something ang return #<undefined> intead of usual pair, I will be very surprised.
That's true, there is the name clashing issue. A function name should either represent a function with a single implementation, or a virtual function with various implementations. It doesn't make any sense if you try to have both for the same function name.
Although you could say that the Foo implementation of cons is more specific than the generic cons, and that it overrides it. But in order for that to work, you have to treat all functions as methods. I can't think of an easy way to give that to scheme without making a new dialect.
Name:
Anonymous2012-06-17 7:10
>>16
Yes, but design should prevent it whenever possible. >>17
>But in order for that to work, you have to treat all functions as methods. I can't think of an easy way to give that to scheme without making a new dialect.
It is easy to implement function call so it would look for object's method first, but it anyway violates the principle of least astonishment.
I'm still interested in /prog/'s opinion about my suggested syntax of module/object usage, ie:
(: modules ... function args ...)
;and
(: class/object method args ...)
Name:
Anonymous2012-06-17 13:58
so how'd you guys feel about a scheme with a static type system?
I revised my dialect and decided to add new datatype: selectors. They are similar to Erlang's atoms, meaning that they evaluate to themselves and they can't store any value. Selectors can be used in function call: (define (foo bar baz) ...)
(foo baz: baz-value bar: bar-value)
in macros: (define-syntax my-if
((my-if expr1 then: expr2 else: expr3)
(if expr1 expr2 expr3)))
or everywhere else where you would usually use quoted symbol.
OOP was also revised. Now to call object's or class' method you just write: (object method args ...)
without any annoying colon. Initially I wanted to use the same form, but with quoted method. Now I can see that the first argument(method name) just shouldn't be evaluated.
If you used (object 'method-name-literal args ...) instead, then you could have a variable represent a method name, and there would be more purity and flexibility in the object. IE, it can be considered as just another closure. Consider calling the following on a vector of objects of the same type:
So now say you have a vector of objects that implements some interface, IExample, and then you apply vectorize-fns to this vector and store the result in B. B will be an object that implements each method in IExample, but the return value of each method with be vectored.
Name:
Anonymous2012-06-20 0:40
>>27
Damn, I completely forgot about functional part while thinking about OOP implementation. Yes, it is better to evaluate method name for more flexibility and consistency at the same time.
But the quote in this place still annoys me. May it be better to replace quoted symbol with self-evaluating atom?
>>28
impossible even using macros since you don't know whether something will be an object. you could define! all those symbols to be equal to their own name, but that's going to bite you in the ass quick enough. just do multimethods, dude, and only store fields in objects.
Name:
Anonymous2012-06-20 4:14
>>28
yeah, for reasons >>29-san described, you can't do it. You could if you went back to the (: object method-name ...) syntax and made : a macro, but that was fugly as fuck.
Name:
Anonymous2012-06-20 4:30
>>29 >>30
I don't get it. What exactly impossible?
>>32
Meh. It will be possible if I make it possible in my interpreter.
But what I meant by "self-evaluating atom" was not quoted symbol, but _atom_ which I described here: >>25
I mean I am going to make method call look like either: (window 'add-button button)
where method is accessed via symbol, or (window add-button: button)
where method is accessed via selector(atom).
I understand that the difference is barely notable, but I hope you know how even tiniest design flaw can make programming awful.