[e-lang] Couple of newbie questions

[Chris Rathman]

Mark S. Miller wrote:
> The following probably doesn't stay close enough to the original to suit your 
> purpose, but none of your implementations of rational numbers on that page 
> seem object-oriented to me. Here's a sketch of how one might actually do 
> rational objects in E.
>   

Well, one of the common criticisms leveled against SICP is that it
doesn't cover object-oriented programming well enough.  :-)

The translation does try to balance being faithful to both the book and
the target language.  I got ahead of the material at this point in the
book.  When I was translating the ML, I was wanting to have a minor
foray into modules to show how to group related functions.  From an E
standpoint, I was wanting to show how to group functions together - the
grouping is more akin to static class methods, such that the
state/values are not encapsulated.   I probably should show another
alternative translation of rationals that's a bit closer to
object-oriented, but maintain a progression from the literal translation.

That said, the kind of solution you give here is more in spirit with
sections 2.4 which deals with modules and section 2.5 which deals with
something akin to object polymorphism and type coercion.  The rational
class you provided will come in handy when I get to that point - though
SICP shifts to Imaginary numbers as the example in 2.4 and 2.5.

> -----------------------------
> #!/usr/bin/env rune
>
> # Copyright 2006 Hewlett Packard, under the terms of the MIT X license
> # found at http://www.opensource.org/licenses/mit-license.html ...............
>
> # Based on Chris Ratham's makeRational2 at
> # 
> http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages:E:Chapter_2
> # which reduces "to lowest terms in constructor"
>
> pragma.syntax("0.9")

Though I could afford to spend some quality time with the E
documentation....

What is the effect of leaving out the pragma.syntax instruction?  From
glancing at the documentation, it seems to come highly recommended -
indicating that some of the examples won't run.  Is the default not the
latest version?

> Shouldn't the first return in your
>
>      def list(xs) {
>         if (xs.size() == 0) {
>            return [nil]
>         } else if (xs.size() == 1) {
>            return cons(xs[0], nil)
>         } else {
>            return cons(xs[0], list(xs(1)))
>         }
>      }
> be
>            return nil
>   

The way that I encoded the scheme type lists is to have the value 'nil'
in the base position of the chain.  Borrowing Oz's list tuple notation
and then extrapolating to the way it get's encoded into E, I have
something like:

nil => [nil]
3|nil => [3, nil]
2|3|nil => [2, [3, nil]]
1|2|3|nil => [1, [2, [3, nil]]]

...and so on.  So in the base position, there is the 'nil' value (which
is an arbitrary value that I encoded as string  only because it's a  bit
easier on the eyes when printing a list - I originally used a function
for nil).

I should probably rewrite the list functions using an object to hold the
various methods.  I took the simplistic approach for now - mainly just
to concentrate on the usage rather than the implementation details.
There are some issues that I still need to work out, but the list
functions do seem to work for all the examples thus far.  Chapter 3 gets
into mutable lists, and I'll probably refine the representation at that
point.


> Shouldn't the first test in your
>
>      def islist(xs) {
>         try {
>            if (xs[1] == nil) {
>               return true
>            } else {
>               return islist(cdr(xs))
>            }
>         } catch err {
>            return false
>         }
>      }
> be
>            if (xs == nil) {
> ?
>
>   

Yep, I left out that case.  The islist function is only used in the Tree
examples of the translation, and there wasn't an example that used an
empty tree - so I missed that one.

I did consider posting a question about this function.  I'm not
particularly satisfied with this implementation, as it's inefficient for
two reasons.  First, it always has to recurse down the list to find out
if the value nil is in the base.  And second, it will generate an
exception for the leaves (they are integers).  Both could be solved by
going to an OO encoding of lists.  But I was also meaning to ask if
there's a method that is available to determine the type of variable?
Something along the lines of:

    if (!xs.isArray()) return false

In the tree examples, the input is either a list or an integer, so when
I hit the leaves it generates an exception - not likely to be efficient.


Thanks,
Chris Rathman