Arc Forumnew | comments | leaders | submit | schtog's commentslogin
0 points by schtog 5949 days ago | link | parent | on: Arc Welder - wannabe IDE

True, without paren-mathcing programming lisp is teh horrors, with it it is a piece of cake.

-----


True, most language-developers don't have the luxury of skipping backwards compatability.

Obviously this complicates things for library-developers but Arc will be very interesting when it is done.

Even if it might not be something new it will hopefully together with the Arc-community things what´s is wrong with all current LISPs.

-----


your definition of fibonacci is incorrect.

-----

1 point by schtog 6009 days ago | link | parent | on: defmacro mac?

and so:

  (defmacro def (&rest body)
    `(defun ,@body))

and there will be no sideffects of this?

-----

1 point by cooldude127 6009 days ago | link

except you wont be able to use arc's cool dotted list syntax for arguments. instead of

  (def my-fun (a . rest)
    ...)
you have to use CL's &rest syntax

  (def my-fun (a &rest rest)
    ...)

-----

1 point by schtog 6008 days ago | link

but using def and mac with these definitions:

  (defmacro mac (&rest body)
	  `(defmacro ,@body))

  (defmacro def (&rest body)
	  `(defun ,@body))

is EXACTLY the same as writing defmacro and defun?

-----

1 point by cchooper 6008 days ago | link

yep

-----

1 point by wfarr 6009 days ago | link

Personally (and this may well just be me) I prefer the latter.

-----

1 point by dreish 6008 days ago | link

What does it buy you, other than four more steps toward carpal-tunnel syndrome?

-----

1 point by schtog 6012 days ago | link | parent | on: Smalltalk vs LISP

yes that was kind of my thought. but i dont know enough about either language yet.

-----

1 point by schtog 6012 days ago | link | parent | on: having a parenthesis in a list?

i dont want to display really the display is there so i can see what is happening. i am actually writing a macro yes but just testing now to figure out how stuff works.

-----

1 point by schtog 6013 days ago | link | parent | on: Anarki tut: urexample fails

where is this pathname then that might have to be changed?

-----

1 point by absz 6012 days ago | link

In the output:

  open-output-file: cannot open output file: "C:/tmp/shashd39M2tCqX6"
It looks like the official arc2 distribution is being used here, which isn't smart about pathnames, so something in arc.arc, ac.scm, or something like that is just blindly using /s. If the Anarki is being used, then this bug should have been fixed. But as I said, I have a Mac, so I'm really just guessing here.

-----

3 points by kens 6012 days ago | link

You might try "mkdir C:\tmp"

-----

1 point by globalrev 6012 days ago | link

im using vista and anarki.

downloaded anarki like 2 weeks ago and havent fetched a new version since.

-----

1 point by schtog 6015 days ago | link | parent | on: Will/Can Arc create a LISP-revival?

is the good stuff about lisp to tied in with the syntax and notation?

i mean changing the notation to normal 2+2 instead of + 2 2 and getting rid of the parenthesises, is that really really hard to do and still keep all the features of the language? i guess it is since it hasnt been done.

macros in the lispway seems to be the biggest thing about the language. macros are dependent on code being lists and lists being code right? they are hard to do without parenthesises and notation?

-----

25 points by almkglor 6015 days ago | link

Let me tell you a story about a language called "Stutter". It's a full m-expr language. Function calls have the syntax f[x], math quite sensibly uses a + b * c notation, etc. The only weird thing is that assigning a variable uses the set special form - set[x 42] - because of some weird stuff in the parser that is only tangentially related to our discussion.

Now I'll introduce to you a special syntax in Stutter. In Stutter, () introduces a data constant called an array, which is just like any other sequential data collection in any other language. So it's possible to do something like this in Stutter:

  set[var  (1 2 3 4)]
Stutter is a dynamically-typed language, and arrays can contain strings, numbers, or even arrays:

  set[var (1 "hello" ("sub-array" 4 ))]
Let me introduce to you something new about Stutter. In Stutter, variable names are themselves data types. Let's call them labels (this is slightly related to why we have a set[] special form). And like any other data type, they can be kept in arrays:

  set[var (hello world)]
Remember that () introduces an array constant. So (hello world) will be an array of two labels, hello and world. It won't suddenly become (42 54) or anything else even if hello is 42 and world is 54. The variable's name is a label, but the label is not the variable (at least not in the array syntax; it was a bit of a bug in the original implementation, but some guys went and made code that used labels in that manner and it got stuck in the language spec).

The array is just like any other array in any other language. You can concatenate them like so:

  set[var append[(array 1) (array 2)]]
  => now var is (array 1 array 2)
You can add an element in front of it like so:

  set[var cons[1 (some array)] ]
  => now var is (1 some array)
Array access syntax is not very nice, but it does exist:

  nth[1 (this is the array)]
  => this returns the label "is"
You could create an empty array with:

  nil[]
And you could create an array with a single element with:

  array["hello"]
  => returns the array ("hello")

Oh, and remember those guys who abused the labels in array syntax I told you about? Well, they created a sort-of Stutter interpreter, in Stutter. However, they sucked at parsing, so instead of accepting files or strings or stuff like that, their Stutter interpreter accepted arrays. They were going to make the parser later, but they just really sucked at parsing.

They called their Stutter interpreter "lave", because they were hippie wannabes and were tripping at the time they were choosing the name. It was supposed to be "love", but like I said, they were tripping.

Of course, since lave accepted arrays, it couldn't get at the nice f[x] syntax. So they decided that the first element of an array would be the function name as a label. f[x] would become the array (f x).

lave had some limitations. For example, instead of Stutter's nice infix syntax a + b, lave needed (plus a b). Fortunately lave included a plus[x y] function which was simply:

  define plus[x y]
   x + y
So how come these guys became so influential? You see, Stutter's BDFL is a bit of a lazy guy. He is so lazy that he didn't even bother to fix up the syntax for if-then-else. In fact, there was no if-then-else. What was in fact present was a ridiculously ugly cond syntax:

  cond[
    { x == y
         ...your then code...
    }
    ;yes, what can I say, Stutter's BDFL is lazy
    { !(x == y)
         ...your else code...
    }
  ]
lave's creators pointed out that you could in fact represent the above code, in lave-interpretable arrays, as:

  (cond
    ( (eq x y)
      ...your then code...)
    ( (not (eq x y))
      ...your else code...))
Then they created a new Stutter function which would accept 3 arrays, like so:

  if[
    (eq x y)
    (...your then code...)
    (...your else code...)]
And then it would return the cond array above.

It looked like this:

  define if[c then else]
    append[
        (cond)
        cons[c
          array[then]]
        cons[ append[(not) array[c] ]
          array[else]]]
You could then use an if-then-else syntax like this:

  lave[
    if[ (eq x y)
         (...your then code...)
         (...your else code...)
     ]
  ]
Then they thought, hmm, maybe we can integrate this into our lave function. So they wisely decided to create a new feature in lave, called "orcam". I think it was supposed to be "okra", but unfortunately I asked them about it while they were tripping, so maybe I just got confused.

Basically, you could tell lave that certain Stutter functions would be treated specially in their lave-syntax. These functions would have the "orcam" property set in some private data of lave. Instead of just running the function, lave would extract the array components, pass them to the function, and then run whatever array that function returned. So you could simply say:

  lave_set_orcam_property[(if)]
  lave[
   (if (eq x y)
      (...your then code...)
      (...your else code...)
   )
  ]
Because of this, people started creating all sorts of orcam-property-functions. For example, there was only a while loop in the language (lazy, lazy). Someone created an orcam-property-function called for:

  define for[s c u code]
    append[ (begin) //begin{} is just a compound statement
        cons[ s
            append[(while)
                cons[c
                    cons[ code array[u]]
                ]
            ]
        ]
    ]
So you could do:

  for[(set i 0) (less i 42) (preincrement i)
    (begin (print i))]
And it would look like:

  (begin
    (set i 0)
    (while (less i 42)
       (begin (print i))
       (preincrement i)
    )
  )
So if you wanted something like a C for loop you could do:

  lave_set_orcam_property[(for)]
  lave[
    (for (set i 0) (less i 42) (preincrement i)
        (begin
             (print i)
        )
    )
  ]
It was particularly difficult to create nice orcam-property-functions, but it was easier than trying to get Stutter's BDFL to move.

Soon after lave's creators added orcam-property-functions, Stutter's BDFL decided to do something about the language. He was always bothered about the bug in Stutter array syntax where something like (hello world) would return, well, the array (hello world), instead of sensibly returning an array with the values of hello and world. So he introduced the `, syntax. An array constant prefixed with "`" would have a special meaning. It would not be completely a constant. Instead, when it saw a "," Stutter would evaluate the expression following the comma and insert that element into the array being created. So `(,hello ,world) could now become (42 54), if hello was 42 and world was 54.

Some of the top ocam-property-function writers realized that Stutter's new `, syntax would really, really help. For example, instead of the kludgy, virtually unreadable if code, you could just write:

  define if[c then else]
   `(cond
        (,c ,then)
        ((not ,c) ,else)
    )
And you could also define for as:

  define for[s c u code]
     `(begin
          ,s
         (while ,c
              ,code
              ,u
          )
      )
However, you weren't limited to just the `, syntax. It was usually the best choice, but if there was a lave-expression array you wanted that couldn't exactly be given by "`,", you could still use the good old append[] and cons[] functions. In fact, for really complex lave-expression arrays, a combination of the new `, syntax and the old append[] and cons[] functions would do quite well.

Because of this, creating orcam-property-functions became easier and their power skyrocketed. Other languages which automatically evaluated variable labels in their arrays couldn't imitate it (so what was originally a bug - that (hello world) did not evaluate the variables hello and world - became a feature). Worse, those other languages' arrays sometimes couldn't themselves contain arrays, or even have different types.

Their arrays just weren't powerful enough to hold code, so other languages never managed to create a powerful orcam-property syntax.

Eventually, people were writing Stutter programs like so:

  lave[
   (define (fn x)
      (if (less x 1)
          1
          (times x (fn (minus x 1)))
      )
   )
  ]
And so, Stutter's BDFL decided to be even more lazy and simply wrote Stutter as:

  while[true]{
    print[ lave[ read[] ] ]
  }
so that everyone didn't have to keep writing "lave[]"

-----


which file are you running to start it?

-----

1 point by globalrev 6019 days ago | link

ive tried all, as.scm, arc-exe-scm.

apparently i should use as.scm(?) but i get an error.

-----

1 point by schtog 6019 days ago | link | parent | on: Macro trouble

  (mac meta (x . y) 
      `(pr ,x ,@y))
arc> (meta 1 2 3 4 5) 123451

still dont see why the 1 is repeated in the end.

-----

2 points by sacado 6019 days ago | link

Everything returns a value in arc, at least nil, or any other value. When you evaluate something through the REPL, the result is displayed. When you call 'pr, all the args are displayed, then the first arg is returned (then, displayed by the REPL). If you type, say

  (for i 1 10 (pr 1 2 3 4 5))
You will not see the 1 repeated on each iteration. It will print nil, though : that's the value returned by 'for.

-----

1 point by jmatt 6019 days ago | link

Check out the definition for pr on arcfn. http://www.arcfn.com/doc/io.html

Prints arguments using disp. Returns the first argument.

-----

1 point by tokipin 6019 days ago | link

here's a macro that prints them out more telligibly:

  (mac pr2 args
       (let l (len args)
         `(do
            (pr ,@(firstn (- l 1) args))
            ,(last args))))

-----

More