In any case, I think all of the stuff in the www folder should probably be moved to the data directory, so it doesn't get wiped regularly. I just haven't done it yet; partly because I didn't know exactly where I would put it.

I'll admit, the readme isn't the best. I mostly copied it from the original and changed the relevant bits.

Thus, the path you should be using is "repo/www/admins". The www directory should already exist. You can of course change this by setting either of those variables (srvdir* or adminfile*) in repo/main.arc. It might be best to relocate that data to the other directory, or it might be deleted on accident when updating later.

The root cause is that when we made anarki open to incompatible changes we didn't think it would be automatically pulled into VMs like openshift or docker. You can only use a shifting substrate like anarki if you can control when to take in updates.

And what kind of metaprogramming models besides function/macro/fexpr do you see working on top of such a system?

I'll assume we're talking about something like RDP, but not quite RDP. David Barbour's goals for RDP include safe distributed programming, secure mashups, and sometimes even type-directed reduction of boilerplate. Thus RDP isn't necessarily RDP without an appropriate static type system, and we proabably don't need to commit to that part here.

Let's just call what we're talking about "continuous reactive" code, or "continuous" for short. :)

I'll answer out of order a bit.

---

"And what kind of metaprogramming models besides function/macro/fexpr do you see working on top of such a system?"

All of these actually keep making sense in a continuous system. The only things that can't technically be carried over are certain kinds of side effects.

Here's a more complete description of the differences:

- Most imperative side effects don't make sense. If (do (= x 1) (= x 0)) is executed continuously at every instant, then at no time is x just 1 or just 0. Continuous reactive programming needs its own particular side effects to deal with continuously displaying things, continuously maintaining connections to things, continuously monitoring the current state of the mouse, etc. Instead of mutation, continuous reactive code can use demand monitors, which aggregate sets of values. Similarly, we would have to avoid effects related to first-class continuations, threads, etc., unless we can make sense of them.

- Since all the effects at a given instant are simultaneous, the data/control flow doesn't need to be processed in a particular order, and it can naturally be concurrent, which in turn means each concurrent part can be undisturbed for a good period of time without needing to be recomputed. This means certain constructs like (if ...) stick out as expensive operations, since they must synchronize their inputs and outputs rather than letting them pass through concurrently.

- Eval and function calls are pretty weird operations. In a continuous program, the entire data flow graph exists like a constantly marching trail of ants, sometimes switching between different conditional branches. I think a dynamic call causes that trail of ants to sometimes snap between different iterations of a fractal pattern. My current implementation[1] supports "functions" but doesn't support arbitrary recursion, because I keep every possible trail instantiated regardless of whether it's currently in use. It's like all the functions are inlined whether we like it or not. (I actually kinda like it.)

- If we care about secure mashups, passing a big context object around tends to be a bad idea, especially if it's implicit. Fexprs may need a redesign in order to avoid passing authority to code that doesn't need it.

---

"How would you build a declarative continuous state system on top of arc? Or would it be better to start from scratch?"

(Building the execution semantics is probably a bigger challenge than building the state resources, so I'll assume that's what you mean.)

While starting from scratch would keep things simpler, I don't think it's necessary, as long as there's some bridge to manage the continuous side from the procedural side and/or vice versa. A single language could have dedicated syntaxes (e.g. lisp special forms) both for procedural code and for continuous code.

I've actually been thinking about how a single (fn ...) syntax could be used for both. Pure code is a special case of error-free continuous impure code, and that in turn is a special case of error-free procedural code, so a single abstraction might cover it all.

However, dynamic errors make things more interesting. In procedural Arc code, (do (foo) (err "oops 1") (bar) (err "oops 2")) would not execute (bar) because that comes after an error has occurred. In continuous code, all of the code is executed at every instant, so there is no "after" to speak of, and (bar) executes at the same time as both errors occur. (Actually, David's approach would be to terminate the computation as soon as possible and try to roll back any effects that have occurred in the meantime, so in that case (bar) would not usually be seen to execute.)

This is enough of a jarring discrepancy that I've tabled the idea of unifying the (fn ...) syntax in the procedural language I'm working on.[2] I think it's something that can be done, but it's more complex than I first thought.

Anyway, suppose we have two different syntaxes, or suppose (as David prefers) we don't have a continuous (fn ...) syntax at all but instead use concatentive programming techniques.[3]

Either way, it's painful to bridging between one style of computation and another.

Procedural code managing continuous code: Procedural code has to deal with continuous signal input similarly to how it would traditionally deal with keyboard and mouse input, and it has to deal with continuous signal output kind of like drawing to a canvas. This means writing 2-5 imperative code blocks for every bridge, at least until some common bridge patterns can be abstracted away.

Continuous code managing procedural code: One way to use continuous code to trigger an imperative action would be to build a continuously updating collection of the imperative actions we want performed, annotating each one with a timestamp so it's clear when it's supposed to happen exactly. This is cumbersome enough that I haven't tried it yet, but it's basically the kind of FFI layer that a continuous-only language would need in order to play nicely with existing OSes and protocols.

The Web is a good example of a system that already has bridges like what we'd need. An HTML document can have continuously existing tags and attributes that cause JavaScript code to be executed at certain times. In turn, JavaScript code can insert and remove declarative HTML and CSS as it goes along.

Sorry for using so many JS metaphors. :) Aside from Rainbow's UI experiments, I don't know of any Arc applications which continuously monitor or display something.

---

[1] Underreact: https://github.com/rocketnia/underreact

[2] Penknife, which currently is hidden away inside Era and not described in the readme: https://github.com/rocketnia/era

  (if foo
    (bar baz)
    qux)
  
  
     (  |         +   |       )        |   |   |
     ( foo(true)  +  foo(nil) )       bar baz qux
  =======================Disjoin=====================
  foo(true) bar  baz  qux   +   foo(nil) bar baz qux
   |         |    |    |    +    |        |   |   |
  Drop      Drop Drop  |    +   Drop     =Apply= Drop
                       |    +               |
                       =========Merge========
                                  |

The "Disjoin" operation is the distributive law on product and sum types, taking ((A + B) * C) to ((A * C) + (B * C)). In simple cases, it has to synchronize C with a combination of A and B so it knows which output to send C's packets down.

The "Merge" operation takes (A + A) to A, forgetting which branch it was on. In simple cases, it has to synchronize the original two signals becuase the output should only be inactive when both inputs are inactive. If we're using dynamic typing, we may also need to check the inputs dynamically to make sure their periods of activity don't overlap.

Overall, one call to (if ...) causes multiple synchronization points in the code.

You might wonder what Arc could use here if not (if ...), and my guess is it could use a structured data type with associated special forms that can be implemented with implicit concurrency:

  (def left (x) (annotate 'left x))
  (def right (x) (annotate 'right x))
  
  ; Sum types distribute over product types.
  ; ((A + B) * C) -> ((A * C) + (B * C))
  (disjoin (left a) c)   -->  (left (list a c))
  (disjoin (right b) c)  -->  (right (list b c))
  (disjoin other c)      -->  (err "Can't disjoin")
  
  ; Sum types are commutative.
  ; (A + B) -> (B + A)
  (mirror (left a))   -->  (right a)
  (mirror (right b))  -->  (left b)
  (mirror other)      -->  (err "Can't mirror")
  
  ; Sum types are associative.
  ; ((A + B) + C) -> (A + (B + C))
  (assocsl (left (left a)))    --> (left a)
  (assocsl (left (right b)))   --> (right (left b))
  (assocsl (right c))          --> (right (right c))
  (assocsl other)              --> (err "Can't assocsl")
  ; (A + (B + C)) -> ((A + B) + C)
  (assocsr (left a))           --> (left (left a))
  (assocsr (right (left b)))   --> (left (right b))
  (assocsr (right (right c)))  --> (right c)
  (assocsr other)              --> (err "Can't assocsr")
  
  ; (A + A) -> A
  (merge (left a))   -->  a
  (merge (right a))  -->  a
  (merge other)      -->  (err "Can't merge")
  
  ; (A -> C) -> (B -> D) -> ((A + B) -> (C + D))
  ((lift-sum l r) (left a))   -->  (left (l a))
  ((lift-sum l r) (right b))  -->  (right (r b))
  ((lift-sum l r) other)      -->  (err "Can't lift-sum")

a) Does mailgun provide a sendmail command that you can download? If so, just installing that might be all you need.

b) Anarki has rudimentary support for GET and POST on arbitrary urls.

  arc> (get-url "http://google.com")
  ("<HTML><HEAD><meta http-equiv=\"content-type\" content=\"text/html;charset=utf-8\"><TITLE>301 Moved</TITLE></HEAD><BODY><H1>301 Moved</H1>The document has moved<A HREF=\"http://www.google.com/\">here</A>.</BODY></HTML>")

For instance, the basic fizzbuzz example provided on the main page looks very similar, but doesn't actually run in anarki. Maybe that's anarki's fault, but the syntax of the for loop is different.

Rather, a macro can be described as an extension of the compiler, while a fexpr is an extension of the interpreter. In a compiled language, macros can be an optimization tool, because they can perform arbitrary computation at compile time.

In wat.js, which I believe is interpreted, macros provide relatively little value. They can still perform slightly better, because they only need to be expanded once. To quote directly from manuel:

"To fexprs I also add macros. When a macro is used as the operator of a form, the form's code gets changed to the macro's output when the macro is first called, a technique I learned from here. I like macros because they make syntactic abstraction cost-free - with fexprs alone there is always an interpretative overhead. Still, Wat macros, like fexprs, do not work with quoted identifiers, but with first-class values, so many hygiene problems are avoided."

I wish there were examples. Snippets you can copy paste that do lots of useful stuff like http://ycombinator.com/arc/tut.txt. It shouldn't take anyone more than 10secs to find how to do things. It's disheartening to hear such good work remains unused only because there are no examples but I suspect it's the truth. That's what happened to me.

It should give you basic examples of how to write code in wat, as well as show you which functions are defined. Of course, most of them don't actually have examples in the file, as it's merely defining the standard library, but it's a start. There's also test.wat, and the authors blog: http://axisofeval.blogspot.com/search/label/wat (which unfortunately mostly uses the underlying json representation for most of its code).

I'm pretty sure the answer is no, for now.

With the right use of Racket's 'parameterize and 'current-parameterization, we could build a system that works like Common Lisp's conditions and restarts. (Global variables are an alternative to 'parameterize, but they'll have more awkward interactions with continuations and threads.)

I've only played with CL once or twice, but I seem to recall one of the nicest parts about conditions and restarts is that when a condition isn't caught at the REPL, the user gets a sub-prompt they can use to invoke a restart. Threads might give us something close to this behavior, if we make the REPL's catch-all condition handler block the thread while the user chooses a restart.

Unfortunately, all preexisting Racket/Arc errors will still use the exception system rather than this homemade condition system. In order to make conditions the main error mechanism, we might have to modify the way Arc compiles to Racket so that it traps exceptions and turns them into conditions.

Finally, CL's condition handlers use its subclassing system to find the most specific handler. Arc doesn't have hierarchical dynamic typing like that, or at least not in the main language, so it might not make sense to handle conditions that way.

It's probably not. Restarts (and similar) just seemed like a really useful tool for use in production environments. Anything that makes error handling more powerful, flexible, or understandable is a good thing. But changing arc to support it might be a bit much, at least at this point.

I do think it would be good if we could improve arc's error handling though. Or at least error reporting on the repl.

Arc doesn't have hierarchical dynamic typing like that...

Though, I'd probably end up implementing something closer to wat.js with the arc library.

I'm not sure why he changed it though. There must have been some benefit (maybe the lisp-1 vs lisp-2) which made it easier to write arc.

That's not necessary either. If you want an Arc expression that evaluates to a keyword, you can already just do this:

  arc> '#:foo
  #:foo

(Example output from http://tryarc.org/.)

  arc> (= k-idfn ($:lambda (#:k v) v))
  #<procedure:zz>
  arc> (k-idfn '#:k "hello")
  Error: "struct procedure:zz: expects 0 arguments plus an argument with keyword #:k, given 2: #:k "hello""

We pretty much have two ways to call this function successfully.[1] First, we can write the function call itself as Racket code, taking advantage of Racket's function call syntax compiler to parse the keywords:

  arc> (let call-k ($:lambda (f v) (f #:k v)) (call-k k-idfn "hello"))
  "hello"

  arc> ($.keyword-apply k-idfn ($.list '#:k) ($.list "hello") ($.list))
  "hello"

Note that keyword-apply requires the keywords to be given in a specific order based on their UTF-8 bytes.

If we do a lot of this in the code, I'm thinking we could benefit from one of three things:

- An Arc function that takes an Arc table like (obj k (list "hello")) and calls Racket's 'keyword-apply it to the sorted keywords it expects.

- An Arc macro that looks like a function call, e.g. ($kw-call k-ifn #:k "hello"), but finds any occurrences of keywords and generates the appropriate Racket function call.

- A patch to Arc's own function call syntax so that it parses Racket-style keyword arguments.

I think these solutions would be more effective than shaving one or two heiroglyphics off of '#:k.

---

Not even Racket allows #:k as an expression by itself. It has to be written '#:k. After all, even if #:k evaluated to itself, (list #:k "hello") would not give you a list containing #:k and "hello", since it would try to pass a keyword argument instead.

You might wonder why Racket chose a design with such hoops to jump through. Well, I can't speak for them, but personally I'd give several shallow and hand-wavy reasons:

- It aligns with a certain mental model where positional args are an ordered list and keyword args are an orderless map. (This is the mental model I learned a long time ago in Groovy, so I like it.)

- It lets Racket treat (foo #:a 1 #:b #:c 3) as a compile-time error.

- It lets Racket treat missing/extra keyword args and missing/extra positional args as the same kind of error.

- It means keyword args don't have to be described in terms of positional args. It would be possible to design a lisp that only has Racket-style keyword args, with no positional args whatsoever.

- It means when a programmer wants to get a procedure's arity information dynamically, the result can include information about the keyword args it supports, rather than just the positional args it supports.

---

[1] Hmm, maybe there's a third way to call it successfully:

  arc> (= successfully ($:lambda (#:k v) v))

If what you're saying about '#:key vs #:key is true though, then my test cases were incorrect and I was trying to make something work that shouldn't have.

It turns out I'm getting much different results on a local setup than I was getting in tryarc.org. Since Arc 3.1 and Anarki use (require mzscheme), all sorts of things are replaced with doppelgangers that doesn't support keyword args, including the function application syntax #%app. In fact the lack of keyword arguments is one of the only things (require mzscheme) is good for. This is something tryarc.org changes, apparently.

MzScheme docs: http://docs.racket-lang.org/mzscheme/index.html

---

"So, what's the right way to hack on arc to support calling racket functions with keyword args?"

I wouldn't say it's "the right way," but we could put the functionality of Racket's 'keyword-apply in a function that takes an Arc table, and then we'd pretty much never need to worry about keywords other than that.

I have an implementation for this, which I should be able to commit with some unit tests now that I know what's going on with MzScheme.

...Actually it might take me a few days to get around to that, so here's the code if anyone wants to use it right away:

  (def $kw-apply (func kwargs . posargs)
    
    ; Convert the last element of posargs (the first-class list) into a
    ; Racket list. If posargs is completely empty, pretend the last
    ; element is an empty list just like Arc's 'apply already does.
    (zap [rev:aif rev._
           (cons (apply $.list car.it) cdr.it)
           (list:$.list)]
         posargs)
    
    (let (ks vs)
         (apply map list  ; Transpose.
           (sort (compare $.keyword<? !0)
             (map [list ($.string->keyword:+ "" (or _.0 "nil")) _.1.0]
               tablist.kwargs)))
      (apply $.keyword-apply func (apply $.list ks) (apply $.list vs)
        posargs)))

  ($kw-apply my-func
    
    ; keyword args
    (obj a list.1 b list.2 message (list "hello"))
    
    ; positional args
    1 2 3 (list 4 5))

---

"Or would it be better to make a more arc-idiomatic mongo driver, and how?"

I actually have some opinion about "the best way" for this. :)

I think Arc-idiomatic approaches serve no particular purpose, since Arc is a tool for general-purpose computation.[1] I would want a database driver to be idiomatic only for the database itself, so that it serves the more specific purpose of storing data. This can then be accompanied with sugary helper utilities, as long as they're optional.

It seems many ORMs want to bake the sugar into the interface, or they make sugar that has tiny escape hatches for poking at the underlying interface. If sugar is the only thing a programmer (usually) sees, I look at it as though it's a full-on database design of its own... which is rarely favorable since it usually inherits most of the complexity and obligations of the original.

---

Interesting. I'll have to play around with that. And study it a bit more to figure out how it works. If I understand your description correctly, the reason you're using lists is so that 'nil is interpreted as no value, while '(nil) is interpreted as intentionally passing the value 'nil? How does the function know the difference?

---

Interesting opinion. Unless I misunderstood you, I would have felt the opposite way. Normally, I would expect the purpose of the data interaction layer to be separating the implementation details from the code, so that if changes need to be made to what backend storage system you can just trade it out.

There's always a reason, but these days Anarki has broke all my code enough times that that shouldn't be a concern. :)

I think this would be a positive change.

---

"...the reason you're using lists is so that 'nil is interpreted as no value, while '(nil) is interpreted as intentionally passing the value 'nil? How does the function know the difference?"

Arc doesn't support nil as an element of a table. Setting a table entry to nil removes it. Therefore '$kw-apply will only see non-nil values anyway.

As pg says: "In situations where the values you're storing might be nil, you just enclose all the values in lists." http://arclanguage.org/item?id=493

When I was using Arc heavily, I defined a utility (sobj ...) that was just like (obj ...) but it wrapped everything in a singleton list. That may have been the only extra utility I needed.

I could write (each (k (v)) tab ...) in place of (each (k v) tab ...). I could write tab!key.0 in place of tab!key. I could write (iflet (v) tab!key ...) in place of (iflet v tab!key ...).

It was surprisingly unintrusive, even pleasant.

---

"Normally, I would expect the purpose of the data interaction layer to be separating the implementation details from the code, so that if changes need to be made to what backend storage system you can just trade it out."

  arc> ':abc
  :abc

Hopefully the README file has good enough directions for getting started. If not, reply here or put an issue on that github repo and I'll fix it.

as ur step.i successed.my site is :http://diy-tvvocold.rhcloud.com/news

but i cant sign up..why?

i try bash :

  ./arc.sh
  ./arc.sh: line 17: type: rlwrap: not found
  ./arc.sh: line 21: racket: command not found

1) rlwrap is not installed

2) racket has not been added to your path

If you want to run the arc script, you can do it manually by moving to the app-root/data folder and executing:

  racket*/bin/racket -f arc/as.scm

1) Update the anarki installation on openshift:

  rhc ssh <app>
  cd ${OPENSHIFT_DATA_DIR}arc
  git pull

3) Push to openshift, and wait ~20 seconds for it to reload.

  ##git remote add upstream -m master git://github.com/shader/arc-openshift.git
  ##git pull -s recursive -X theirs upstream master

when i try

  arc> (nsv)
  rm: cannot remove"arc/news/story/*.tmp": No such file or directory
  load items: 
  ranking stories.
  tcp-listen: listen failed
    port number: 8080
    system error: Permission denied; errno=13
    context...:
     zz
     /var/lib/openshift/53755de6500446c100000b1a/app-root/data/arc/ac.scm:1227:4

if u update the full instructions that will be great and grateful,,,thx very much! (add this will be helpful

  ##export PATH=$PATH:/var/lib/openshift//app-root/data/racket-6.0.1/bin:$PATH
)

For the git issues, I found a mistake in the instructions. The 'add remote' line should be:

  git remote add arc-openshift git://github.com/shader/arc-openshift.git

As for your repl test, you are directly calling '(nsv), which defaults to binding on port 8080 for all ips, which is against the OpenShift policy. What you want instead is:

  (nsv '("127.8.109.xxx" 8080))

Another alternative would be to just load main.arc from the terminal, which would automatically start the server exactly as the post-deploy script does, but in a way that lets you see all of the errors:

  (thread:load "../repo/main.arc")

  arc> (thread:load "../../repo/main.arc")
  #<thread>
  arc> rm: cannot remove"arc/news/story/*.tmp": No such file or directory load items;
  load items: 
  ranking stories.
  ready to serve port (127.10.233.1 8080)
  tcp-write: error writing
    system error: Broken pipe; errno=32
    context...:
     /var/lib/openshift/5375a15d5973ca41a30002b1/app-root/data/arc/ac.scm:945:0: printwith
      map1
      map1
      pr
      handle-request-thread
      handle-request-thread
  tcp-write: error writing
    system error: Broken pipe; errno=32
    context...:
     /var/lib/openshift/5375a15d5973ca41a30002b1/app-root/data/racket-6.0.1/collects/racket/private/map.rkt:26:19: loop
     /var/lib/openshift/5375a15d5973ca41a30002b1/app-root/data/arc/ac.scm:1479:0: ar-close
      handle-request-thread
  tcp-write: error writing
    system error: Broken pipe; errno=32
    context...:
     /var/lib/openshift/5375a15d5973ca41a30002b1/app-root/data/racket-6.0.1/collects/racket/private/map.rkt:26:19: loop
     /var/lib/openshift/5375a15d5973ca41a30002b1/app-root/data/arc/ac.scm:1479:0: ar-close
      th1
  tcp-write: error writing
    system error: Broken pipe; errno=32
    context...:
     /var/lib/openshift/5375a15d5973ca41a30002b1/app-root/data/arc/ac.scm:945:0: printwith
      map1
      map1
      pr
      handle-request-thread
      handle-request-thread
  tcp-write: error writing
    system error: Broken pipe; errno=32
    context...:

that's what i got while i sign and submit.and when i closed the terminal the site shutdown too...503...

------that's what i do after followed by ur 8 step instructions in http://new-tvvocold.rhcloud.com/...and when i try my way in http://news-tvvocold.rhcloud.com,by use

  ##git remote add upstream -m master git://github.com/shader/arc-openshift.git
  ##git pull -s recursive -X theirs upstream master

I tried on my site with the url "http://google.com, and that worked. However, doing just "google.com" does not, so it's apparently filtering for fully qualified urls.

As for your error message when run from the command line... I get the same "rm: cannot remove..." message, followed by "load items" and "ready to serve port..." all of which are correct. The only real error is after that part, but I'm not sure why you're getting it. That error looks like something that might happen on a timeout or broken connection with the client.

Which arc directory are you putting it in? There's the one that is the anarki installation under app-root/data, and the other which stores web app data in app-root/repo. You need to put the admins file in the app-root/repo/arc directory, or it won't be found by the app server.

main.arc is the launch script I included in my arc-openshift repository. It just sets a few variables, and then launches the news server with the right parameters. It's located in the root directory of the arc-openshift repo.

---

Even without SQL, code injection is something to worry about. The Arc codebase is a breeding ground for exactly this kind of issue, since it rarely does string escaping. Let's see...

HTML injection (XSS attacks): This is the kind of injection news.arc primarily needs to worry about. Almost every string it passes around is used directly as an HTML code snippet. Fortunately, every user input is sanitized thanks to the form-generating utilities in app.arc.

Shell injection: Make sure that any directory paths passed to (ensure-dir ...) are already shell-escaped. (Arc also invokes the shell in a few other places, but those don't need any extra escaping.)

Format string injection: Be careful about file paths passed to (tofile ...). Everything after the last slash must be a valid 0-argument format string. The format string syntax is described at http://docs.racket-lang.org/reference/Writing.html.

Starting with simple files is actually really convenient and takes very little effort. Only fixing things that need fixing is a good way to make progress quickly, but it is a little disconcerting not to have many options to switch to.

Maybe building a simple arc-based database would be a good idea, but that also distracts from solving the actual problems I'm working on. Which did not initially include making a new database, as much fun as that would be.

Merging the concept can be helpful, but requires more of the people making the examples in the first place. Also, just because a code snippet makes a good example does not mean it makes a good test, and vice versa.

I would prefer a solution where 'examples didn't include any predefined results at all, and they were all just evaluated during help. If desired, someone working with the unit test suite could write code that leveraged the examples, but it wouldn't be necessary. That way we could use good illustrative examples that may not make good tests, and good thorough tests that may not make good examples.

I certainly agree that the vocabulary of matchers is incomplete. And if we can't find a small basis set of them, this whole second alternative to tests start to seem inelegant.

Perhaps we should just tag some tests to be shown in help and call it a day. Though I like seeing the tests right next to each function. That seems useful even if we rip out the online help altogether. In fact, I started out writing examples when the macro was a noop. We could just inline all the tests, but then it would be overwhelming to have 20 tests for each function.. Ok, I'll stop rambling now. Summary of use cases:

a) Getting feedback that something broke when we make a change. (Unit tests currently do this.)

b) Seeing some examples as we read the code.

c) Online help at the repl.

I hadn't thought of the use case for wanting examples while perusing the code itself, but I must admit that I find that somewhat uncommon. I don't often know which file a function is defined in, and rarely need it given the help support we have in the repl. If I do want to look at the code, the 'src utility shows the source of a function. If I want to edit it, I often use the help utilities to find the file anyway. So having the results only available via the repl wouldn't bother me any.

Actually, I don't know if the examples should be automatically displayed with 'help, or queried separately.