Beyond ASCII only editors for Haskell
Hi One of Haskell's advantages is that it is very suitable as an executable specification language. Which is also claimed on http://www.haskell.org/aboutHaskell.html: "Much of a software product's life is spent in specification, design and maintenance, and not in programming. Functional languages are superb for writing specifications which can actually be executed (and hence tested and debugged). Such a specification then is the first prototype of the final program." also on the same page: "Haskell, a purely functional programming language, offers you: ... * A smaller "semantic gap" between the programmer and the language. " But if I were to specify a program (in a non-executable language) or if I were to write some function on a blackboard, I would not be restricted to only ASCII characters. For example, I would not write 'sqrt 2' but I would write a square root symbol with 2 underneath. Likewise, I would not write '2 ^ 5', but I would write a 2 with a 5 raised upwards to the right of the 2. Then why are we stuck with the mono-spatial ASCII based editors in Haskell? Why is it not possible to make Haskell program look similar to ordinary math? (also when writing those programs and not just afterward in some Latex formatted paper). Also, programmers often use diagrams as specification. As Andrew Bromage says it in http://haskell.org/~shae/pseudocode1.pdf: "Mostly, I strongly suspect that most code of this type is not written, but rather it's translated into. I tend to see many uses of "point-free style" in the same light. It's also one of the reasons why I've resisted using arrows: You don't program in arrow style; you program in diagrams on paper, then translate that into arrow style." This makes me think that our diagrams should be compilable and thus executable? These diagrams could be embedded in our editor and intermixed with ordinary code. I have looked for the type of editor roughly outlined above, but found nothing. If anybody have some links to projects, which is related to these kind of thoughts please let yourself be heard. Also, of cause, comments are most welcome. -- Mads Lindstrøm <mads_lindstroem@yahoo.dk>
Mads Lindstrøm wrote:
But if I were to specify a program (in a non-executable language) or if I were to write some function on a blackboard, I would not be restricted to only ASCII characters. For example, I would not write 'sqrt 2' but I would write a square root symbol with 2 underneath. Likewise, I would not write '2 ^ 5', but I would write a 2 with a 5 raised upwards to the right of the 2. Then why are we stuck with the mono-spatial ASCII based editors in Haskell? Why is it not possible to make Haskell program look similar to ordinary math? (also when writing those programs and not just afterward in some Latex formatted paper).
While the idea is intriguing, it has actually been done. Look up APL as a language. Once, there were special terminals, able to enter APL-specific symbols only used in APL. You might be lucky your local computer museum has one (I cannot frankly remember if they have one in Denmark). ASCII has the advantage of being de-facto. UTF-8 might change that, as might XML, but I am not sure if this is an advantage at all. Apart from mathematical conciseness and reabability, nothing is gained by the change. On the contrary, you have limited yourself to a small number of editors which are able to read your program, unless you translate down to an ASCII variant. I do not think one can learn from APL. The world is much changed today. However, programming in diagrams and the like sounds awfully like CASE-tools of the start of the nineties - which did not prevail either. It might be the world is ready for another attempt with XML+UTF-8 though.
Jesper Louis Andersen wrote:
Mads Lindstrøm wrote:
But if I were to specify a program (in a non-executable language) or if I were to write some function on a blackboard, I would not be restricted to only ASCII characters. For example, I would not write 'sqrt 2' but I would write a square root symbol with 2 underneath. Likewise, I would not write '2 ^ 5', but I would write a 2 with a 5 raised upwards to the right of the 2. Then why are we stuck with the mono-spatial ASCII based editors in Haskell? Why is it not possible to make Haskell program look similar to ordinary math? (also when writing those programs and not just afterward in some Latex formatted paper).
While the idea is intriguing, it has actually been done. Look up APL as a language. Once, there were special terminals, able to enter APL-specific symbols only used in APL. You might be lucky your local computer museum has one (I cannot frankly remember if they have one in Denmark).
Newer heard of these terminals before, but they do sound interesting. Atleast for historical reasons. But, it is less important how easy it is to write code than how easy it is to read it, as code will be read 10 times more than writen. If you think this is untrue, think about how many times you have already read you own code before anybody else gets to see it. For example, you make funciton X and a little later you make function Y which uses X. Now it is not unlikely that you go read function X again to see what it actually did. And when you make the next function you might look at X and Y again. And so on... My point is that we should not to care so much about how fast we can write the code (with speciel kind of terminals or otherwise), but how easy it is to read.
ASCII has the advantage of being de-facto. UTF-8 might change that, as might XML, but I am not sure if this is an advantage at all. Apart from mathematical conciseness and reabability, nothing is gained by the change. On the contrary, you have limited yourself to a small number of editors which are able to read your program, unless you translate down to an ASCII variant.
Conciseness and readability is very important, as it affects how fast you can comprehend others or you own source code. But we do not have to leave out ASCII based editors - atleast to begin with. You can be showing functions like sqrt using real math symbol and at the same time store your documents as ordinary Haskell sources, which can be read by any editor. This would of cause require the editor to have a faily big understanding of the Haskell language. And it can only go so far, some math stuff will require richer formats that cannot be translated nicely to ordinary Haskell sources.
I do not think one can learn from APL. The world is much changed today. However, programming in diagrams and the like sounds awfully like CASE-tools of the start of the nineties - which did not prevail either.
It might be the world is ready for another attempt with XML+UTF-8 though.
-- Mads Lindstrøm <mads_lindstroem@yahoo.dk>
Mads Lindstrøm <mads_lindstroem@yahoo.dk> writes:
But we do not have to leave out ASCII based editors - atleast to begin with. You can be showing functions like sqrt using real math symbol and at the same time store your documents as ordinary Haskell sources, which can be read by any editor. This would of cause require the editor to have a faily big understanding of the Haskell language. And it can only go so far, some math stuff will require richer formats that cannot be translated nicely to ordinary Haskell sources.
This has been done, Luke Gorrie wrote pretty-lambda.el: http://www.emacswiki.org/cgi-bin/wiki/PrettyLambda Jorge Adriano did something similar for Haskell with x-symbol: http://www.haskell.org/pipermail/haskell-cafe/2002-August/003237.html Pugs is doing this directly: http://use.perl.org/~autrijus/journal/24762 For more exciting possibilities, the plan for the Yi editor is to have parser-based modes. That would allow you to do much more than what's mentioned above. -- It seems I've been living two lives. One life is a self-employed web developer In the other life, I'm shapr, functional programmer. | www.ScannedInAvian.com One of these lives has futures (and subcontinuations!)| --Shae Matijs Erisson
Jorge Adriano did something similar for Haskell with x-symbol: http://www.haskell.org/pipermail/haskell-cafe/2002-August/003237.html
Note that the latest haskell-mode has support for something similar (tho it works differently). But these are minor cosmetic tricks. Stefan
On Sunday 22 May 2005 22:35, Shae Matijs Erisson wrote:
Mads Lindstrøm <mads_lindstroem@yahoo.dk> writes:
But we do not have to leave out ASCII based editors - atleast to begin with. You can be showing functions like sqrt using real math symbol and at the same time store your documents as ordinary Haskell sources, which can be read by any editor. This would of cause require the editor to have a faily big understanding of the Haskell language. And it can only go so far, some math stuff will require richer formats that cannot be translated nicely to ordinary Haskell sources.
This has been done, Luke Gorrie wrote pretty-lambda.el: http://www.emacswiki.org/cgi-bin/wiki/PrettyLambda
Jorge Adriano did something similar for Haskell with x-symbol: http://www.haskell.org/pipermail/haskell-cafe/2002-August/003237.html
Pugs is doing this directly: http://use.perl.org/~autrijus/journal/24762
For more exciting possibilities, the plan for the Yi editor is to have parser-based modes. That would allow you to do much more than what's mentioned above.
Sébastien Carlier also made an preprocessor for Haskell code using UTF-8 mathematical symbols: http://www.macs.hw.ac.uk/~sebc/unicode/ Cheers, Jérémy.
Mads Lindstrøm <mads_lindstroem@yahoo.dk> writes:
But we do not have to leave out ASCII based editors - atleast to begin with. You can be showing functions like sqrt using real math symbol and at the same time store your documents as ordinary Haskell sources, which can be read by any editor. This would of cause require the editor to have a faily big understanding of the Haskell language.
A related option is to use LaTeX style literate Haskell, and use a LaTeX class that can pretty-print the code using non-standard glyphs. (I've toyed a bit with this, without being entirely satisfied by the results. Send me a mail if you want the details.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants
to only ASCII characters. For example, I would not write 'sqrt 2' but I would write a square root symbol with 2 underneath. Likewise, I would not write '2 ^ 5', but I would write a 2 with a 5 raised upwards to the right of the 2. ...
Remember Paul Halmos' advice (from "I Want To Be A Mathematician"): if you use (or dare to invent) "tricky" notation, imagine you had to read the formula to someone over the phone. Then you need to *name* and *pronounce* things, not just *write* them. This also enforces a natural linear order on the representation, much like the sequence of characters in a file. On the other hand, most editors will represent it two-dimensionally, but it's not clear whether hard-wiring 2D into a language definition solves more problems than it creates. (So the Haskell designers were cautious and allowed to bypass the layout convention.) With a few examples (sin, cos, log, ...), Mathematics has gone a long way to avoid multi-letter identifiers. Since there are only a few latin letters, it resorts to graphical (examples above) and calli-graphical resolutions (other fonts, boldface, italics, superscripts, subscripts etc. I think the \sqrt sign is in fact an "r" = first letter of "radix" = root) From an "engineering" standpoint (readability, maintenance), this sometimes is questionable. See any software engineering textbook, section "choose sensible names for identifiers". By sticking to plain ASCII, we enforce longer (and hopefully more meaningful) names :-) BTW, the Haskell standard itself does feature some unnecessary cleverness: abridged names like Bool, fst, snd just don't feel right. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Johannes Waldmann wrote:
to only ASCII characters. For example, I would not write 'sqrt 2' but I would write a square root symbol with 2 underneath. Likewise, I would not write '2 ^ 5', but I would write a 2 with a 5 raised upwards to the right of the 2. ...
Remember Paul Halmos' advice (from "I Want To Be A Mathematician"): if you use (or dare to invent) "tricky" notation, imagine you had to read the formula to someone over the phone. Then you need to *name* and *pronounce* things, not just *write* them.
This also enforces a natural linear order on the representation, much like the sequence of characters in a file. On the other hand, most editors will represent it two-dimensionally, but it's not clear whether hard-wiring 2D into a language definition solves more problems than it creates. (So the Haskell designers were cautious and allowed to bypass the layout convention.)
It seems to me that the layout conventions work pretty well. I do not see much code where it is not used, so generally people must like it. And I personally, have newer experienced being confused about the block structure in Haskell. If this is just me or is general among people I cannot say. Also, there is a more theoretical argument why the C/C++/Java/... way of using '{', '}', and ';' is bad. Basically, your are defining your structure in two different ways. Namely, using indentation and using the '{', '}', and ';'. Two ways leaves room for inconsistency. And this inconsistency is unnecessary, as the compiler can and do deduce the block structure from the indentation. Compare this to both defining a function and commenting it. Here there is also room for inconsistency. But there is no way around it, as the compiler cannot deduce what your comment means and people need comments to understand the code.
With a few examples (sin, cos, log, ...), Mathematics has gone a long way to avoid multi-letter identifiers. Since there are only a few latin letters, it resorts to graphical (examples above) and calli-graphical resolutions (other fonts, boldface, italics, superscripts, subscripts etc. I think the \sqrt sign is in fact an "r" = first letter of "radix" = root)
From an "engineering" standpoint (readability, maintenance), this sometimes is questionable. See any software engineering textbook, section "choose sensible names for identifiers". By sticking to plain ASCII, we enforce longer (and hopefully more meaningful) names :-)
BTW, the Haskell standard itself does feature some unnecessary cleverness: abridged names like Bool, fst, snd just don't feel right.
As you also write, not all Haskell names are long and meaningful. Just look at (!!), ($), (.). And yes I do not like the fst and snd either. However, what I was trying to suggest was not to invent some completely new notation, but to use the most common math notation like square root. People already know this symbol, so no new symbols needs to be learned. What I also had in mind was things like case expressions and indexing. I think there are more people familiar with the subscript indexing than with the (!!). But how far do you want to take you long and meaningful names? Do you not also want some of the math symbol, like /, -, and + ? Or do you want to rename them divide, subtract, and add? As I see it, it is basically a balance between conciseness, intuitiveness, convention (and how know this convention is), and how often a particular function are used. The reason for turning to math symbols is that more people know math than any programming language out there. Also math is very concise. However, often not intuitive. This also means that I do think we should invent some symbols. Like the (->) used in function signatures. And we can live with the new notation, even though it is not intuitive, as it is used very, very often. On the other hand, I do not want to completely adopt math. The one letter disease is one thing I would not adopt and it is only tolerable in math, because math deals with problems of small scope. Whereas programming deals with problems of a much larger scope. As a side note, I think (but I am not sure) sticking to one letter comes from the implicit multiplier. If we are using a math function named 'sin', nobody can know if we are meaning s*i*n or are referring to the function 'sin'. So what we need to do is find the right balance (see two sections above). I do not know what the right balance is, but debating it here probably gives everybody involved a better idea. And I do think we could invent some kind of "framework", consisting of questions to be answered, that could help decide which symbols to use and which not to use. -- Mads Lindstrøm <mads_lindstroem@yahoo.dk>
On Monday 23 May 2005 22:48, Mads Lindstrøm wrote:
It seems to me that the layout conventions work pretty well. I do not see much code where it is not used, so generally people must like it.
Please forgive me for taking this as an opportunity to rant about the single misfeature of Haskell's layout syntax, which is how if/then/else must be layed out. The problem is that the 'else' must be indented further than the 'if', so that this: if cond then on_true else on_false usually gives me a syntax error. Other than this, I like layout so much that I have never actually used the explicit {;}-notation. Ben
Benjamin Franksen <benjamin.franksen@bessy.de> writes:
It seems to me that the layout conventions work pretty well. I do not see much code where it is not used, so generally people must like it.
Works for me. It helps *a lot* to have a sensible editor that knows where to position things of course. I use Emacs, but should probably upgrade the mode, as it doesn't place 'let' in do-blocks correctly.
Please forgive me for taking this as an opportunity to rant about the single misfeature of Haskell's layout syntax, which is how if/then/else must be layed out. The problem is that the 'else' must be indented further than the 'if', so that this:
You're talking about monads and do-notation here? I have no problems with this in pure code. I tend to find 'when' is more useful for monadic code, but yes, positioning ifs and cases can be a bit painful.
Other than this, I like layout so much that I have never actually used the explicit {;}-notation.
I sometimes use it for compactness: ... case x of {1 -> foo; 2 -> bar; _ -> error "too much"} And with ghci. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
On Tuesday 24 May 2005 11:26, you wrote:
Benjamin Franksen <benjamin.franksen@bessy.de> writes:
It seems to me that the layout conventions work pretty well. I do not see much code where it is not used, so generally people must like it.
Works for me. It helps *a lot* to have a sensible editor that knows where to position things of course. I use Emacs, but should probably upgrade the mode, as it doesn't place 'let' in do-blocks correctly.
Please forgive me for taking this as an opportunity to rant about the single misfeature of Haskell's layout syntax, which is how if/then/else must be layed out. The problem is that the 'else' must be indented further than the 'if', so that this:
You're talking about monads and do-notation here? I have no problems with this in pure code.
Hmm. You are right. This only gives a syntax error inside a 'do...' block. And now as I think about why this is the case, I can't see a good way to fix it, other than giving if/then/else-completion a higher precedence than layout. Hmmmm. Ben
On May 24, 2005, at 5:45 AM, Benjamin Franksen wrote:
On Tuesday 24 May 2005 11:26, you wrote:
Benjamin Franksen <benjamin.franksen@bessy.de> writes:
Please forgive me for taking this as an opportunity to rant about the single misfeature of Haskell's layout syntax, which is how if/then/else must be layed out. The problem is that the 'else' must be indented further than the 'if', so that this:
You're talking about monads and do-notation here? I have no problems with this in pure code.
Hmm. You are right. This only gives a syntax error inside a 'do...' block. And now as I think about why this is the case, I can't see a good way to fix it, other than giving if/then/else-completion a higher precedence than layout. Hmmmm.
Arguably this would be the right behavior. The if/then and then/else pairings in effect unambiguously bracket the predicate and alternative respectively, and oughtn't cause a problem with layout. -Jan-Willem Maessen
On 20050524T111249+0200, Benjamin Franksen wrote:
The problem is that the 'else' must be indented further than the 'if', so that this:
if cond then on_true else on_false
usually gives me a syntax error.
I usually write that as if cond then on_true else on_false or, another example, if cond then do on_true_1 on_true_2 else do on_false_1 on_false 2 which looks a little odd looking from a C/Pascal-style perspective but is logical and understandable. -- Antti-Juhani Kaijanaho http://antti-juhani.kaijanaho.info/ Blogi - http://kaijanaho.info/antti-juhani/blog/ Toys - http://www.cc.jyu.fi/yhd/toys/
Benjamin Franksen <benjamin.franksen@bessy.de> writes:
Please forgive me for taking this as an opportunity to rant about the single misfeature of Haskell's layout syntax, which is how if/then/else must be layed out.
For me it's worse that I can't write like this: foo x = do y <- foo x let z = some long line which must be split into two return (y, z) -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
On Tuesday 24 May 2005 18:40, Marcin 'Qrczak' Kowalczyk wrote:
Benjamin Franksen <benjamin.franksen@bessy.de> writes:
Please forgive me for taking this as an opportunity to rant about the single misfeature of Haskell's layout syntax, which is how if/then/else must be layed out.
For me it's worse that I can't write like this:
foo x = do y <- foo x let z = some long line which must be split into two return (y, z)
Yes, that one has bitten me quite often, too. Ben
Jesper Louis Andersen wrote:
I do not think one can learn from APL. The world is much changed today. However, programming in diagrams and the like sounds awfully like CASE-tools of the start of the nineties - which did not prevail either.
I am sorry to say that I newer really tried any of these CASE tools. Therefore, I have no idea why these tools failed. If anybody think they got the answer I would like to hear it. Maybe the reasons for failure are relevant for what I am proposing, maybe they are not. It is true that we do not see CASE-tools being used very much, but we do see tools go beyond ASCII and still be very popular. What I am thinking of is the visuals environment, like those produced by MS. -- Mads Lindstrøm <mads_lindstroem@yahoo.dk>
Mads Lindstrøm wrote:
Jesper Louis Andersen wrote:
I do not think one can learn from APL. The world is much changed today. However, programming in diagrams and the like sounds awfully like CASE-tools of the start of the nineties - which did not prevail either.
I am sorry to say that I newer really tried any of these CASE tools. Therefore, I have no idea why these tools failed. If anybody think they got the answer I would like to hear it. Maybe the reasons for failure are relevant for what I am proposing, maybe they are not.
The CASE tools failed because they were too specialized. The basic premise, or idea, were that one could build a typical bussiness application by drag-n-drop. The tools were quite good at that. You could literally paint Database-relation schemas, GUIs and link them together. The problem were the glue, which was quite weak compared to other programming languages like Java or (especially) Haskell. Because you had to do some coding in order to glue things together. Not much, but you had to. Also, most of the basic logic is not possible to do with painting, how nice that could be for a visually adept person like me. I do not think the tools failed because of what you are proposing. The idea of presenting programs in other forms than ASCII is fine, as long as you do help the programmer and do not introduce unnecessary constraints, irritations or just general clunkiness.
. . .
It is true that we do not see CASE-tools being used very much, but we do see tools go beyond ASCII and still be very popular. What I am thinking of is the visuals environment, like those produced by MS.
You might be interested in looking at work done at Oxford and Chalmers U. on graphical notations for describing hardware architecture, in particular networks of functional units. The interesting thing was that the notation mapped essentially 1-1 onto expressions in an application-specific language built on top of Haskell. One variant, called Lava, was adopted for use by Xylinx (?sp), an FPGA house. At least part of the reason it worked was that the functional units were combinational, which is nicely compatible with a (stateless) pure functional language. In a similar vein, you might look at a heterogeneous simulation system called "Ptolemy"/"Ptolemy II" developed by Prof. Edward Lee at Berkeley. The system supports, among others, simulation models based on Finite-State Automata, Kahn Process Networks and Token Flow Networks (a generalization of dataflow). The user interface is graphical, using drag&drop to populate the functions and dragging to interconnect. I was experimenting with it as a tool for prototyping computations to be performed on massively-parallel networks of functional units, similar to FPGAs. One really interesting fact to come out of the experiments was that the EEs understood immediately what was going on (it looked sort of like circuit and logic diagrams). The difficulty was with the software people, who insisted on viewing the functional units as little stateful processes, so they started suggesting mechanisms for synchronization and communication -- all that complexity. I found myself siding with the EES -- the dataflow model was simple, and design for performance could be based on indicators such as length (latency) versus width (parallelism) of the network. -- Bill Wood bill.wood@acm.org
Mads -- Eons ago, colleagues and I put together a primitive data flow diagram editor and generated functional code for the functions users wired together. One of the things we learned was that people would happily wire together diagrams with state components that could not be translated because they did not represent functions. (Two different data flow paths sharing the same state creates obvious race conditions, but that's what some people wanted to draw.) It was an interesting exercise to build the tool, but I don't think it gave users any great advantage. Perhaps is was a shortcoming of the tool, which was little more than a prototype. However, the informal nature of data flow diagramming at that time seemed to be out of synch with the rigor needed for programming. Good luck with your search -- it may be a good time to try it again. -- Reg
Hi
One of Haskell's advantages is that it is very suitable as an executable specification language. Which is also claimed on http://www.haskell.org/aboutHaskell.html:
"Much of a software product's life is spent in specification, design and maintenance, and not in programming. Functional languages are superb for writing specifications which can actually be executed (and hence tested and debugged). Such a specification then is the first prototype of the final program."
also on the same page:
"Haskell, a purely functional programming language, offers you: ... * A smaller "semantic gap" between the programmer and the language. "
But if I were to specify a program (in a non-executable language) or if I were to write some function on a blackboard, I would not be restricted to only ASCII characters. For example, I would not write 'sqrt 2' but I would write a square root symbol with 2 underneath. Likewise, I would not write '2 ^ 5', but I would write a 2 with a 5 raised upwards to the right of the 2. Then why are we stuck with the mono-spatial ASCII based editors in Haskell? Why is it not possible to make Haskell program look similar to ordinary math? (also when writing those programs and not just afterward in some Latex formatted paper).
Also, programmers often use diagrams as specification. As Andrew Bromage says it in http://haskell.org/~shae/pseudocode1.pdf:
"Mostly, I strongly suspect that most code of this type is not written, but rather it's translated into. I tend to see many uses of "point-free style" in the same light. It's also one of the reasons why I've resisted using arrows: You don't program in arrow style; you program in diagrams on paper, then translate that into arrow style."
This makes me think that our diagrams should be compilable and thus executable? These diagrams could be embedded in our editor and intermixed with ordinary code.
I have looked for the type of editor roughly outlined above, but found nothing. If anybody have some links to projects, which is related to these kind of thoughts please let yourself be heard. Also, of cause, comments are most welcome.
-- Mads Lindstrøm <mads_lindstroem@yahoo.dk>
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Reginald Meeson wrote:
Mads --
Eons ago, colleagues and I put together a primitive data flow diagram editor and generated functional code for the functions users wired together. One of the things we learned was that people would happily wire together diagrams with state components that could not be translated because they did not represent functions. (Two different data flow paths sharing the same state creates obvious race conditions, but that's what some people wanted to draw.)
It was an interesting exercise to build the tool, but I don't think it gave users any great advantage. Perhaps is was a shortcoming of the tool, which was little more than a prototype. However, the informal nature of data flow diagramming at that time seemed to be out of synch with the rigor needed for programming. Good luck with your search -- it may be a good time to try it again.
Do you have any papers or other kind of documentation describing the system? what worked and what did not work? -- Mads Lindstrøm <mads_lindstroem@yahoo.dk>
participants (13)
-
Antti-Juhani Kaijanaho -
Benjamin Franksen -
Bill Wood -
Jan-Willem Maessen -
Jesper Louis Andersen -
Johannes Waldmann -
Jérémy Bobbio -
Ketil Malde -
Mads Lindstrøm -
Marcin 'Qrczak' Kowalczyk -
Reginald Meeson -
Shae Matijs Erisson -
Stefan Monnier