Good news - copy and paste is finally working now (just fixed it). So now people will be able to paste in your examples! :-)
Thank you for the encouraging/motivating comment! Fixing copy-paste has been on my list for a long time, but this finally got me to do it.
I appreciate your offer to help. Maybe I should open-source Try Arc and then people can start issuing pull requests when they're motivated to fix something.
Awesome! That'll really help me show people arc code, as I'm rarely at a computer with Arc installed when I want to show people.
Open-sourcing Try Arc would be cool. I'd love to look at larger Arc projects -- all of mine are middling at best. I'm working on bigger ones, but the lack of libraries is...frustrating, so I'd love to see how other people work with Arc.
Generally, I'll try to show it to some of my programmer friends, or to people at work.
I had actually come up with an interview question: take two strings and return the index of the first difference. I posted some arc code, and wanted to have people run it.
My code:
(def first-difference (seq1 seq2 (o comparer is))
"Returns the index of the first difference between seq1 and seq2, or nil if
they are the same. This function uses 'comparer as the function to compare
elements of the sequences."
(withs (len1 (len seq1) ;; 'withs ([var1 val1]* ) binds each var to its val
len2 (len seq2)
helper (afn (seq1 seq2 pos) ;; 'afn makes an anonymous function that
;; can recurse by calling 'self
(if (is len1
len2
pos) ;; at end of both sequences
nil
(or (is len1
pos)
(is len2
pos)) ;; at end of only one sequence
pos
(~comparer seq1.pos
seq2.pos) ;; found a difference
pos
(self seq1 seq2 (+ pos 1)))))
(helper seq1 seq2 0)))
Edit: no, that's not right, because it doesn't return nil on identical sequences. Here are two variants with and without the accumulator. Which is easier for noobs?
It's interesting to compare this to the solution in my workday language. One of the reasons that M is shorter is because its functions are more tolerant. For arc, I had to make sure that the index to the string was not too large. In M, it simply returns an empty string if you attempt to access a string position beyond the length. And I used iteration with M. Perhaps the arc solution would have been shorter had I done the same there.
Are you concatenating strings? Is that where returning "" is useful? In wart concatenating strings is tolerant of non-strings, so I think returning nil should be ok.
If the string X = the string Y, print 0 (to indicate there are no differences / MUMPS uses 1-based indexing of strings)
Otherwise, go through each character of the strings and at the point where they differ, print that index and quit looping.
MUMPS does not error out on attempting to extract a character beyond the string's length. So in that event, 1 string's extract will return the empty string, which will differ from the other string's extract and will cause you to print the index and quit. Not generating such an error, of course, cuts down on the code needed.
So if we enter the for loop, we know there is a difference between the two sequences.
So we just need to find an index position i where (isnt seq1.i seq2.i) is true. If indexing off the end of a string causes an error, we need to put in code to prevent that. If indexing off the end of a string returns anything that can't be an element of the string, we can compare each index i until we find a difference, knowing that we'll eventually find one.
That worked for me with Try Arc. It's really not a large program, the portion that I wrote. On the backend, all the heavy lifting is done by Racket's sandbox library and srv.arc. On the front-end, it's Chris Done's jQuery console (and to some extent now, WordPress).
I just wanted to apologize for the frequent downtime that has been occurring at Try Arc (you may or may not have noticed). I hope it hasn't inconvenienced too many people trying to hack on Arc while away from their installations or newcomers just getting started. I know at least one time zck was unable to test some code because of it (http://arclanguage.org/item?id=15207).
Thanks for your patience while I get this figured out.
I haven't experienced the downtime. However, I would like to use it on my Android, but the Enter key does not seem to end the input line. Any ideas on how to handle that?
Hi Steve, have you had a chance to try this on your Android since yesterday? I think the update I made to fix copy-paste may have also fixed this.
The reason I say this is that I just tried it on my Android - a Samsung/Google Nexus S - and it worked (the Enter key did successfully end the input line). But it may also be due to us having different phones, so when you get a chance to try it out again, please let me know.
Also, thanks for your patience and for reminding me about this issue. I remember you first raising it a long time ago.
> The most natural interpretation of generic-noun function names is as constructors.
Before I was lukewarm on the name, but this reminded me of the pronunciation difference. Pronounce it like the noun (predikit) and it sounds confusing, but pronounce it like the verb (predikayte) and it sounds great.
I think a verbalization of "predikit" is a better way to read it. "Predikayte" already has a different meaning, one that could make people think of assertions... essentially the same meaning trouble as "testify," right? :-p
Personally, I think this is all moot, but I'd go with "checkify" or "to-check".
testify
Pro: Only 7 characters long.
Pro: Bunches with related words containing "ify."
Con: Bunches with unrelated words containing "test."
Con: Is a neologism if used in English.
Con: Has non-sequitur homonyms in English (one meaning "claim").
Con: The vocal majority here at Arc Forum seems to dislike it. :-p
predicate
Pro: Bunches with related words containing "icate."
Con: Debatable pronunciation.
"predikayte"
Con: Is a neologism if used in English, I think. It
reinterprets the verb as a verbalization of the "predikit"
version, when "predikit" is actually something of a
nominalized form of "predikayte" in the first
place[Wiktionary]. Is it already used this way?
Con: Has non-sequitur homonyms in English (one meaning
"assume").
"predikit"
Pro: Same as a related term used in English discussion.
"predikahtay"
Con: Has a non-sequitur homonym in Italian (meaning
"preach")[Wiktionary].
Con: Since it has the same spelling as a noun, it may conflict with
other noun-based names (e.g. accessors, local variables).
Con: In English discussion, needs special formatting to look like a
variable name.
checkify
Pro: Bunches with related words containing "check."
Pro: "Check" is a related term that can be dropped casually into
English discussion.
Con: "Check" has many non-sequitur homonyms in English (one
meaning "restrict").
Pro: Bunches with related words contianing "ify."
Con: Is a neologism if used in English.
to-check
Pro: Bunches with related words containing "check."
Pro: "Check" is a related term that can be dropped casually into
English discussion.
Con: "Check" has many non-sequitur homonyms in English (one
meaning "restrict").
Pro: Bunches with related utilities containing "to-".
Con: Is a downright technical term if used in English.
Con: "To check" could be seen as an infinitive form.
WordPress has become my favorite platform for building websites. The software is so robust and the ecosystem of themes and plugins so rich - I find it's really conducive to productivity.
That's why I'm excited to announce this port of Try Arc to WordPress. I think it will make the codebase more maintainable, and help me to get features & fixes out faster.
If you're curious, the Arc web server is still in play here. But now rather than the whole site being hosted that way, only the REPL is (the only component that needs to be). The rest of the site is served from a separate Apache instance; it gives way to the REPL through a simple IFrame in a WordPress page template.
Yes, you're right. It is very annoying to have the new tab on every nav link. I will try what you suggested. Thanks, Kartik. :-)
Update: For now I just disabled the new tab feature altogether. Later we'll find a way to add it just for the REPL page or otherwise address the problem. For now, be careful what you click on while working at the REPL!
Gmail and a few other places (basecamp) have a way of detecting when you have an unsubmitted form and popping up a confirmation dialog if you accidentally try to navigate away. I used to know how to do this - it's a standard javascript function that works on all browsers..
Hey thaddeus, the main issue I run into with something like this is that sessions are very resource-intensive on the server side. As it stands I get to reclaim session resources right when people leave, and still Try Arc gets overloaded and requires manual restart about once every two weeks.
Ah, but the solution seems so straightforward now: just put sessions to sleep. Every session can be stored efficiently as a list of expressions, and then re-awakened by running the expressions through a new REPL before showing it to the user.
If the REPL session takes any input, including by measuring timings or generating random numbers, it won't be deterministically recreated by a list of commands. And what if I want a fresh REPL?
When I go to Try Arc, I imagine there's a single REPL per window/tab, which goes away as soon as I leave the page. So I think it would be cool to be able to copy out transcripts (without spurious hyphens showing up :-p ) and load/paste Arc libraries, but that's all the power I hope for.
If you're looking for more of a server-side challenge (and more of a productivity site rather than a tutorial :-p ), it would be awesome to have a user account system that lets me paste a bunch of Arc utilities and load them automatically every time I start a REPL.
I'm still a bit suspicious about abstraction leaks in the concept of "save this session." I'd prefer to think in terms of a library pastebin, where I may choose to turn my REPL session into a library but I'm not misled into thinking it'll preserve more about my session than the raw code I entered.
For what it's worth, managing user logins and passwords is a very easy business with WordPress! The challenge would be figuring out how to interface those WordPress user accounts with REPL functionality.
If implemented like HN x-id's you could just refresh or reload the page in order to get a new session. And like HN one could just expire a stored session after x minutes without being used.
Note though: Originally when I posted the session-id idea I was thinking tryarc was only one session with many threads, where each session-id would really just point to its own namespace. Had this been the case it would just be the functions and variables being stored in memory. And then threads/session-ids/namespaces (whatever) could be spun up or down and managed in a myriad of ways.
You: "If implemented like HN x-id's you could just refresh or reload the page in order to get a new session."
That's the behavior I expect, but then I also expect to get a new session if I navigate somewhere and click the back button. If the back button case does not give me a new REPL, I don't see why refreshing the page would.
Having both macros and eval always seemed redundant to me, because they're both for letting you treat code as data. Also, since the eval in most lisps (Arc included) doesn't accept a second parameter for the environment context, they might as well not have eval in the first place.
1. A good theoretical lisp should be fexpr-based and have an eval which accepts both parameters.
2. A good practical lisp wants to be fast, so it should use macros instead of fexprs. Eval is basically irrelevant here.
"...they might as well not have eval in the first place."
Although I agree with you in principle, eval is needed in at least one place: load. So I don't think we can necessarily get rid of it completely, unless we used a different method of loading/evaling files...
eval is also used in a few other places in ar, but not very many. So rather than getting rid of it, I think a better solution is to say, "eval is generally a bad idea, so use something else unless you absolutely positively must use eval" which is exactly what we do.
By the way, I'll note that when I tried to use eval to expand a macro at runtime, it ended up being horrendously slow. I changed it to use a function (which did the same thing, but with thunks) and suddenly my code ran at least 100 times faster than it did with eval.
Ah, you're right. You may not be able to do away with eval.
And do you know what you just helped me realize? If we've already identified ourselves as a practical lisp, why should we try to get rid of features like eval in the first place?
A theoretical lisp tries to get rid of unnecessary features to approach being as minimal as possible. A practical lisp has already decided that it would rather be useful than theoretically minimal.
So a practical lisp probably shouldn't worry about getting rid of things unless they are actively causing problems. If it wants to be as useful as possible, it might as well leave in unnecessary features. Because they're probably still useful some of the time to some people, even if they're not totally necessary.
