<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>At the moment, you seem to be using some lib/ collection at Rosetta for your code. (I didn't have time to figure it out.) </div><div><br></div><div>What I am proposing is that you develop a pico/ collection and that you turn into a language collection. Do it on a case by case. Then you can post two solutions to any problem up there: </div><div> -- #lang racket/pico </div><div> -- #lang racket </div><div><br></div><div>Start with the Sokoban and move forward from there. -- Matthias</div><div><br></div><div><br></div><div><br></div><div><br></div><br><div><div>On Jun 10, 2013, at 5:48 PM, Sean Kanaley wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
It doesn't have to be exactly PicoLisp. I would be happy with a
thin wrapper library that simply translates super-long-names into
names. Define being called "define" because it equals the English
spelling isn't too compelling or else German programmers are in
trouble. define is definieren. I imagine define-syntax-parameter
is definieren-schalggendlahg-paravolddennneinen and they probably
use 230 width margins as a default...else they don't use full
words. In Pico, define = de. Many newish languages use def.
Haskell goes off of formatting and "=" (a single character is about
as good as it gets...). Arc's print = pr, etc. It's not good when
a <i>functional</i> language's main function-defining-construct
takes the same total characters as 3 other languages combined
(def+de+=).<br>
<br>
The following is halfway about Racket conventions/style, halfway
about pattern matching is evil (esp. without type inference), and is
mainly me rambling, so be advised...<br>
<br>
I have thought further about mixed data and verbosity, and I believe
the fundamental issue is static typing, the lack of, and trying to
simulate it with fancier types (at the expense of verbosity). Mixed
data without static types thus has the verbosity downside but
without the hypothetical safety upside...the struct amounts to a
built-in <i>comment</i> about what is supposed to be its data, but
it's really just a list with lengthier access functions and lack of
list-powered functions to operate on it. Lack of static typing
means (struct pos (x y)) sure looks like something that contains
numbers but in untyped Racket it's really just (list any/c any/c),
without the ability to treat it as a list. So something like e.g.
distance from 0 in the moves on a square grid sense is:<br>
<br>
(+ (pos-x p) (pos-y p))<br>
<br>
instead of:<br>
<br>
(apply + p)<br>
<br>
which really should be:<br>
<br>
(app + p)<br>
<br>
Then, if you change the struct, your code is secretly wrong
everywhere you pattern match. One is "supposed" to abstract with
functions. In SICP it's a given that accessors are in terms of
caadaaar and such, versus relying on the fact that it's actually <i>at</i>
the position referred to by caadaaar, exactly what pattern matching
does. Many example problems for the purposes of demonstrating the
value of abstraction have the reader redefine the datatype,
requiring changes to <i>only</i> the accessors, say cadaar instead
of cdadar. Pattern matching undoes this advantage and the
programmer is in a situation where every usage of the struct must be
tracked down or suffer runtime errors. This disadvantage is
minimized with static typing and type inference. Haskell can tell
you that either 1. a String is not an Int within some ADT or that 2.
there aren't enough positions matched against in the first place.
The syntax is also superior:<br>
<br>
(match-define (cons (pos x y) ps) ps0<br>
<br>
versus, in Haskell:<br>
<br>
(Pos x y):ps' = ps<br>
<br>
Or in "short Racket":<br>
<br>
(mdef (cons (cons x y) ps) ps0<br>
<br>
or even:<br>
<br>
(mde ((x.y).ps) ps0<br>
<br>
and we're at half the length of normal Racket, or:<br>
<br>
caar, cdar, and cdr respectively to compose the "struct" access
functions with the list ones with the addition of a single letter
(caar vs. (compose pos-x car)), or, lastly, to be fully SICP
compliant, using names that the struct maker in Racket would've come
up with, except potentially much shorter than the auto-generated
ones. I'm aware these can be renamed, but there's still the
disadvantage that structs aren't lists.<br>
<br>
As for going pure cons, I don't believe caar is a spaghetti code
version of the pattern match above. In the programmer's mind x has
to be constantly thought of as the most recent position's x coord
all the way through the section where it's in scope, or else he
can't be using it correctly. He must know what x really<i> is</i>,
not <i>where</i> he got it from. Pattern matching emphasises the <i>where</i>.
It's semi-necessary though in supposedly good coding style because
the struct "should" have a solid name like item and fields with
solid names like "weight", meaning that accessing a couple things
is:<br>
<br>
(item-weight i)<br>
(item-value i)<br>
etc.<br>
<br>
instead of:<br>
<br>
(car i)<br>
(cadr i)<br>
<br>
This verbosity encourages the use of the matcher,<br>
<br>
(define-match (item w v) i<br>
<br>
Yet that is nearly as long in total character length as the long
accessors thanks to deeffiinnneee-maaattchhh, and forever ties w to
whatever happens to be in the left-most position.<br>
<br>
Pattern matching issues aside, I believe Racket could benefit from
chopping 50% of the letters out of its identifiers.<br>
<br>
list-ref = nth<br>
define = def<br>
define-values = defs<br>
define-X = def-X<br>
apply = app<br>
vector-set! = vec!<br>
set-box! = box! (in general, the "!" indicates a setter, so do away
with the "set-")<br>
print = pr<br>
display = disp<br>
string-X = str-X<br>
append-map = map* / mappend / mapp<br>
null? = nil?<br>
lambda = delete entirely, because pressing ctrl+\ and getting an
actual lambda is vastly superior, or replace with "\" to keep it
simple<br>
<br>
<div class="moz-cite-prefix">On 06/10/2013 02:28 PM, Matthias
Felleisen wrote:<br>
</div>
<blockquote cite="mid:4AE6A351-4375-40EA-A9AB-9054CAC367A3@ccs.neu.edu" type="cite"><br>
<div>
<div>On Jun 10, 2013, at 1:49 PM, Sean Kanaley wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Lucida
Grande'; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; font-size: medium; "><span class="Apple-converted-space"> </span>But if I had to
choose which language seems to actually produce better code,
I would have to side with PicoLisp. </span></blockquote>
</div>
<br>
<div>I wonder whether we could implement pico as a language and
then write </div>
<div><br>
</div>
<div> #lang racket/pico </div>
<div><br>
</div>
<div>and just reuse the PicoLisp code. </div>
</blockquote>
<br>
</div>
</blockquote></div><br></body></html>