Arc Forumnew | comments | leaders | submit | drcode's commentslogin
2 points by drcode 6257 days ago | link | parent | on: Referential transparency

You're asking a complicated question with a complicated example and don't have matching parentheses.

You can't expect us to answer this without supplying us with a proper example.

-----

2 points by xrchz 6256 days ago | link

I'm really sorry my parentheses were mismatching. Here is a correct example.

  (define pusher cons)
  (define-syntax push
    (syntax-rules ()
      ((_ e ls) (pusher e ls))))
  (let ((pusher (lambda (x ls) (append ls (list x)))))
    (display (push 'a '(b c d))) (newline)
    (display (pusher 'd '(a b c))) (newline))

-----

1 point by almkglor 6257 days ago | link

Well, I think it's an example of the problem I pointed out here: http://snapvm.blogspot.com/2008/07/symeval.html

-----

1 point by xrchz 6256 days ago | link

I think you're right.

-----

1 point by drcode 6258 days ago | link | parent | on: Restart Points in arc/lisp

you're right- I may not have thought about some of the details involved in this.

-----

1 point by drcode 6259 days ago | link | parent | on: Packaging libraries

I like this idea- good work!

-----

3 points by drcode 6259 days ago | link | parent | on: Restart Points in arc/lisp

Take a look at my nondeterministic regular expression library to see how you can do this.

Or, read "On Lisp" to learn how to do this with continuations, as stefano already pointed out.

-----


The first idea, as previously mentioned, conflicts with destructuring. Plus, global variables shouldn't be assigned to much, anyway. Local variable assignment already handles this issue pretty well, with "let", "with" and "withs".

As for the second issue, lists are not a primitive type in Lisp: They are made out of cons cells. I think a "cons" symbol should take priority. Once we have that worked out and it proves useful a "list" symbol might make sense.

-----


In my own view, the payoff here isn't really enough relative to

  (obj a 1 b 2)

-----

3 points by Amferreira 6259 days ago | link

Yes, but then you can't print hash tables in a way that is also readable, and unambiguous with a list. Right now: arc> (= codes (obj "Boston" 'bos "San Francisco" 'sfo "Paris" 'cdg)) #hash(("Boston" . bos) ("Paris" . cdg) ("San Francisco" . sfo))

Could be: arc> (= codes {("Boston" 'bos) ("San Francisco" 'sfo) ("Paris" 'cdg)} {("Boston" 'bos) ("San Francisco" 'sfo) ("Paris" 'cdg)}

If the () are required or not is up for discussion, keys/values could be positional like obj.

Note that printing (obj a 1 b 2) as (obj a 1 b 2) is ambiguous with printing the list '(obj a 1 b 2)

-----

2 points by drcode 6259 days ago | link

I think you have a good point here. I'll have to think about this line of thinking some more.

-----

4 points by drcode 6260 days ago | link | parent | on: Need for a practical language

> What do you think about this?

Sounds like a great recipe for creating a ten year language, like Perl.

Arc is, after all, a philosophical exercise at guessing what a hundred year language might look like (though clearly still falling well short of that goal)

Do you really think you're going to be calling a C++ function through an FFI in 100 years?

That being said, you are absolutely right that a lack of focus on libraries greatly hurts arc's chances at widespread success. I'm not sure if there is any good way to solve this dilemma, though, in the near future.

-----

6 points by stefano 6259 days ago | link

> Do you really think you're going to be calling a C++ function through an FFI in 100 years?

I think I will be dead in 100 years.

> I'm not sure if there is any good way to solve this dilemma

The only solution is to write libraries. Take some problem you think is generic enough for a library and write code to solve it. I've already written in Arc a library to download files through HTTP and a simple XML parser. They're not complete, but they're something. Talking about libraries' shortage won't solve the problem. We have to write code.

-----

2 points by andreyf 6247 days ago | link

Do you really think you're going to be calling a C++ function through an FFI in 100 years?

I don't think we can imagine how we'll be programming in 100 years - Arc is a bit too easy to imagine - and was just about imagined nearly a half-century ago.

How would you design a language if you knew that you had >2^50 the processing power you have today to compile/interpret it?

-----

3 points by drcode 6264 days ago | link | parent | on: Explicit local =

The issue is that the variable is at the scope of the "do", which means it can't be a standard macro, but a change to the language implementation. It can definitely be done though- The question is more as to whether this offers enough conceptual advantage over "let"...

This is essentially the same (or very similar at least) to a system I implemented a while back, which you can read about here: http://arclanguage.org/item?id=7485

I added an additional twist that gives it additional advantages that I argue offset the cost of a new language construct.

-----

1 point by bOR_ 6263 days ago | link

what is exactly the advantage it has over 'let'? Just brevity? (I'm not sure if having explicit local variables adds clarity)

-----

2 points by drcode 6263 days ago | link

it's the combo of brevity, one less set of parens and one less indentation level.

-----

1 point by stefano 6263 days ago | link

It would let you avoid adding an indentation level.

-----


That is cool though... I keep thinking about how neat it would be to get arc running on Google App Engine, assuming that ever moves to a parrot-based Python...

-----


That is nice that anarki has thread-local storage... I had stability issues with anarki so I've just been using arc2 with some patches lately... but I've definitely been missing thread-local storage...

-----

More