Given that arc compiles to mzscheme, mz seems like the right name. If there was a CL-based arc with the same feature, the name would be more debatable. In rainbow for example, a "pass through the compiler unchanged" feature is meaningless - there is nothing on the other side that would understand.
"mz" also has the advantage of being short, expressive and euphonic, unlike "qac" or "ptac"
More generally, why would you want the pass-through-compiler feature to be named the same thing in different arc systems if the backend is different? Code that works when you're compiling to mzscheme is useless if you're compiling to CL; you'd rather have it warn you that it doesn't know what the hell you're talking about when it sees "mz" than have it (mis)interpret your mzscheme code as CL code.
Various languages were represented in the audience. Generally, python and erlang users were less impressed; but users of java and other blubs found a new way in which their language was inadequate :)
Some were concerned about unreadability, and others dismissed arc as impractical, but overall I think people seemed to appreciate the power macros can bring to a language, and how hopeless the situation is for java et al, given their heteroiconicity.
I'm curious, in the example you give, you show a missing closing paren after a def; but how does the reader know that the missing paren isn't missing from a later form? (assuming the reader has little understanding of the content it's reading beyond paren-balancing - especially since it's a scheme reader reading arc code).
The only obvious clue I can see is indentation ...
At this stage, MzScheme is reading lists from the input file as data. Once a complete list has been read, Arc then takes that list and interprets it as a piece of Arc code.
On line 4, the MzScheme reader sees the first opening parenthesis which starts the def. It then reads all the way to the end of the file without finding a closing parenthesis, and so complains that it isn't able to read the list starting on line 4.
ummm ... doh. I understand now, it's reporting the line number of the unmatched opening paren ... I was thinking it was the line number where the missing one should have been. thanks.
You can use 'with to create variables pointing just to the two tables you need and then there's less digging to do when you need to look up or alter values.
You might get better mileage by changing the data structure though if that's possible:
app*
yardwork ...
house
roof
budget = 1996.0
forecast = 1996.0
windows
budget = 1000.0
forecast = 1800.0
Arc doesn't really have "pointers" (at least not in the c/c++ sense) - you either have global variables, or local (lexically-scoped) variables. So you can create a local variable pointing to the innermost table using 'let or 'with. Oh, I said "pointing" - well, they're kinda pointers.
Does that point you in the right direction, or did I miss the point entirely?
btw with the hot new special-syntax you can write app.area.sub-area instead of ((app area) sub-area) - see http://arclanguage.org/item?id=9220
"The sticking point is compression-tolerance. As you write code through your career, especially if it's code spanning very different languages and problem domains, your tolerance for code compression increases. It's no different from the progression from reading children's books with giant text to increasingly complex novels with smaller text and bigger words."
If my understanding is vaguely correct, Yegge argues for compact code for the same reasons pg does.
I personally wish there were a means to quickly identify the data-type
Something that an editor for a dynamic language can give you is run-time analysis of your code - so, indeed, a mouse-over could in fact give you a list of the types assigned to any given symbol. This is something I'd love to get welder to do ... it's entirely possible, in theory :)
Alternatively, you could write your own function definition macro that lets you specify param types and checks them for you at runtime:
I enjoyed the first half - then he went on and on and on....
My goal is to try making code readable enough that documentation or 'metadata' is barely needed. I'm going to rework my code and start keeping my code idealized - not descriptive - not short.
I'm going see how it works when I drop the data type tagging all together and hope one day when I am a little more knowledgeable I will be able to craft a solution.
Maybe in a few years I'll let you know how it went :)
T
Awesome work. Watch out for the numerous number formats scheme allows -
1.3e-32-4.3e+56i
3/8-4.3e+56i
I can attest that it's hell to parse these numbers - and imz returns 56 in each of these cases. You might need to use real-part and imag-part from scheme if you don't want to write a complex number parser in arc :)
Thanks for the feedback, conanite :)
I think I know how to cope with that problem. I'll post my results as soon as I have some spare time. I'm also planning to successively add more elaborate mathematical functions. Maybe some numerical integration or solving differential equations.
