<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    It doesn't have to be exactly PicoLisp.&nbsp; I would be happy with a
    thin wrapper library that simply translates super-long-names into
    names.&nbsp; Define being called "define" because it equals the English
    spelling isn't too compelling or else German programmers are in
    trouble.&nbsp; define is definieren.&nbsp; 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.&nbsp; In Pico, define = de.&nbsp; Many newish languages use def.&nbsp;
    Haskell goes off of formatting and "=" (a single character is about
    as good as it gets...).&nbsp; Arc's print = pr, etc.&nbsp; 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).&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; One is "supposed" to abstract with
    functions.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; This disadvantage is
    minimized with static typing and type inference.&nbsp; 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.&nbsp;
    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.&nbsp; 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.&nbsp; 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.&nbsp; He must know what x really<i> is</i>,
    not <i>where</i> he got it from.&nbsp; Pattern matching emphasises the <i>where</i>.&nbsp;
    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">&nbsp;</span>But if I had to
            choose which language seems to actually produce better code,
            I would have to side with PicoLisp.&nbsp;</span></blockquote>
      </div>
      <br>
      <div>I wonder whether we could implement pico as a language and
        then write&nbsp;</div>
      <div><br>
      </div>
      <div>&nbsp;#lang racket/pico&nbsp;</div>
      <div><br>
      </div>
      <div>and just reuse the PicoLisp code.&nbsp;</div>
    </blockquote>
    <br>
  </body>
</html>