Comments & Submissions | Comments | Submissions

bogomipz

Sort by: Relevance | Points | Date Posted
"Syntax for optional/keyword args"
10 points by bogomipz over 2 years ago | link | parent | top
cached 3 days ago
Keyword arguments definitely have their place. They fix a problem with having too many optional args. Example:

  (def foo (a b c (o d) (o e) (o f) (o g))
If you want to call foo with g but not the other optional args, you'd have to write

  (foo 1 2 3 nil nil nil 42)
It's easy to loose track of positional args when there are more than say 5 of them (depends on the person), and it gets a lot worse when some are just nils. The above call with keyword args instead of optionals would be something like;

  (foo 1 2 3 'g 42)
Or, depending on the implementation, there might be a special syntax;

  (foo 1 2 3 :g 42)
"We Have Docstrings"
8 points by bogomipz over 2 years ago | link | top
cached 10 days ago
I didn't study the code in your repo, but could help also print the signature for the function?

  arc> (help add)
  (add n1 n2)
  Adds two numbers.
Lists as functions on symbol arguments
7 points by bogomipz over 2 years ago | link
cached 13 days ago
Unquoting
6 points by bogomipz over 2 years ago | link
cached 10 days ago
"Cut and Index - Arc and Ruby Side By Side"
6 points by bogomipz over 2 years ago | link | top
cached 5 days ago
Surprisingly, nobody in this thread has suggested that lists/strings in functional position could accept two arguments. This would replace the current cut function. Additionally, negative numbers should mean index from the end, and 0 as second argument could mean "to the end". Here's Python, Ruby, arc1, and lastly my suggested semantics:

The i'th item of s

    s[i]
    s[i]
    (s i)
    (s i)
The i'th item of s from the end

    s[-i]
    s[-i]
    (s (- (len s) i))
    (s (- i))
The first x items of s

    s[:x]
    s[0,x]
    (cut s 0 x)
    (s 0 x)
The last x items of s

    s[-x:]
    s[-x..-1]
    (cut s (- (len s) x))
    (s (- x) 0)
The items from position i to the end

    s[i:]
    s[i .. -1]
    (cut s i)
    (s i 0)
The items from position i to position j (inclusive)

    s[i:j+1]
    s[i .. j]
    (cut s i (+ 1 j))
    (s i (+ 1 j))
The items from position i to position j (exclusive)

    s[i:j]
    s[i ... j]
    (cut s i j)
    (s i j)
i items beginning at position j.

    s[j:j+i]
    s[j,i]
    (cut s j (+ i j))
    (s j (+ i j))
The items from position i to the end minus the last j items

    s[i:-j]
    s[i ... -j]
    (cut s i (- -1 j))
    (s i (- j))
i items beginning at the j'th position from the end

    s[-j:-j+i]
    s[-j,i]
    (cut s (- (len s) j) (+ (- (len s) j) i))
    (s (- j) (+ i (- j)))
"More generic if macro"
6 points by bogomipz over 2 years ago | link | top
cached 3 days ago
You could use this, though;

  (if (~expr1)
        (...)
      (~expr2)
        (...))
"Use Apache for static files?"
5 points by bogomipz over 2 years ago | link | parent | top
cached 10 days ago
Just take any URL that is not defop'ed to mean a file name.

Currently, if no op is defined, the server responds with "Unknown operator.". Replace that with the code for opening a file, and if this fails, respond with a proper 404 Not Found message.

"'Axioms' that might need to be added"
5 points by bogomipz over 2 years ago | link | top
cached 6 days ago
If the [...] syntax had a notation for passing on all arguments, implicit currying would be less important. Being explicit about the currying has the advantage that you don't have to know the arity of a function to recognize that currying is taking place.

How about allowing (+ 3 7 4 6 3) to be written as:

  (let numbers '(4 6 3)
       (+ 3 7 . numbers))
Couple this with [...] capturing all arguments in a variable and you get something like this (feel free to come up with a better variable than ^):

  [foo 'a 'b 'c . ^]
Table constructor
4 points by bogomipz over 2 years ago | link
cached 23 days ago
"Regular expressions"
4 points by bogomipz over 2 years ago | link | parent | top
cached 13 days ago
Now we're getting somewhere :) For this argument to really convince me, though, Arc needs better support for user defined types. It should be possible to write special cases of existing functions without touching the core definition. Some core functions use case forms or similar to treat data types differently. Extending those is not really supported. PG has said a couple of times;

"We believe Lisp should let you define new types that are treated just like the built-in types-- just as it lets you define new functions that are treated just like the built-in functions."

Using annotate and rep doesn't feel "just like built-in types" quite yet.

Sort by: Relevance | Points | Date Posted