Arc Forumnew | comments | leaders | submitlogin
2 points by fallintothis 4234 days ago | link | parent

  $ git clone http://github.com/akkartik/wart.git
  $ cd wart # that you forgot :P
  $ git checkout f0e3d726eb
  $ ./wart
  wart>
Well, with instructions that simple, I suppose I really should actually try wart out before commenting. About time, right?

First run, but ./wart is shebanged (shebung? ha) with

  #!/usr/bin/env zsh
Mac user, I take it? :) I don't have zsh, but just sh works, for what it's worth.

With that fixed, I get to the REPL readily enough.

  7083 4912909 wart> (prn "hello")<CR>
  <CR>
  hello
  "hello"
Suggestion: wrap the memory allocation output of 002main.cc in some sort of debugging guard; maybe your makefile could have an ifdef DEBUG that would set some CFLAGS.

  7083 4913331 wart> (prn "world") # this is a comment!<CR>
  <CR>
  <CR>
  <CR>
  what<CR>
  7083 4913753 wart> (prn "what was that?")<CR>
  020lookup.cc:26 No binding for at
  Was it defined using indentation? Wart ignores indentation inside parens.
Well, then...the misadventures of rolling a parser by hand? Or maybe just a bug in the REPL, because loading doesn't seem to barf. Also,

  $ ./wart
  make: `wart_bin' is up to date.
  7083 4912909 wart> (prn "Why two Enters, by the way?")<CR>
  (prn "It's not like this sexp is evaluated.")<CR>
  Why two Enters, by the way?
  "Why two Enters, by the way?"
  7083 4913331 wart> (prn "Then there are errors down here.")<CR>
  004parenthesize.cc:36 Unbalanced )
  dying
I probably don't understand the significant-whitespace deal. On that note: if indentation's going to be important, I'd take a leaf from Python's REPL and have some leader characters on line continuations the same width as the initial prompt, so everything lines up. Something like

  wart> # return the index of x in seq, or nil if not found
  >>>>> def pos(x seq n)
  >>>>>   default n :to 0
  >>>>>   if seq
  >>>>>     if (car.seq = x)
  >>>>>       n
  >>>>>       (pos x cdr.seq n+1)
In all, feedback from my first foray: the REPL needs some work; silencing make after the first run, hiding debugging figures (unless I make DEBUG), adding a PS2, and figuring out why the parser breaks in odd cases would go a long way toward the user experience. :)

It's not much feedback, but it's all I've got at the moment. On topic: I have nothing against the syntax you've chosen for your update, in principle. Did the double-character ambiguity get resolved? If so, you could forgo <- in favor of the typical = & ==. Maybe Haskell's /= is more appealing than ~=, unless you use that for destructive division. # frees up ; for some potentially interesting infix uses (invokes imagery of unquoting, but other symbols kind of have that covered...).



1 point by akkartik 4234 days ago | link

Thanks for trying it out! I'm embarrassed that your experience was so terrible. Here I am, using it everyday..

I'll get on fixing all your bug reports. In the meantime I've first added them to manual_tests: http://github.com/akkartik/wart/commit/d8336d2a22; http://github.com/akkartik/wart/commit/ac4462c94d

(Edit a day later: all these bugs should now be fixed. http://github.com/akkartik/wart/commit/e062e2a407)

---

I used to be on a mac, yes, but I don't think that's why I use zsh :) It's just an apt-get away, and it spares me having to worry about bash kludges like "$@" and whatnot. But you're right, I should just use sh to minimize friction. It's not like it's a complex shell script.

-----