"I call Python from Arc when there's a Python library that would be useful to me."

Yup, I agree with both of those. Python is ew compared to Arc, but it does have some nice libraries.

Incidentally, I started on Arubic for fun, to learn more about how an Arc interpreter works, and also to enable nice integration with Python. Then I can finally use multi-expression lambdas with Python. :P

Oh yeah, and change some stuff that I felt Arc was lacking in.

Plus, I like Python better than Racket. So if I'm going to hack in one of the two...

---

"http://awwx.ws/lang2 "

I think d0m's saying: Why do Arc folks do things like X by making a new language? Shouldn't we put features in Arc itself, if it's going to be a language people will actually use?

I think aw's saying: Why not ask instead, "How can I do X in Arc?" In fact, here's a way I do X without making a new language.

I think Pauan's saying: I'd like to do X, and aw's approach seems clunky. I think a new language would be better.

---

As I see things, d0m, we pursue our own languages because there are certain improvements we want to make that take a complete rework of the language.

Python interop is a great example. Clojure-Java interop is possible because they both run on the same rather high-level platform, the JVM. Official Arc runs on the Racket runtime, and Python (at least CPython) is its own whole runtime, so there aren't many ways to bridge the gap except for the C FFIs and the kind of IPC aw's lang hack uses. One of the best ways to get a clean integration between Python and Arc would be to reimplement Arc and/or Python to run on the same high-level platform--and yet that means reimplementing a language, rather than improving an existing one.

Or does it? The reimplementations may already exist. If you could use Jython for your Python project, then you could probably achieve a good degree of interoperability with Jarc and Rainbow, which are high-quality Arc implementations for the JVM.

---

But really I think Python interop was only one example, and your point was any that features we could put into the main Arc language should be put there. In that case, you'll need to define what counts as Arc.

There's an official release of Arc, maintained by Paul Graham, but keep in mind that he only updates once in a blue moon and tends to leave out features that aren't obviously necessary to him. A brief language implementation is one of his primary goals for Arc.

We do have Anarki, a community fork of Arc, but keep in mind that Anarki is held back a little by a desire to be similar to official Arc, so that the next time Paul Graham releases an update, it's easy to merge it in. This similarity also makes Anarki a bit more useful in practice, since it's compatible with most official-Arc code people write.

We could probably relax that policy on Anarki, but what big changes should we allow? I'd make radical changes and turn it into Penknife. Pauan would make sorta big changes and turn it into Arubic. It could be useful to make radical implementation changes and turn it into aw's ar, and akkartik may want to radically reorganize the project's file tree.

All in all, Arc's philosophy isn't well-defined and persuasive enough to drive us all toward the same future. Although we do want to make big changes, it's easy for us to be unsure about them or disagree. So we tend to experiment with big ideas by implementing them in our own language projects, where at least we know what we like.

If it helps, think of it this way: We don't make our own languages just to let Arc stagnate. We make our own languages so that we can improve Arc in various ways all at once. This fracturing is kind of unfortunate, but we still do build upon each other's ideas, so we're just advancing the state of the Arc in an unusual way. ^_^

With respect to there being lots of variants of Arc, I think about Arc as a personal programming language. Thus that it allows extensive personalization, and people publish many personal variants, is to my mind a feature not a bug.

This diversity of course raises its own issues: we're concerned not just with interoperability between Arc and other languages, but interoperability between variants of Arc! :-) But solving this provides a more powerful platform than one stuck with providing the lowest common denominator of standard language features to ensure interoperability.

I've never thought of that. I'm used to using Racket stuff from Arc without hesitation, but then the stuff I use is provided with the Racket language, like parameters and regexes. Most of my non-Arc personal code is in Java or Groovy, and I'm very glad I can use it from Rainbow, but I haven't actually done that yet....

With arc, the language syntax and base libraries are awesome, but you scratch your head more often, wondering" well how the hell am I supposed to do that. " And these problems/features are not small roadblocks... For example, if I need to use Arc connecting to oracle? - good luck, it's not going to happen.

Thanks for the offer. I think real database connections to arc could only improve the adoption + user happiness levels, but I will suggest connecting to oracle was just an example for the point I was trying to make.

What I am suggesting is not new or even surprising. Arc has no depth for libraries. Rich solved this problem right from the get-go by having tight integration with java. Arc would have had similar success had it done the same thing - too bad really. And dropping into Scheme just doesn't cut it.

I'm suggesting users of arc will google things like 'arc oracle', or even 'scheme oracle' which returns jack. With Arc you get Nada for google answers + you get unanswered posts such as these.

http://arclanguage.org/item?id=10839

However google 'clojure oracle':

http://en.wikibooks.org/wiki/Clojure_Programming/Examples/JD....

step-by-step recipes to connect to a myriad of databases. This was made possible through Clojures tight integration with java. Clojure can import java libraries with 1 simple import statement.

Let's not forget that Clojure is a newer language than Arc - correct?

Now, I'm just looking at the title of the thread "Effort to make it easy to use in production?", and thinking - yeah, I can understand, that's why I moved over to Clojure and its too bad Arc didn't do this.

Sure I'm no expert in the programming language industry, but if I were to come up with a new spiffy language I'd rather do what Rich did. Arc could have been built atop the jvm - correct? It was just easier not to, considering arc was not about being practical, it was about attaining some elusive mystical idealized syntax that will be practical in, possibly, a hundred years from now.

The JVM naturally has the advantage that it's easy to call Java libraries, but it has the disadvantage that it has no built-in support for tail call optimization or continuations. Since it's not particularly difficult to make use of libraries running in a different process, it would be easy enough for me to use Java libraries from an Arc implemented in Racket if I wanted to, and so I had no compelling reason to write ar on top of the JVM.

There is a long history of languages written for people who want to use the JVM but who also want to be able to use a less terrible language than Java: Jython, Groovy, Clojure, etc. Since Clojure is a particularly nice language, it didn't surprise me that it rapidly gained popularity among people who want to use the JVM.

For any particular project that I may be working on, there are a mix of features that I need for that project. If I were working on a project that primarily needed to call Java libraries and I didn't need the features unique to Arc, I would most likely use Clojure myself (or Rainbow or Jarc, if it turned out that one of those were suitable to my project). If I were working on a project where the features of Arc were important and I also needed to call some Java libraries, I'd likely write it in Arc calling out to Java libraries.

Since this is a forum for Arc, I answer questions primarily from the perspective of Arc. Since typically a hundred people will browse a forum for each person posting, I primarily answer questions for the majority reading. For example, if someone makes a statement that is wrong, I will say that they are wrong, so that someone else reading the forum isn't left with incorrect facts.

When someone complains about Arc, I tend to suspect that either there's something they want, or else they just feel like complaining. People wanting things is useful. If someone actually wants X and says so, and we come up with a solution for them, then we also help the hundred other people who want that thing as well. Other the other hand, and I'm not saying that anyone has actually done this, but if someone were to sit at a computer and type in a complaint that other people haven't done the work to make Arc a popular language faster than some other language has become popular, that doesn't strike me as being particularly useful.

I'm not against complaining. Complaining is often a useful first step towards finding a solution. However, while I'm not trying to pass judgement, I am trying to discern whether someone is complaining because they just want to complain or because they want a solution.

Sure, if you have spent hundreds of hours doing low level hacking between racket<->arc you can suggest these things are not all that hard, but the reality is that many of these feature-x's are just not going to happen.

Chances are that mainstream features are not a priority for the members here... And that's my message to the OP: go use Clojure or something having the features you want. I say this from 2 years of following arc, the arc forum and its members. There are probably a dozen submissions/comments about db connects and FFI, yet to this day nothing works.

> "If you like the Arc, then instead of complaining that other people aren't figuring out what you'd want to use for you, why not take the time to help and describe what you would need in a db connection library and FFI?"

I'm thinking if you re-read the thread starting from my first comment (http://arclanguage.org/item?id=14539), you'll hopefully come to understand that I haven't been complaining, but rather I have been defending/substantiating my suggestions and thoughts.

As for why I don't take time to describe some spec, well because I'm not asking for anything and I've chosen to spend the bulk of my time learning Clojure and building applications. I guess you could say I take my own advice.

> "If you want some love on the forum, there's an easy way to get that:make a useful contribution."

Or, you could add a page to the wiki describing the ways that Clojure is better than Arc.

Since then, Jarc's actually added Rainbow compatibility functions, so you might be able to get away with writing code just for Rainbow without leaving Jarc too far behind. Rainbow's faster, but Jarc has a more straightforward implementation.

---

I didn't plan to hack on programming languages when I started playing with arc. Creating new languages/implementations is an occupational hazard of hacking on arc. Or maybe it's a pleasant side effect that we get for free (a viral - and rapidly mutating - language). Depends on how you look at it.

---

a) Can one use Arc to call Python and call Python from Arc? Yes.

b) Could you, if you wanted to, learn how this is done and package it up in a way so that it would easy to use? Sure, you could do that, if that was a way that you'd like to contribute.

When you give Javascript examples, you seem to care a lot about jQuery (with good reasons, of course). Wouldn't it be possible to separate the Arc-that-compile-in-js and jQuery?

For instance:

  (def foo ()
    (alert "test"))

  $('.click_me').click(foo); 

Ideally, that would be also possible:

  $('.click_me').click((fn () (alert 'test'))); 

  $('.click_me').click([alert "test"]); 

  ; How to differentiate betweens javascript syntax or arc/js syntax?
  $.each([1,2,3], [alert _]); 

 

  $.each([1,2,3], ~[alert _]);

  $('.click_me').click( ~(fn () (alert "test")));

  $('.click_me').click( ~[alert 'test]);

  $('click_me').click( function(e) {
    ~(alert "test in js/arc") 
    alert("test in pure js");
  });

  $('.click_me').keydown( ~[here, _ would be bound to the event object]); 

  ({} a b c d) -> js: {a: 'b', c: 'd'} 

  ([] 1 2 3) -> [1,2,3] 

  (([] 10 12 14) 1) -> 12 

I'd never thought of this before. I especially like your examples with the delimiter for switching between syntaxes. CoffeeScript provides one of those (http://jashkenas.github.com/coffee-script/#embedded), and I think you're right that it'd be nice to have.

> I find: ({} a b c d) -> js: {a: 'b', c: 'd'} Better than the single { equivalent.

([ 1 2 3) and ({ a 1 b 2) are kind of an abuse of s-expressions. I think the fact that I want them suggests I should be going all the way to [1 2 3] and {a 1 b 2}, without the parens at all. If you have to delimit them with parens, I agree [] and {} have advantages.

(Not to mention that it would screw up all editors :p)

Haha, yes it would. I finally had to turn paredit off in emacs when I was writing these expressions.

Also, as you say, a couple of (case) would be needed in the standard library. But again, I hardly see why it is a bad thing? (Maybe multi-methods would be a better approach but that's another debate). My point is that I don't really care what the standard lib code looks like.. the important part is the end language result.. no?

Finally, I get your point about the "Grand Unified Theory of Sequences". However, this list of chars suggestion is more about making the code behaviour simpler.. not that much about trying to be "minimalist to be minimalist".

Not in principle. Especially if it was totally transparent. This isn't the case in Haskell, because you wind up importing ByteString functions qualified with a prefix like B, so your code is littered with B.map this and B.length that.

But then, if it's totally transparent (i.e., same behavior & syntax between the inefficient one and the efficient one), what was the point of the separation to begin with? Just use the efficient one.

Also, as you say, a couple of (case) would be needed in the standard library.

Actually, no. I was saying that treating strings as lists would make code shorter. E.g., map has to check for strings manually right now.

  (def map (f . seqs)
    (if (some [isa _ 'string] seqs)
         (withs (n   (apply min (map len seqs))
                 new (newstring n))
           ((afn (i)
              (if (is i n)
                  new
                  (do (sref new (apply f (map [_ i] seqs)) i)
                      (self (+ i 1)))))
            0))
        (no (cdr seqs))
         (map1 f (car seqs))
        ((afn (seqs)
          (if (some no seqs)
              nil
              (cons (apply f (map1 car seqs))
                    (self (map1 cdr seqs)))))
         seqs)))

  (def map (f . seqs)
    (if (no (cdr seqs))
        (map1 f (car seqs))
        ((afn (seqs)
           (if (some no seqs)
               nil
               (cons (apply f (map1 car seqs))
                     (self (map1 cdr seqs)))))
         seqs)))

Finally, I get your point about the "Grand Unified Theory of Sequences". However, this list of chars suggestion is more about making the code behaviour simpler.. not that much about trying to be "minimalist to be minimalist".

My point was that fusing lists and strings is a popular idea since Arc doesn't really have good facilities for polymorphism. You currently need to do the (case ...) junk (or macroexpand into it or whatever), since there are sequences with their subtle interface differences. Strings-are-lists would get rid of this (until we needed another sequence type...). Object-oriented languages "do polymorphism" better (e.g., with multimethods), but breed a fervor for all-things-OO similar to the just-make-everything-a-list sentiment, even though both are extremes.

I don't really care what the standard lib code looks like.. the important part is the end language result.. no?

Right now Arc sits in the middle, without a unified sequence interface -- be it making everything a list or having some other abstraction -- so we all suffer for it, both in the standard library and in user code. Here's a fun one:

  arc> (count #\a '(#\a #\b #\c))
  1
  arc> (counts '(#\a #\b #\c))
  #hash((#\b . 1) (#\c . 1) (#\a . 1))
  arc> (count #\a "abc")
  1
  arc> (counts "abc")
  Error: "Can't take car of \"abc\""

See that post: http://arclanguage.org/item?id=12311

Not to get too hung up on this example -- I can appreciate the simplicity of the strings-are-lists model where map is concerned -- but...

You could argue that map's current behavior is sane. There's a subtle difference between expected behaviors, depending on how you want to interpret map. Currently, map says the output sequence should be of the same type as the input. As such, you might expect an error from

  (map [+ "abc" _] "def")

  (map-as 'string [+ "abc" _] "def")

"But then, if it's totally transparent (i.e., same behavior & syntax between the inefficient one and the efficient one), what was the point of the separation to begin with? Just use the efficient one."

Maybe I wasn't clear.. but I never said it needed to be transparent. If I need my strings to be highly optimized, I'd much prefer use a specialized string library and use, say:

  (let optimized-string (create-optimized-string (get-100000-chars))
   (optimized-string-map blah optimized-string))

  (with/optimized-string
     (let bleh (get-100000-chars)
       (map blah bleh)))

-----

Also, I'm not sure I agree with you on the "(until we needed another sequence type...)." Why another sequence type? Any sequences could be coerce to simple list which work with the core functions. Use map-hash, or map-file, or map-whatever if you need specialized version for other sequences. (Or as I said in the last example)

-----

Finally, again (sorry), I don't really agree on: "map says the output sequence should be of the same type as the input."

Is it true?

  (map [string "test" _] '(1 2 3)) -> ("test1" "test2" "test3")
  (map [string "test" _] "123")) -> err

Neither do I. Just trying to be terse (not that I am anyways; I have a problem with conciseness). :)

I never said it needed to be transparent

No, but I was. In my limited experience, using ByteStrings in Haskell is still too much work, as opposed to having the standard Prelude functions work "out of the box". Instead of being able to say

  map (\x -> 'x') "abc"

  import qualified Data.Bytestring as B

  B.map (\x -> 'x') (B.pack "abc")

Why another sequence type? Any sequences could be coerce to simple list which work with the core functions.

Not everything is a linked list. And forcefully coercing every data structure into a linked list wrecks the time & space complexities that give many data structures their purpose. You'd force ranges (virtual sequences, a la Python) to eat up memory, though you certainly want to (say) map over them. You force arrays to have O(n) random access times. You couldn't have immutable sequences because linked lists are mutable. Etc.

Use map-hash, or map-file, or map-whatever if you need specialized version for other sequences. (Or as I said in the last example)

Frankly, ad-hoc polymorphism is ugly. Take Scheme, for instance, whose (R5RS) standard comparison operators include:

  char=? char<? char>? char<=? char>=? string=? string<? string>? string<=?
  string>=?  = < > <= >=

I don't really agree on: "map says the output sequence should be of the same type as the input."

  arc> (type '(1 2 3))
  cons
  arc> (type (map [string "test" _] '(1 2 3)))
  cons
  arc> (type "123")
  string
  arc> (type (map inc "123"))
  string

I also don't know :) Maybe advanced arc users could share their opinion on that?

"Not everything is a linked list. And forcefully coercing every data structure into a linked list wrecks the time & space complexities that give many data structures their purpose."

Yes, this is true.

In fact, it's a decision that needs to be taken.. should the core high level function work against different data structure? (As it does with clojure?)

As for now, map does work with string (but has a weird behavior in my opinion) and doesn't work with hash. Is this what we want?

Also, what do you think about multimethods? Do you think it's something useful to be added in Arc?

---------

About the map input versus output, I get what you mean. However, (map [string "test" _] "123") should work :-/ Maybe the problem lies in the concatenation operator while constructing the new string. i.e.

  (map [coerce _ 'int] "123") could give "116101115116"
 

  (map [string "(" _ ")"] "test") -> Shouldn't it return "(t)(e)(s)(t)" ?!

The answer seems to be a resounding yes. Polymorphism was one of Arc's main principles when it was 3 weeks old (http://paulgraham.com/arcll1.html), and one that's been more-or-less preserved to this day -- just clunkily.

doesn't work with hash

I don't care for maptable in Arc. Seems like something that should be done by map. I address the point about hash-tables-as-sequences more in http://arclanguage.org/item?id=12341.

Also, what do you think about multimethods? Do you think it's something useful to be added in Arc?

From what I've seen, generic functions (single dispatch or multimethods) seem a "Lisp-y" way of solving the type-dispatch problem, and you don't really need to go full-blown OO about it. But I don't know much about other options.

However, (map [string "test" _] "123") should work :-/

Oh, I agree. I was just saying, the case could be made. :P

I think my map-as (from your original thread: http://arclanguage.org/item?id=12341) reflects map's intended behavior best, since coerce is really our standard for how types should interact. Not that it should be implemented that way, necessarily. But since coerce will flatten strings, it seems fair to say that

  (map [string "test" _] "123")

  (coerce (map1 [string "test" _] (coerce "123" 'cons)) 'string)

  arc> (coerce (map1 [string "test" _] (coerce "123" 'cons)) 'string)
  "test1test2test3"

The function [string "(" _ ")"] returns strings, so if anything, the result of that expression should be a sequence of strings, not a string itself.

I thought about making [] more powerful.. but I can't find a way to do it the "arc way".

What I am proposing is: instead of creating a special construct for currying, why not make a convention that all arc functions be currying?

so simply: (< 2) evaluate to [< 2 _] .. No special suggar, just by convention.

And for the cases where we want more powerful currying technics, we can still use the [] syntax.

You originally:

  (map (> 2) '(1 2 3 4 5)) -> (nil nil t t t)

  (map [> _ 2] '(1 2 3 4 5)) -> (nil nil t t t)

  (map (> 2) '(1 2 3 4 5)) -> (t t nil nil nil)

  (map [> _ 2] '(1 2 3 4 5)) -> (nil nil t t t)

  (map (> 2) '(1 2 3 4 5)) -> (nil nil t t t)

  (map [> _ 2] '(1 2 3 4 5)) -> (t t nil nil nil)