[<<][math][>>][..]

Sat Aug 25 08:52:06 EDT 2012

Meaning

Reply to Antti's article.


- Ad-hoc meaning (Forth / Machine langauge / Lisp).

  The appeal here is definitely conceptual simplicity and expressive
  power.

  The big idea I think is feedback: should interpretation be strictly
  layered (ML / Haskell style, or even to some extent the Racket
  Scheme staged macros), or should it feed back onto itself: no
  distinction between data and code.

  This feedback loop seems to be essential to keeping things
  conceptually simple at the base level.


- Types.  While typed languages are in some sense less elegant due to
  their ad-hoc structure, these systems can be useful for generating a
  different kind of expressive power.

  E.g. dispatching based on function return type for Haskell style
  type classes.  This kind of "precognition" is of a different nature
  than purely local meaning available in feedback systems.

  However, heterogenous type/meta systems impose a lot of
  problems. Most importantly maybe: simplicity of the core system is
  lost (e.g. again Haskell: type system is very complex compared to
  the lambda calculuse it "protects").

  Basically, compared to the conceptual beauty of a feedback system
  (same language is base and meta), a layered type system has a
  different kind of freedom: meta level and language level do not need
  to correspond, and thus can very widely.

  ( Note that in Haskell there are essentially 3 levels: 1. Base
  lambda calculus, 2. the type system visible by the programmer, and
  3. the implementation of all the different type system extensions
  which map abstract logic stuff to more simple constructs.  To be
  fair, 3. needs to be counted; it seems to be necessary to keep
  piling extension onto extension to work around the limitations of
  the type system.  This has to be done as part of the compiler, not
  as part of a program.  It is not very modular!  And this work cannot
  be done by mortals either... )



- On the practical side, after using both approaches fairly
  intensively I'm still not sure which one is better, but it's obvious
  they are different and lead to a different way of thinking.

  One advantage of strong type systems and impossibility of "language
  feedback" is that they seem to be easier to read.  

  The ad-hoc nature of the "implicit meaning" that is often present
  only at the time the programmer writes an ad-hoc feedback structure
  is very hard to reconstruct from the code, and is often a "short
  term memory" organization in the programmer's head.  ( Of course
  here "programmer" is me in my own experience. )

  From my experience, writing very "semantically stacked" code in a
  dynamic/feedback language is a sure way of pissing off people that
  need to maintain your code after you're done with it!


  As for writing in Haskell vs. writing in Scheme.  In Haskell I get a
  good feeling of "wow, finally" being able to express the structure
  of what I want to do.  This often leads to a better understanding,
  but being required to do so can be a pain in the ass.  In Scheme
  things go a lot faster but often I loose track because of some
  hidden inconsistencies or differences between what I think it does
  and what it is actually doing.  The latter almost never happens in
  Haskell because it's meaning is more rigid.

[Reply][About]

[<<][math][>>][..]