[e-lang] Couple of newbie questions

[Chris Rathman]

Chapter one doesn't get too involved, but I can usually get a decent 
feel for the underlying design in a language.  On the whole, E was 
rather easy to translate.

On the negative side (some of which may just be due to my newbie status):

1).  Wrapper functions for math methods:  The documentation gives the 
math functions as object methods.  And this is probably a good thing 
given that most uses will be of that form.  For example, the sine 
function would be invoked like:

          0.5.sin()

which from an OO perspective is impressive.  But I couldn't figure out 
how to do this from an FP perspective short of wrapping it in a function 
(def _(x) { x.siu() }).  Is there a way to use the methods as a function 
parameters short of wrapping them in a function?  Not a big deal, but 
since it's fresh on my mind...

2).  TCO:  I don't know if the lack of tail call optimization is only in 
the Java implementation (I didn't try the Lisp version), but most FPers 
would likely complain about a lack of TCO.

3).  Rune question:  I couldn't figure out how to load a file from 
within the interpreter (opting to call Rune with the file as a 
parameter).  Is there a "using" or "load" type command that can be 
issued from the interactive environment?

On the positive side:

1).  Function/Expression Consistency:  Many languages make a distinction 
between procedural constructs and expressions.  The tell-tale is usually 
the if-then-else construct - and whether it can be used in an 
expression.  E has the flavor of Scheme and ML (good company on the FP 
side).  E doesn't make an arbitrary distinction between anonymous 
functions and normal functions.  And other than the TCO mentioned above, 
writing in an FP style comes quite natural to the language.

2).  Using Let:  I couldn't see where E had a Let construct, but the 
lexical scoping and blocks {} are a cinch to work with.  Section 1.3.2 
is a fairly trivial example to demonstrate scoping in Scheme, but it is 
one of the harder ones I've found to express concisely among the 
languages that don't have a let construct.  Mostly owing to #1 on 
consistency, I had no problems with it in E.

3).  No surprises along the way:  The SICP translation is not so much 
about which language is best.  The book was written with Scheme in mind, 
so Scheme likely comes out on top - much as Oz is the best language for 
CTM.  I do believe that the ideas of SICP transcend any particular 
language (at least the first three chapters).  From an E standpoint, the 
ideas of chapter 1 can be expressed without any undue surprises - a 
definite passing grade.  Not something that's going to sway one way or 
the other in terms of language choice, but a certain elegance is always 
good to have in the core of a language.

Chapter two of SICP is where the material gets a bit more interesting 
(at least from my perspective).  I haven't looked at E's Lists just yet 
- (I'm hoping they lean towards the lists of Scheme, ML, Oz and Erlang - 
mostly because it makes the translation easier).

As for the difference in whether to explicitly print expressions, or 
whether to just give the expressions - this is completely arbitrary on 
my part.  Alice ML is the language I've spent the most time on.  Being 
statically typed, I didn't want to have convert everything to strings to 
display them (clutter).  The original Scheme code doesn't use print, so 
in that sense the ML code is truer to the original.  Oz was the second 
language I took on and it looked slightly odd to have a _= in front of 
all the expressions (which is what I did in Haskell), so I added a 
Browse (Oz's equivalent of print).  Anyhow, there has been some 
translation drift along the way, and the use of print is symptomic of 
that drift (the E translation may look a bit Pythonish).  The E code 
could be expressed comfortably either way (which I guess is another plus 
for the language).

Thanks,
Chris Rathman


Mark S. Miller wrote:
> Chris Rathman wrote:
>   
>> SICP in E link:
>> http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages#E
>>     
>
> Wow Chris, that's great! And quite a lot of work! I've added a link to it from 
> our wiki. (The link is currently on the main page but will probably get moved.)
>
> So now that you've done this much, I'm wondering. How well did E do? Did 
> anything stand out as surprisingly pleasant or annoying? Are there any 
> particular lessons you think E should learn from some of the other languages 
> there? Thanks.
>
> Btw, I'm curious why the examples for some languages, like Alice or OCaml, 
> just show expressions, while others, like E and Python, explicitly ask that 
> the values of the expressions be printed?
>
>