Arc Forumnew | comments | leaders | submitlogin
Interesting behavior for malformed ssyntax
8 points by Darmani 5980 days ago | 2 comments
While reading about the empty product, I thought I'd check whether it was present in Arc's (errr....MzScheme's) :

  C:\home\arc>mzscheme -m -f as.scm
  arc> (*)
  1
I then got to wondering whether functions could be invoked with 0 args using special syntax. I then discovered that, to my surprise, planting a dot at the end of a symbol caused the REPL to quit:

  arc>*.
  C:\home\arc>
A little bit of probing revealed why it occurred:

  arc>(ssexpand '*.)
  (* #<eof>)
A little more experimentation revealed that (load ...)ing files containing these malformed symbols from the REPL causes the Arc interpreter to quit as well.

I found this curious, although I can certainly see why ssexpand would return EOF for "premature" symbol ends. However, I then found that . gets translated to (#<eof> *) and 1..2 gets translated to (1 #<eof> 2) (luckily, .1 gets translated to 0.1).Thus, I thought I'd bring it this curious behavior to the attention of the community -- Arc may have cryptic error messages, but quitting the interpreter upon trying to load malformed ssyntax is as cryptic as they come.



3 points by Darmani 5979 days ago | link

Shame I didn't notice before the edit limit expired, but this post got screwed up by the formatting system. The first first line should read "Arc's (errr....MzScheme's) * :". The example in the last paragraph should read "that .* gets translated to (#<eof> *)". And everything in between should not be italicized...

(http://news.ycombinator.com/formatdoc should really be a lot easier to find.)

-----

3 points by almkglor 5979 days ago | link

LOL. Using the arc-side (require "ssyntaxes.arc") solves this, but also completely suppresses #<eof> in all cases.

Edit: Hmm. Should probably mean some fixing in the scheme-side to fix up the ssyntax and ssexpand functions.

-----