It is annoying that so many languages (C, Java, C#, etc) have both a conditional statement (if-else) and conditional expression (ternary ?:). Really the if-else should be an expression (I think the ternary operator is hideous).
PostScript is a lot like Lisp in that it's purely and simply homoiconic: PostScript code is just normal PostScript data. The "ifelse" operator takes a boolean and two expressions (executable PostScript polymorphic arrays, or any other PostScript object, executable or not -- non-executable objects are just pushed onto the stack), and executes one or the other depending on the value of the boolean parameter.
I think Lisp's multiple-value-bind is an inelegant hack, compared to the simplicity of PostScript.
ML languages have true tuples and I have to say is superior to output function variables and allows pattern matching.
Your the first I have seen to ever give a compliment to PostScript the language. I'll have to relook at Postscript (and other stack based languages).
Here's a metacircular PostScript interpreter:
http://donhopkins.com/home/archive/NeWS/ps.ps.txt
Also check out Glenn Reid's PostScript Distillery, a partial evaluator for PostScript programs that reads in an input PostScript program that draws text and graphics to print a document, and it partially evaluates it against the PostScript stencil/paint imaging model, and then writes out another canonical output PostScript program that draws the exact same document, but optimized, all in the same default user coordinate system, with redundant graphics state changes removed.
Distillery was the initial idea and working proof of concept that led to PDF, Adobe Acrobat and its Distiller which converts PostScript to PDF.
Of course if the input PostScript program that draws the document is procedural and has loops or recursion, the optimized output program has all the loops unwound and may actually be much larger! But the whole point of PDF and the Distiller is to strip out the programming language parts of PostScript and just represent the effective drawing commands.
http://donhopkins.com/home/archive/postscript/newerstill.ps....
And here's a paper about a visual PostScript programming and debugging environment for NeWS, which discusses the metacircular evaluator and PostScript distillery:
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines - October 1989: http://www.donhopkins.com/drupal/node/97
The Metacircular Postscript Interpreter
A program that interprets the language it is written in is said to be "metacircular". [Abelson, Structure and Interpretation of Computer Programs] Since PostScript, like Scheme, is a simple yet powerful language, with procedures as first class data structures, implementing "ps.ps", a metacircular PostScript interpreter, turned out to be straightforward (or drawrofthgiarts, with respect to the syntax). A metacircular PostScript interpreter should be compatible with the "exec" operator (modulo bugs and limitations). Some of the key ideas came from Crispin Goswell's PostScript implementation. [Goswell, An Implementation of PostScript]
The metacircular interpreter can be used as a debugging tool, to trace and single step through the execution of PostScript instructions. It calls a trace function before each instruction, that you can redefine to trace the execution in any way. One useful trace function animates the graphical stack on the PSIBER Space Deck step by step.
The meta-execution stack is a PostScript array, into which the metacircular interpreter pushes continuations for control structures. (forall, loop, stopped, etc...) A continuation is represented as a dictionary in which the state needed by the control structure is stored (plus some other information to help with debugging).
It is written in such a way that it can interpret itself: It has its own meta-execution stack to store the program's state, and it stashes its own state on the execution stack of the interpreter that's interpreting it, so the meta-interpreter's state does not get in the way of the program it's interpreting.
It is possible to experiment with modifications and extensions to PostScript, by revectoring functions and operators, and modifying the metacircular interpreter.
The metacircular interpreter can serve as a basis for PostScript algorithm animation. One very simple animation is a two dimensional plot of the operand stack depth (x), against the execution stack depth (y), over time.
Printing Distilled PostScript
The data structure displays (including those of the Pseudo Scientific Visualizer, described below) can be printed on a PostScript printer by capturing the drawing commands in a file.
Glenn Reid's "Distillery" program is a PostScript optimizer, that executes a page description, and (in most cases) produces another smaller, more efficient PostScript program, that prints the same image. [Reid, The Distillery] The trick is to redefine the path consuming operators, like fill, stroke, and show, so they write out the path in device space, and incremental changes to the graphics state. Even though the program that computes the display may be quite complicated, the distilled graphical output is very simple and low level, with all the loops unrolled.
The NeWS distillery uses the same basic technique as Glenn Reid's Distillery, but it is much simpler, does not optimize as much, and is not as complete.
PSIBER source: http://donhopkins.com/home/archive/psiber/cyber/litecyber.ps...
The source includes a twisty little version of QuickSort implemented in PostScript by Don Woods, who also wrote Adventure!
PSIBER is a terribly ugly example of 7775 lines of PostScript code that draws and edits and debugs other PostScript code, but here's some better code that is well commented and meant to serve as a programming example, which configures, draws and orders pizzas:
PizzaTool source: http://donhopkins.com/home/archive/NeWS/pizzatool.txt
PizzaTool man page: http://donhopkins.com/home/archive/NeWS/pizzatool.6
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
+ used PostScript code instead of JavaScript for programming.
+ used PostScript graphics instead of DHTML and CSS for rendering.
+ used PostScript data instead of XML and JSON for data representation.
http://www.donhopkins.com/drupal/node/97
See the PSIBER and PizzaTool code I posted in the message above for an example of what was possible with NeWS!
When you don't actually care about speed, you can do some pretty cool stuff.
But you might be interested to know there is currently an effort to get Tcl to compile to native/near-native code. Here is a paper on the new techniques being developed and a link to a talk given by one of the lead tcl core team members.
http://www.tcl-lang.org/community/tcl2015/assets/talk14/TheT...
Seriously, Picolisp is absolutely insane.
[Edit] I should say "one of the qualities." The other important one is that Tcl has no types. Even all the lisps I know have types.
Is it that it has no types or that everything is a string? asking, not stating.
set x 5
expr { $x + 3 }
I'm not sure that's a great explanation. Maybe a decent summary of the concept of 'no types' is "the language does not presume to tell you how you can or cannot use your data."
And before you ask, yes, picolisp has list interpolation (or quasiquoting, in lisp parlance), so you can control which parts of a certain chunk of code will be run when, and in which contexts. It also includes the `macro` fexpr, which makes interpolation more convenient.
I guess Self was the same way. Self & Smalltalk also give you access to the entire runtime.
Most languages of this sort, like Smalltalk, Lisp, and especially slower, more liberal implementations like PicoLisp, allow for compile-time and/or runtime AST transformation, and other sorts of metaprogramming.
in TCL, everything is a string. Or at least, everything behaves like a string in the proper context. When you pass code blocks into a command (like if, or while, or whatever), you're not passing code objects: you're passing unevaled strings. This is why expr works in TCL: there's nothing special about expr, it's just actually implementing a DSL (sort of) rather than evaling your code straight up.
The practical upshot of this is that unlike smalltalk (I think: Can an ST user actually answer this?), and to a greater degree than LISP and FORTH (;immediate and readtables are a lot more painful to wrangle), you can not only modify the semantics of the language: you can modify the syntax.
Also you can at any time just completely replace one object by other via the becomes: message.
There are also some cool tricks when metaclasses are used, many of each one can see in Python as well.
However, you know ST better than me. Am I right?
But I think there is already quite a few things possible via messages and metaclasses, even if one cannot do actual AST transformations.
After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.
That's true. In fact, there are things that messages and metaclasses can do that you can't do with AST transformations without implementing those abstractions.
>After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.
I still miss this in Lisp. Some Lisps had that, once, but it's uncommon nowadays. it happens in the commercial CLs, but those are expensive. OS CL implementations rarely have good image support (in SBCL, image saving actually corrupts the RAM state to the point of nonrecoverability, and the docs recomend fork(2)ing if you want to save an image and continue your app).
Aside from the proprietary CLs, PicoLisp is the only modern lisp environment that has this kind of dynamic capability AFAICT (and while it does sort of have images, in the form of external symbols, the language doesn't encourage using them like this. Also, calling it modern is a stretch: it has more in common with LISP 1.5 than, say, CL). And the Schemes? Don't make me laugh. Scheme has many strengths, but reflection isn't one of them. It's something that I really wish the Lisps had.
One of the reasons I want to try my hand at implementing Lisp on the Spur VM at some point.
The speed critical parts were written in C and loaded as TCL extensions.
Back in the first .com wave.
It also taught me to never again use a programming language without JIT/AOT compiler on their standard toolchain for heavy loads.
Although they've been working on TCL perf (and even compilation) and there have been some improvements, especially when you're not doing metaprogramming. But still, using it on heavy loads isn't a great idea...
(I mean, honestly. I'm starting to think picolisp might be faster, and picolisp has 3 types and one data structure. Haven't run the benches yet, though.)
Back in the day, aolserver w/ TCL + (open)acs + pgsql/oracle was teh awesomeness compared to LAMP that everyone else was doing. Oh well... :(
We were eventually acquired by a company doing helpdesk and CRM software.
Seriously. If you want a decent cross-platform UI system with minimal effort, which has bindings in just about every language, TK is really worth your time now.
TTK is something new?
On OSX in particular, Tk UIs always stick out like a sore thumb for this reason, even with TTK.
let x = if something {
foo()
} else {
bar()
}
x = something ? foo() : bar();
x = if(something) { a = foo(); baz(a); } else { b = bar(); baz(b); }
some_condition ? this : that
Typing this, I realize how hard it is to explain without speaking it :)
It's a little tricky, because in the above, the `if` keyword appears after the question mark.
Is the color red? Yes-- this: no-- that.
Trying to make a parsimonious English sentence while maintaining the syntax elements : P
Just read it as:
IF some_condition THEN this ELSE that x = baz(if (something) foo() else bar())x = something ? ((a=foo()), baz(a)) : ((b = bar()), baz(b));
Otherwise:
x = something ? baz(foo()) : baz(bar());
x = (something) ? ({ a = foo(); baz(a) }) : ({ b = bar(); baz(b); });
x = (something) ? (a = foo(), baz(a)) : (b = bar(); baz(b));
x = (< y 0) ?? y++ : y; // evaluate y++ while (< y 0), then yield y.
x = let (int x = 3, double y = 3.0) : (x++, x*y);
The ternary operator is not actually lacking anything; with the comma operator, multiple expressions can be evaluated. What's lacking is the vocabulary of what those expressions can do.
Since functions also have a block, and the return value of the function is the result of the block, this is much more consistent.
Funny story; years before I became a C programmer, and at a time when I didn't yet study ISO C properly, I discovered and used this extension naturally.
I wanted to evaluate some statements where only an expression could be used so I thought, gee, come on, can't you just put parens around it to turn it into an expression and get the value of the last expression as a return value? I tried that and it worked. And of course, if it works it's good (standards? what are those?)
Then I tried using the code with a different C compiler; oops!
Anyway, this GNU C feature doesn't have as much of an impact as you might think.
set condition-body {puts "Hello, world"}
if { $condition } $condition-body
if { $condition } {*}$condition-body
If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).
The empty tuple:
scala> val empty = Tuple1(())
empty: (Unit,) = ((),)
scala> val empty = ()
empty: Unit = () trait Foo {
type ErrorType;
fn bar() -> Result<u8, Foo::ErrorType>;
}
struct Abc{}
impl Foo for Abc {
type ErrorType = ();
fn bar() -> Result<u8, ()> {
Err(()) // oops, we don't want to be able to do that!
}
}
enum Void{}
struct Xyz{}
impl Foo for Xyz {
type ErrorType = Void;
fn bar() -> Result<u8, Void> {
// No way to create a Void, so the only thing we can return is an Ok
Ok(1)
}
}
fn baz<F: Foo>(f: F) {
match f.bar() {
Ok(v) => println!("{}", v),
Err(e) => panic!("{}", e)
};
}
...
baz(Xyz); // The compiler can notice that f.bar() can never return a Result::Err, so strip off the match and assume it's a Result::Ok
Finally, similarly, you can specify that certain functions are uncallable by having them take Void as a parameter.
The question here was Unit vs empty tuple.
Up-thread was the question of whether C "void" is more like S/H/R Unit or S/H/R Void.
> If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).
The implication is that () == Unit == void. The empty tuple and unit are essentially equivalent aside from name, void is something else.
In truth, C void is not exactly either Void or Unit. Like Void, you can't exactly make one... but you can call functions declared to take it and write functions that return it, and really it just means "I have no information to pass" - which is more like Unit.
However, () and Unit are.
enum Void{}
fn foo(v: &Void){ ... }
let bar : Void;
fn abc() -> &Void{ ...}
fn xyz() -> Void{ ... }
On the other hand, you can do all of these just fine:
fn foo(v: ()){ ... }
fn bar(v: &()){ ... }
...
let v = ();
bar(&v);
foo(v);
(All statements here are made within the safe subset of the language - unsafe allows access to intrinsics that would allow a Void to be made, and a reference to Void.)
x = if condition
something
else
something_else
endIn the Scheme language, many imperative forms have an unspecified result. For instance, see R7RS 4.1.6: "the result of the set! expression is unspecified".
Also, a related misfeature is that function arguments can be evaluated in any order.
But for those of you who aren't scheme programmers, it gets worse: because when RnRS says that the result of something is "unspecified" many implementations take it literally. That's right: in many Schemes, `set!` returns the literal value #<unspecified>. I swear I'm not making this up. It's awful.
To quote Jonathan Gabriel of Penny Arcade: "Baby, why you always gotta make me hit you?"
That incidentally is part of the reason why the expr command was created to process infix expressions since it would be too costly to keep converting sub-expressions back and forth from strings to numbers.
How?
It's not the nicest solution, but it would allow targeting Java without disrupting the code structure too much.
[1]: https://en.wikipedia.org/wiki/Generational_list_of_programmi...
[2]: https://en.wikipedia.org/wiki/Generational_list_of_programmi...