http://github.com/akkartik/wart/blob/44423b4107/011types.cc#...

That silliness is hard to avoid. If we don't use word wrap, we have to re-indent code when an identifier changes just so things stay on the screen. To avoid that re-indentation, we should probably redesign our text editors, diff tools, and languages so word wrap isn't a pain to work with. I think I'd rather do a little re-indentation for now.

---

It's not quite the same topic, but for a long time,[1] I've considered indentation an enemy to brevity. All that wasted whitespace! :) Arc's a:b ssyntax is great at eliminating levels of indentation.

"..indentation is not affected by the lengths of identifiers. It’s silly to format code in such a way that you need to re-indent just because you renamed a function." http://news.ycombinator.com/item?id=4993847

https://github.com/Pauan/nulan/tree/f88a81563fec518cd740302d...

Or just use the uploaded version:

http://pauan.github.com/nulan/doc/tutorial.html

You'll have to use the "Reset Tutorial" button to see all the changes.

The biggest change is that you can now click on an expression to highlight it. To see what I mean, try clicking on stuff in the tutorial.

But the coolest part is that the highlighting understands boxes. Try inputting this:

  box foo = 5

  foo + 10


  box foo = 20

  foo + 30

  w/box foo = 5
    | foo + 10
    | box foo = 20
    | foo + 30

It's also smart enough to know that the "." syntax is a string, even though it looks like a symbol:

  box foo = []
  
  foo.bar <= 5
  
  foo.bar

  (list (+ x 1) for x in xs if (> x 5))

Although, if the sole purpose here is to do away with slashed names, the only real place they're used in Arc is to shorten with- to w/.

  arc> (keep [find #\/ (string _)] (keys sig))
  (w/bars w/rlink w/table when-umatch/r w/uniq w/stdin w/stdout w/outstring w/appendfile w/socket w/outfile w/link w/instring w/infile w/link-if)

  ; Make 'let not rely on 'with, so it won't dispatch on special keywords by
  ; mistake

  (mac let (var val . body)
    `((fn (,var) ,@body) ,val))

  (= special-with* (table))

  (mac with args
    (aif (special-with* (car args))
         (apply it (cdr args))
         (let (parms . body) args
           `((fn ,(map1 car (pair parms))
               ,@body)
             ,@(map1 cadr (pair parms))))))

  (mac withify (keyword parms . body) ; for want of a better name...
    `(= (special-with* ',keyword) (fn ,parms ,@body)))

  (withify uniq (vars . body)
    `((fn ,vars ,@body) ,@(map1 [uniq] vars)))

  (withify tmpfile (f . body)
    `(let ,f (tmpfile)
       (before (system:join "rm " ,f)
         ,@body)))

  arc> (macex '(with (x 1 y 2) (+ x y)))
  ((fn (x y) (+ x y)) 1 2)
  arc> (macex '(with uniq (x y) (do-something-with x y)))
  ((fn (x y) (do-something-with x y)) gs1740 gs1741)
  arc> (macex '(with tmpfile foo (writefile 'stuff foo)))
  ((fn (foo) (before (system:join "rm " foo) (writefile (quote stuff) foo))) (tmpfile))

They might be, once I make them user-customizable. At least, as "first-class" as macros.

---

"If not, I was thinking aloud that Nulan's parser might be able to subsume patterns somehow"

Well, the way I designed it, Nulan's parser is stand-alone: you can run it without any of the other Nulan stuff.

That's because the parser is really very simple. It's only concerned about lists, symbols, numbers, and strings. It has no knowledge of boxes, or macros, or anything like that.

This is by design. Although it would be possible to integrate the parser more closely into Nulan, I like the clean separation of concerns.

Patterns are currently executed during the macro expansion phase, so that's already long after the parser has run. In addition, while the parser operates everywhere, patterns can only be used in certain places.

How they work is pretty simple. Using the not-yet-created $pattern-rule macro:

  $pattern-rule foo -> {_ pat} val body
    'val + pat + body

  (-> (foo 5) 10) 20

Now, it will call the "foo" pattern with the following arguments: (foo 5), a unique variable, and 10. These represent the pattern, the argument to the function, and the body, respectively. Whatever the pattern returns is used as the body of the function.

After running the pattern, the end result is this:

  (-> u (u + 5 + 10)) 20

  $pattern-rule and -> {_ @pat} val body
    pat.reduce
      -> x y
        pattern-match y val x
      body

Using this system, it's easy to do, for instance, list destructuring:

  $pattern-rule list -> {_ @pat} val body
    w/box i = -1
      pat.reduce
        -> x y
          pattern-match y ('val[,(++ i)]) x
        body

  -> (list a b c)
    prn a b c

  -> u
    | box a = u.0
    | box b = u.1
    | box c = u.2
    | prn a b c

http://pauan.github.com/nulan/doc/tutorial.html

I'm thinking about putting in a redirect for the old URL, but I'm not sure if it's worth it or not.

But at least you're coming up with new ideas. I can't knock you for that.

---

"I'm using keyword args in the definition of multi-word macros to evoke pattern-matching, showing what parts of a call are 'constants'. (Perhaps I need to move to a pattern-matching rather than function-name-based lookup for calls?)"

Why not just use actual pattern matching for the function arguments, like Nulan does?

I would like to point out that you can still use function-name-based lookup for calls. Then it would only be the arguments of the function that are pattern matched. That's what Nulan does.

Then you could say this:

  mac (with 'nils vars ... body)
    `((fn ,vars ,@body))

  mac (with 'tmpfile f ... body)
    `(let ,f (tmpfile)
       (before (system:join "rm " ,f)
         ,@body))

  mac (with vars 'nils ... body)
    `((fn ,vars ,@body))

This also lets you pattern match on keywords too, if you wanted to:

  mac (with :nils vars ... body)
    `((fn ,vars ,@body))

  mac (with :tmpfile f ... body)
    `(let ,f (tmpfile)
       (before (system:join "rm " ,f)
         ,@body))

In fact, depending on how you've implemented wart, you could even add in pattern matching in wart itself, so that this:

  mac (foo 'bar)
    ...

  mac (foo $u) :case ($u = 'bar)
    ...

If you have a better suggestion, I'm all ears. But I settled on that because A) it's simple, B) it's short, C) it's something that does actually come up in practice, so it's not too contrived.

---

"What's the difference between w/uniq and w/box? Both seem to create boxes."

Well, to explain this... unique variables are actually implemented as anonymous boxes. So implementation-wise, there's not much difference.

The difference is in the actual macros "w/box" and "w/uniq". Here's the definition for them:

  $mac w/box -> @args body
    'w/new-scope
       | var ,@args
       | body

  $mac w/uniq -> @args body
    'w/box ,@(args.map -> x 'x = make-uniq;)
       body

  w/box foo = 5
    foo

  w/new-scope
    | var foo = 5
    | foo

  w/uniq foo
    foo

  w/box foo = make-uniq;
    foo

  w/new-scope
    | var foo = make-uniq;
    | foo

They serve exactly the same purpose as "let" and "w/uniq" in Arc.

If you're asking why you can't just do this:

  $mac if-box ->
    w/box temp
      'w/box temp = 5
         if temp
           temp + 1

  $mac foo ->
    w/box bar = 5
      'bar + 2

I thought about having it throw an error for local symbols, which would have required you to write the macro like this:

  $mac foo ->
    w/box bar = 5
      ',bar + 2

---

"I tried running this and got the following"

It works fine for me. And in fact, the code snippet you posted seems exactly the same as what is already in the tutorial. Maybe you intended to paste something else?

You're right that there are exceptions. I think of warnings as something to indulge in in the short term. The extreme short-term; I try very hard not to ever commit a patch that causes warnings. It really isn't that hard in the moment, and the cost rises steeply thereafter.

Incidentally, I'm only this draconian with C/C++. Given their utterly insane notions of undefined behavior I think it behooves us to stay where the light shines brightest. Whether we agree with individual warning types or not, it's easier to just say no.

a) if-box is a kinda contrived example. Perhaps we can find something better?

b) What's the difference between w/uniq and w/box? Both seem to create boxes. Could I just say this at http://github.com/Pauan/nulan/blob/5dfddacfbb/nulan.html#L44...?

  $mac if-box ->
    w/uniq temp
      'w/box temp = 5
         if temp
           temp + 1

  TypeError: Cannot call method 'chunkSize' of undefined

In the beginning, Perl was a simple language. It generalized awk with user-defined functions[1], explicit file handles (STDIN, FILE) and array variables. With the idea that different things should look different, you got sigils to namespace arrays and scalars away from keywords and the standard library[2].

Over time, however, it got more line-noise. % for hashes. & and -> for references. Constants like $_ got added, positional arguments. When you consider all the primitives and capabilities in the language today, do array/scalar variables really deserve their sigils? It feels a little like hungarian notation now that the standard library includes so much more than just functions on strings and arrays.

It's all very well to say "different things should look different", but "different" isn't some absolute property. Programming languages are human things, and subject to human limitations. Our visual and frontal cortex gets swamped by too much "difference". So we need to pick carefully what to make salient. And, above all, not paint ourselves into a corner with our early decisions.

rocketnia: "I think the parentheses help programmers realize that they should look only at the variable names to determine meaningful differences between things."

nburns: "The kind of readability I'm talking about is at a much smaller scale, like being able to recognize a function call or a loop."

The advantage of lisp isn't necessarily that it forces you to do without syntax entirely. Perhaps it is that it allows syntax to be tuned by project/codebase, to make decisions in the small based on the characteristics of the whole.

For several months now I've been sporadically mulling this rambling paper: http://davewest.us/pdfs/ducks.pdf. I'm not sure what it's trying to say, but the lesson that sticks to my mind is that of the Tibetan Thangka, arranging a number of stories spatially for maximum memetic power. A program doesn't have to be just a list of functions, macros, symbols and calls. Or indeed a long list of user stories. I'm starting to believe that it matters how things are arranged in the small, because it can help grasp how things are arranged in the large, help the program to get into my head, ensure I understand how it is organized in the large, keep me from messing up the architecture with my changes, and thereby help preserve the program's coherence over longer periods of time.

[1] nawk -- the first version of awk with user-defined functions -- was released in 1988 (http://en.wikipedia.org/wiki/AWK). Larry Wall had already released Perl in 1987.

Here is the simple code to do that on etc/nginx/nginx.conf server { listen 80; server_name bloggervietnam.com www.bloggervietnam.com;

    location / {
    proxy_pass http://127.0.0.1:8080;

    }

https://github.com/Pauan/nulan/tree/9ffecb5a9aa7a4bd7cbe9680...

Firstly, there's now an interactive tutorial. Just open up "nulan.html", and if you don't see the tutorial, click the "Reset Tutorial" button at the top. Be careful, it'll clobber any changes you've made.

Secondly, you might have noticed that the editor has syntax highlighting now. But it's actually really cool. First, try inputting this:

  $mac foo -> a b c
    a + b + c

  foo 1 2 3


  def foo -> a b c
    a + b + c

  foo 1 2 3

Now try inputting this:

  # Array comprehensions
  box in

  $mac for -> x {('in) n y}
    'y.map -> n x

  $syntax-infix for 0 [ order "right" ]
  $syntax-infix in  0 [ order "right" ]

  (x + 2) for x in {1 2 3}

  $mac ^ -> a b
    a + b

  $syntax-infix ^ 0 [ delimiter %t ]

  prn 1^2

1. I just install screen and fortunately it works well. I just hit F6 button to detach my terminal session. That is why I removed fluxbox GUI for saving RAM and resource.

2. I follow the help above and now I can chance the color of the forum.

3. I have not solved the matter yet since apache did not work despite that I already installed necessary modules as you mentioned.

Javascript is easier in that way because it has garbage collection. Garbage collection makes programming easier. But you can't add garbage collection to every programming language. There are trade-offs when the language abstracts away details like memory management.

>> I suspect C feels close to the hardware because... CPU-scale architecture design has continued to pander to it

I think this gets to the issue of the Von Neumann architecture, and the fact that it isn't the only possible way to design a CPU. I'm not well educated on this subject... However, I don't think you can say that C is the reason for the Von Neumann architecture. I think it's the other way around.

>> "a pointer is the same thing as a memory address"

>> Eh? Who says it isn't? :)

Actually, in C++ the default for class members is private...

It's simply a true statement that "private" generates no machine language. All it does is cause compilation to fail. Whether or not this is a good thing is a matter of opinion.

>> IMO, anonymous functions make OO-style private scope easy and implicit, without feeling like a limitation on the programmer.

If you're speaking of lexical closures, I think you're right. You don't need to declare variables as private, because you can use the rules of scoping to make them impossible to refer to. You can achieve the same thing with a simpler syntax and more succinct code.

>> I believe you're assuming a program must run Turing-complete computations at run time. While Turing-completeness is an extremely common feature of programming languages, not all languages encourage it, especially not if their type system is used for theorem proving.

I'm not assuming that programming languages must be Turing complete. It happens to be true of all general-purpose languages that are in common use today.

>> Functional programming with guaranteed termination is known as total FP. "Epigram [a total FP language] has more static information than we know what to do with." http://strictlypositive.org/publications.html

I'll take a look at that language. I think that in 50 years' time, we might all be using non-Turing-complete languages. Making a language Turing complete is the easiest way to ensure that it can solve any problem, but isn't necessarily the best way.