Arc Forumnew | comments | leaders | submit | vincenz's commentslogin

This is directly related to the existence of "daffy duck"


5 points by vincenz 6004 days ago | link | parent | on: Traversal

What you basically want, since you do not want pattern matching, is eliminators/folds/church-encoding (pick your favourite terminology).


2 points by vincenz 6006 days ago | link | parent | on: New version

Then you would need -0 to get the full string. You're not making sense.

How do you propose to get "bcde" from "abcde"?

Either you need -0, or your final 0 is ambiguous.


3 points by nex3 6006 days ago | link

No you don't - the full string is the default.

  > (cut "abcde" 1)


3 points by tokipin 6006 days ago | link

i was thinking that too, but how would you do it dynamically (eg with variables) ?

  (cut "abcde" begin end)
what would i need to put in end to get the full string? nil?


3 points by sjs 6006 days ago | link

Both nil and (len str) work. I see both sides of the argument as counting from -1 eliminates the 0 corner case.

I like indices that are intuitive with literal numbers. Counting from 0 at one end and from 1 at the other is jarring. When -1 points to the end of string rather than before the last char (cut str 0 (- (len str))) returns the first char instead of the empty string.

With -1 -> before last char:

  (def chop ((o str "abcdef"))
    (pr "Chop how many chars off the end of \"" str "\"? ")
    (= n (coerce (cut (readline) 1) 'int)) ; bug in readline prepends #\newline
    (prn "Chopped: \"" (if (is n 0) str (cut str 0 (- n))) "\"")) ; handle corner case
With -1 -> end of string:

  (def chop ((o str "abcdef"))
    (pr "Chop how many chars off the end of \"" str "\"? ")
    (= n (coerce (cut (readline) 1) 'int)) ; bug in readline prepends #\newline
    (prn "Chopped: \"" (cut str 0 (- -1 n)) "\"")) ; no corner case, but there's this -1 there
I probably made a stronger argument for -1 pointing to the end of string as it leads to shorter code.


2 points by nex3 6006 days ago | link

If you absolutely need to do that, you can just use (len str).


2 points by vincenz 6011 days ago | link | parent | on: Poll: What would you change in Arc?

Precendence levels and such are a known problem and have a known solution. There are rather easy algorithms out there that deal with this. The only problem is that because you lack typing, you could end up with things that are not parsable:

  <x f f y>
  <1 + + 1>
  <1 +>
  <+ 1>
  <+ +>
  <+ ~>


3 points by vincenz 6012 days ago | link | parent | on: How Arc should handle vectors

Sounds like lua :)


4 points by vincenz 6012 days ago | link | parent | on: Arc Ported to JavaScript

Pretty cool,

Though I have to admit, it makes firefox hang and then it asks me to stop script. I wish javascript was faster :)


8 points by nostrademons 6012 days ago | link

Fixed the hanging. Was kinda a fun fix too...manually CPS'd the loading of the libraries and then inserted a call to window.setTimeout after each iteration, which gives the browser's event loop a chance to run.


3 points by vincenz 6012 days ago | link | parent | on: Arc Ported to JavaScript

For the repo, check this:


2 points by nostrademons 6012 days ago | link

I keep getting "fatal: sha1 file '<stdout>' write error (Bad file descriptor)" when I try to git-push to the wiki repository, so if someone for whom git works wants to grab the tarball and import it, feel free.


4 points by vincenz 6012 days ago | link | parent | on: Escaping to mzscheme

This is something that was introduced in the -git- version of Arc. It was something done by a few users in #arc. It is not part of the original language.


2 points by vincenz 6014 days ago | link | parent | on: Poll: What do you NOT want in Arc ?

Rather redundant as this can be fitted in the prior poll.

Let's try to keep all this information in one post, that was the idea behind my original poll: To collect it all in one place. This just fragments it again.


11 points by vincenz 6014 days ago | link | parent | on: Poll: What would you change in Arc?

I'll add my pitch:

    1) proper phase-distinction between compilation and evaluation
       - not possible with the way that macros are currently done
    2) if not (1), then there's no excuse for not making macros first-class
       - see how to in:
    3) modules (like everyone :)
    4) Extend the concept of application to data to all data types by making it programmable in arc
       - Currently you can do ((list 1 2 3) 0) and you'll get 1, 
       - why not allow this for all data-types by having a call-back into arc, such that arc-code can switch on the type.
    5) Hygienic macros
    6) Removal of 'nil
       - 'nil does nothing more than '(), and often it breaks (e.g:
            - when printing cyclic structures
            - the fact that not all '()'s are replaced by 'nil). )
       - Seriously, what's the need for 'nil?  Just use '()
    7) That's it for now, if you want unicode, but bleh
In general, I think the focus on conciseness, while a good thing, should not be the sole purpose. I think pg is slightly misguided on focusing solely on that. You can get conciseness, if your language is powerful enough, through the use of libraries. Small changes like fn and the way if works are easily done through the use of some macrology.


5 points by ryantmulligan 6014 days ago | link

4 is crucial in my mind. You cannot let the language have more power than the programmer. Also, it lets you build more consistent programs instead of needing your own gets and sets all over the place. This would make it a huge win in decreasing tokens a program has to remember and grok about a new program they are reading.


2 points by nostrademons 6014 days ago | link

I really like #4, but what other data types would it support? Arc doesn't currently have anything other than lists, hashtables, and primitives. Unless you mean specifying call and set operations for tagged data types...


3 points by vincenz 6014 days ago | link

You can define any type you want with 'annotate'.

For instance, if you look at arc.arc, you'll see the first two macros are defined without the use of the macro mac. Using

   (set foo (annotate 'mac some-function))
This sets the type to a 'mac (or macro :)

So yes, I guess I do mean for tagged data-types, but also for any possible future 'native' types that it will come to support. Or even redefining it within the context of your application.


2 points by nex3 6014 days ago | link

The way I solved this in the Wiki was to give tagged values (except macros) the same calling semantics as their non-tagged equivalents. Thus, you can represent arbitrary datatypes as functions, tagging them to keep track of their type but still calling them.


4 points by vincenz 6014 days ago | link

That's completely the opposite of what I want :)

I want:

    a) The ability to define within arc what happens when a list is 
         used as function, instead of it being predefined in scheme
    b) The ability to do this for any type and custom types.
And potentially:

    c) For annotated values to be able to do this per-object, 
        by storing an extra field in there that is the getter, 
        where the default value is the one for the type.

    E.g:  (annotate 'blabla value getter)
If there is no getter, then use the one for type 'blabla