Skip to content
This repository has been archived by the owner on May 27, 2020. It is now read-only.

Feedback

Jump to bottom
lfairy edited this page Jun 26, 2012 · 1 revision

Hello there!

I am writing a game based on your λ-calculus visualization as a school project (https://github.com/lfairy/sylvia/wiki/Project-brief). It's part of an new technology class our school is trying out, where we focus on the design process -- research, planning, feedback -- rather than the thing we're building. Part of this is getting input from people who know more than I am, which is what I'm doing now :)

I'm using your idea because it looks much better than the other ones I've seen. Other visualizations either require lots of alpha-conversion (their use of colors give them away) or have complicated non-intuitive rules.

At the moment, I am working on how to render it -- or as your paper says, making the layout rules explicit. I already have a de Bruijn index structure and a parser to build on, so I can focus on how to draw it. I have some ideas at https://github.com/lfairy/sylvia/wiki/Rendering:-Analysis -- as you can see, I'm far from getting the whole thing. Maybe you can suggest another approach?

I would be great if you could provide feedback on what I've done so far. I haven't spread it much, mostly since there's nothing to show for it, so hearing someone who isn't involved in the project would be great.

Thank you

Hi Chris,

Call me Dave.

Great to hear about your project. I'm glad you like my visualisation. But I'm not so sure I know more about it than you. :-) The last time I programmed in Haskell (or any functional language) was for a university assignment as a student in the early 1990's. I think it must have been Haskel 1.0. And of course I wrote the Mockingbird paper 16 years ago.

The software I write these days is C and assembly language for embedded systems. So I'm used to thinking procedurally and not functionally these days. But I'd be happy to help you in any way I can.

I've looked over your web pages and I've looked at your code. I would have to do a Haskell refresher before I could really understand it. Using De Bruijn indexes seems like a good way to go. It seems like it should be useful in rendering.

Here are some aesthetic layout rules and suggestions:

  1. Corners of boxes and lines and centers of ears, throats and applicators are on a grid that is spaced twice as wide horizontally as it is vertically. The diameter of the ears, throats and applicators should be one vertical grid unit. e.g. the graphics in the paper are on a grid that is spaced 9 pixels vertically and 18 pixels horizontally. The ears, throats and applicators in the paper are 10 pixels in diameter, but they probably should have been 9 pixels.
  2. The ear and throat of the same abstraction are at the same height.
  3. A rhyme section occupies one grid unit horizontally
  4. A rhythm section that contains no abstractions (only applicators) is N+1 units wide where N is the number of applicators.

I suggest first just working on rendering the single layer abstractions I and w. Then work on rendering the innermost abstraction of the simply-nested abstractions: K KI I* T Kw C(Kw) L O W CW U C B S J. You would presumably calculate in local coordinates (e.g. relative to the ear, in grid units) the position of each rhyme point and each applicator, and the throat, and the top and bottom of the box.The rhyme-points will always have a horizontal coordinate of 1.

Then you would work on rendering the whole of the simply-nested abstractions listed above. To do those, you will presumably work from the innermost abstraction outwards. Only after calculating the size of the inner abstraction (the position of its throat and the top and bottom of its box) can you calculate the position of the enclosing abstraction's throat and its top and bottom. The position of the inner abstraction (i.e. the location of the inner abstraction's ear relative to the enclosing abstraction's ear will be 1 unit horizontally and 1 unit down.

As you mention on your web page, Theta (UU) and Y (figures 22 and 23) are more tricky. To get to applicators or abstractions to the left of the rightmost enclosed abstraction, the lines need to do detours around the rightmost abstraction. I hope it will become clearer how to handle these after you've done the simpler ones.

-- Dave

Clone this wiki locally