Arc Forumnew | comments | leaders | submit | parenthesis's commentslogin
1 point by parenthesis 3820 days ago | link | parent | on: Project to learn Arc

>> My suggestion is to use the 'system' command …

One just needs to be careful to avoid command injection vulnerabilities.


1 point by akkartik 3820 days ago | link

Eek, meant to upvote.


1 point by parenthesis 4944 days ago | link | parent | on: Kenny Tilton, ranting

Well, here are some standard examples:

ITA, InspireData, PWGL, Viaweb, news.yc, reddit (initially), ...


1 point by parenthesis 5029 days ago | link | parent | on: ~Tilde and macros

Wouldn't it make more sense for (~foo ...) to expand into (no (foo ...)) ?


2 points by absz 5029 days ago | link

Not really, because that would make (keep ~foo lst) meaningless, and that's an important use of ~.


1 point by parenthesis 5033 days ago | link | parent | on: Score one for Arc

What is the ! in !ccc:ufb ... supposed to be doing? Do you mean ~ccc:ufb-reset-ephemerals , i.e. (not ... ) ?


1 point by kennytilton 5033 days ago | link

Sorry, I realized that would confuse things terribly only after posting, and would have edited it into a simple (let x 42..) after the fact to highlight the actual gaffe but decided it would be useful to share what is only coincidentally similar to Arcese in the syntax but identical in spirit.

What was posted was real CL code, but it leverages a sophisticated mechanism known as a reader macro. I imagine there might be similar hijinx in ac.scm supporting the Arc syntax, dunno.

!ccc:ufb-reset-ephemerals -> "<triplecells#ufb-reset-ephemerals>"

I do not have to type that particular RDF URI very often (done, actually, after three times) so I do not abbreviate (except for the UFB (but let's not digress))).

For the same reason that pg is creating Arc, CL programmers like to take stuff that will be a pain to to type and effectively automate the typing with a reader macro.

The use of the colon to separate the RDF namespace from the specific label is a nice pun the CL usage for its namespace mechanism packages. I got a little inconsistent in my hackery and nicknamed the triple-cells CL package "3C", so if I had to reference the stmt-new function in a different package not using triple-cells I would say (3c:stmt-new...).


3 points by cooldude127 5033 days ago | link

this is cl code, not arc. that's the joke: he was using an arc style let in common lisp code.


3 points by kennytilton 5033 days ago | link

Right, and the "score one" headline is about my concern that Arc abbreviations might not become second nature. My Arccells code uses a lot of it, but most times I had to go back and edit a (foo bar) into cuz the (foo bar) just rolled off my fingers. Of course Arc and I are new to each other so it is too soon to tell, but it feels like my fingers now need a lookahead ability they may not be able to grow. I am especially suspect of the piping : ever catching on.

In this case, I guess the one variable LET syntax of Arc caught on pretty damn fast. :)


2 points by bogomipz 5032 days ago | link

I'm sure you will remember to use foo:bar when the alternative is (fn args (foo (apply bar args)))

Using : only in the most important places might be a good thing. I.e not overuse it for (foo (bar x)) -> (foo:bar x) where it trades readability for 2 characters.


I suppose you can cdr:car .

On the one hand, it does feel like all the c....r s should be there.

On the other hand, I think cadr is pretty much the only one I ever actually use; and it is there.


I've matched pg's replies up with the questions, to make this discussion easier to read:

annotate is a general mechanism

ellipsize is supposed to display at most 80 characters of the input

median of an even-length list is supposed to return the lower of the middle two

cdar is supposed to be missing

(type 3.0) is supposed to be an int (for now)

support for complex numbers is supposed to be in Arc

client-ip is supposed to be there (for now)

afn stands for "anaphoric function"

rfn stands for "recursive function"


2 points by drewc 5031 days ago | link

But pg's was so much more concise! ;)


It would be something like this

  (w/uniq end
    (def print-list (((o a end) . b))
      (when (isnt a end) 
        (prn a) 
        (print-list b))))
to avoid the problem of the symbol end being in the input list.


1 point by drcode 5040 days ago | link

Of course, going down that road makes it bulkier and starts making the brevity less convincing :)


3 points by parenthesis 5043 days ago | link | parent | on: New version

The . ! syntax is great.

A possible problem is that I can see myself wanting to use this syntax a lot for accessing hash tables with symbols as keys. But ! is a lot more annoying to type than . is.

My alternative suggestion (which I'm sure has worse problems of its own) would be

  x.y  ->  (x 'y) if y is a symbol, (x y) otherwise

  x,y  ->  (x y)   (by analogy with , inside backquote)

  x!y  ->  (x 'y)  (if there should ever be a need to quote a non-symbol?)
Edit: Also in favour of my proposal, ! looks too much like a letter l:


is very clear.


3 points by EliAndrewC 5043 days ago | link

. and , are not very visually distinctive. It'd be like having (x 0) and (x O) both be commonly used.


3 points by parenthesis 5044 days ago | link | parent | on: Arc Indentation Syntax

Perhaps this idea should be a text-editor feature rather than a language one: the editor can be set to automatically add parentheses based on indentation.

This seems such an obvious idea, either it is actually hopelessly flawed, or else it has already been implemented by someone somewhere.


Another possibility would be a solitary & (echoing, as mentioned, &optional in CL).


1 point by AndyBoySouthPas 5042 days ago | link

In CL I use named keyword arguments much more than optional ones, so I would want to keep single character prefix for keywords. This leads to a possibility: (&& x) would signify optional, (& x) would signify keyword.