Partial Euphoric Type Checking

[T. Onoma]

Greetings all Type Checkers!

I have implemented a version of euphoria's type system in Ruby.

# the good stuff

module Kernel
def typechecking(x=nil)
return $_tc if x == nil
$_tc = x ? true : false
end
end

class Module
def type(tname, &check)
define_method(tname) do |*v|
if $_tc
unless v.all? { |y| check.call(y) }
raise TypeError
end
end
return *v
end
end
end

# demonstrate how it feels

class TypeTest
type :big4 do |x|
x > 4
end
def ameth(x)
# -- type checking --
big4 x
# -- rest of code --
puts x
end
end

typechecking true # turn type checking on
t = TypeTest.new
t.ameth(5) # => 5
t.ameth(2) # => TypeError

Now if you can just get matz to add a little sytax sugar for type and inline parameter methods:

class TypeTest
type big4(x)
x > 4
end
def ameth(big4 x)
puts x
end
end

would that quell the need?

-t0

 

[Sean O'Dell]

Greetings all Type Checkers!

I have implemented a version of euphoria's type system in Ruby.

# the good stuff

module Kernel
def typechecking(x=nil)
return $_tc if x == nil
$_tc = x ? true : false
end
end

class Module
def type(tname, &check)
define_method(tname) do |*v|
if $_tc
unless v.all? { |y| check.call(y) }
raise TypeError
end
end
return *v
end
end
end

# demonstrate how it feels

class TypeTest
type :big4 do |x|
x > 4
end
def ameth(x)
# -- type checking --
big4 x
# -- rest of code --
puts x
end
end

typechecking true # turn type checking on
t = TypeTest.new
t.ameth(5) # => 5
t.ameth(2) # => TypeError

Now if you can just get matz to add a little sytax sugar for type and
inline parameter methods:

class TypeTest
type big4(x)
x > 4
end
def ameth(big4 x)
puts x
end
end

would that quell the need?

In some ways, but it's written in Ruby, and it doesn't look like it can check
available object methods without slipping in Ruby code to do so. It falls
under the category of "third-party kludge" because it's doing a job that most
people assume the language implementation itself would provide. I can't
imagine this would be terribly efficient, either.

Sean O'Dell

 

[Phil Tomson]

Greetings all Type Checkers!

I have implemented a version of euphoria's type system in Ruby.

# the good stuff

module Kernel
def typechecking(x=nil)
return $_tc if x == nil
$_tc = x ? true : false
end
end

class Module
def type(tname, &check)
define_method(tname) do |*v|
if $_tc
unless v.all? { |y| check.call(y) }
raise TypeError
end
end
return *v
end
end
end

# demonstrate how it feels

class TypeTest
type :big4 do |x|
x > 4
end
def ameth(x)
# -- type checking --
big4 x
# -- rest of code --
puts x
end
end

typechecking true # turn type checking on
t = TypeTest.new
t.ameth(5) # => 5
t.ameth(2) # => TypeError

Now if you can just get matz to add a little sytax sugar for type and
inline parameter methods:

Why does Matz need to add any sugar? You show how it can be done above.
Sure, it would make what you're trying to do look a little nicer, but why
don't you just release your code above as a module on the RAA and document
it nicely and then people can use it if they wish (and not use it if they wish).

class TypeTest
type big4(x)
x > 4
end
def ameth(big4 x)
puts x
end
end

would that quell the need?

It's got it's uses but I wouldn't hold my breath for any sugar ;-)

Phil

 

[T. Onoma]

quack! quack! I added duck typing capability to my euphoric type checking
system:

module Kernel
def typechecking(x=nil)
return $_tc if x == nil
$_tc = x ? true : false
end
end

class Module
def type(tname, *resp, &check)
define_method(tname) do |*v|
if $_tc
unless v.all? { |y| resp.all? { |z| y.sendrespond_to?, z) } }
raise TypeError, "#{v}"
end
unless v.all? { |y| check.call(y) }
raise TypeError, "#{v}"
end
end
return *v
end
end
end

Probabably could be written a little more concise. now example:

type :big4, '>', 'to_i', 'succ' do |x|
x > 4
end

def ameth(x)
big4 x
#---
puts x
end

big4 will make sure parameter responds to #> #to_i and #succ and is also
greater than 4.

i also have a some better ideas for sugar too:

class TypeTest

type big4(x)
'>', 'to_i', 'succ'
unless
x > 4
end

def ameth(big4 x)
puts x
end

end

getting better? we may have other clauses besides 'unless' too (?) seems like
i'm starting to converge on Sean's idea from another angle. except mine is
dynamic runtime, but it can be turned offf globally or locally.

BUT!!!!!!!!!!! i have discovered a problem with all type systems! see next
post....(or 2)

-t0

 

[T. Onoma]

Now some for some rally crazy cross thought. First a complete interface
definition substantiated on an existent class.

type :IOInteface, *(IO.methods &
IO.private_methods &
IO.protected_methods)

def ameth(x)
IOInterface x
#---
x.read
end

now Lets use theoretical duck_signs with euphoria. will we be happy quackers?

type :big4, '>', 'to_i', 'succ' do |x|
x > 4
end

def ameth(x)
big4 x
#---
puts x.succ
end

methodameth).duck_signature # => [ [ 'succ' ] ]
methodbig4).duck_signature # => Holy Quack'n Ducks, Batman!

Consider:

def type(tname, *resp, &check)
define_method(tname) do |*v|
        if $_tc
          unless v.all? { |y| resp.all? { |z| y.sendrespond_to?, z) } }
            raise TypeError, "#{v}"
          end
          unless v.all? { |y| check.call(y) }
            raise TypeError, "#{v}"
          end
        end
        return *v
      end
end

can it be done?
1) infinite arity? hmm...have to be considered parameter of array?
2) conditioned (on global) how to signify signiture is conditional?
3) respond_to('all?') No, not *really* array try |y|?
4) y.send, of course, but means y.respond_to?, of course, but means y.z?
5) so... '>', 'to_i', 'succ', i guess?

my head hurts i fear godel will soon appear and slap my bitch funny.

BUT wait! There is an even simplier problem!!!!!......(see next post)

-t0

 

[T. Onoma]

for some cross rally some thought crazy. ( read: i need a type system for my
email! )

Oh, before i introduce you to a very bad duck, check out the very good duck at
_whyTheLuckyStiff's home page: http://whytheluckystiff.net/. It's awesome!

Okay, now the bad duck. Consider this example of my euphoric type system:

class TypeTest

type big4, '>', 'to_i', 'succ')

def ameth(x)
big4 x
#---
x > 4
end

end

typechecking true

t = TypeTest.new

t.ameth(5) # => 5 good
t.ameth(4) # => 'big4' : 4 (TypeError) good
t.ameth('5') # => `>': comparison of String with 4 failed (ArgumentError)

bad duck!

you see we have a problem here. it doesn't matter what methods are
implemented, because '>' for a String and '>' for a Numeric don't DO
the same KIND OF thing. the operators are overloaded. so respond_to? isn't
enough. we end up having to think about what will be passed to those
responding methods as well -- we end up having to ask not only, can you
handle the responsibilities? but can you handle the arguments? (sounds like a
thread i know

this problem not only effects my system, by Sean's as well, which by the way
are not so distinct. we can of course say that it's GOOD ENOUGH, but some
might say, that's just quackery. (can you guezz who?)

so while there are good ducks, like _whys, their are also not-so-good ducks.
and ducks in general are not always what their "quacked" up to be, just like
that kind_of? beast.

-t0

 

[Chris Morris]

you see we have a problem here. it doesn't matter what methods are

implemented, because '>' for a String and '>' for a Numeric don't DO
the same KIND OF thing. the operators are overloaded. so respond_to? isn't
enough. we end up having to think about what will be passed to those
responding methods as well -- we end up having to ask not only, can you
handle the responsibilities? but can you handle the arguments? (sounds like a
thread i know

So we'd like the code we write to tell us when we've screwed up, but a typing system is basically not smart enough, because type alone does not determine functionality.

I guess we're back to unit testing.

Or am I over-simplifying?