11–20 of 28 posts
Just out of curiosity, is there a reason for allowing operators in variable names? I've just glanced over the introduction, so if I got something wrong here, sorry. But it seems like this would work? let shoe = 5; let size = 3; let shoe-size = 10; shoe-size := shoe-size; Now what? Is shoe-size 10 or 2?
Just out of curiosity, is there a reason for allowing operators in variable names? I've just glanced over the introduction, so if I got something wrong here, sorry. But it seems like this would work? let shoe = 5; let size = 3; let shoe-size = 10; shoe-size := shoe-size; Now what? Is shoe-size 10 or 2?
I suggest not characterizing this as "allowing operators in variable names" any more than you'd call it "allowing keywords in variable names" that in most languages you can have variables called "life", "athena", "door_count" and "ended" even if "if", "then", "do" and "end" are keywords.
(Does C "allow operators in other operators" because it has both "+" and "++"?)
Rather: in Dylan, more characters than in (say) C are treated as ordinary constituent-of-identifier characters, with the consequences that (1) you can have things like hyphens in your names and (2) you more often have to use actual whitespace to delimit operators. ("shoe-size := shoe - size".)
This is traditional in Lispy languages, in most of which #2 isn't much of a drawback anyway because of the prefix syntax (in C you can say "a=b-c" if compactness is important to you, but obviously you're not going to write "=a-bc" in a prefix language or "bc-a=" in a postfix one). Dylan is unusual in preferring #1 over #2 despite using infix syntax.
Just out of curiosity, is there a reason for allowing operators in variable names? I've just glanced over the introduction, so if I got something wrong here, sorry. But it seems like this would work? let shoe = 5; let size = 3; let shoe-size = 10; shoe-size := shoe-size; Now what? Is shoe-size 10 or 2?
Hyphens get reused to mean negation and subtraction, but they aren't operators everywhere.
If that surprises you, you haven't used enough Lisp or Forth.
See http://opendylan.org/documentation/intro-dylan/expressions-v... for more info (note the naming conventions. Those will quickly learn you to discriminate operators from characters used in symbols)
I've been seeing OpenDylan pass by on /r/lisp and HN the past few months. I've installed it, and it looks nice, but it could use some maturing and I'm not sure what the advantage over other LISPs is. Can someone explain it to me?
That's why they put a lot of thought into the sealing functionality (http://jim.studt.net/dirm/interim-36.html) and into limited types. For example, you can store a 'integer between zero and a hundred or letter of the alphabet or NULL' in a single byte. Expressing that in C is cumbersome, as you would need wrapper functions or macros, would need to remember using them, etc. A sufficiently advanced Dylan compiler could figure out a representation of its own.
Pascal-like syntax was bolted on later when they tried to bring the compiler to the masses. That, in turn, required serious thinking about the macro system.
And no, that didn't work out. There was a prerelease development environment, but they never managed to get this mainstream.
Just out of curiosity, is there a reason for allowing operators in variable names? I've just glanced over the introduction, so if I got something wrong here, sorry. But it seems like this would work? let shoe = 5; let size = 3; let shoe-size = 10; shoe-size := shoe-size; Now what? Is shoe-size 10 or 2?
White space is required around operators. This allows the names of bindings (variables, methods or whatever) to be very flexible. Things that represent a boolean can end in '?'. Operations that mutate can end in '!'. In the Objective C bridge that I'm working on, I make use of '/' like: 'objc/class-responds-to-selector'. Type names are typically enclosed in ' ' like ' ' (but that's just a convention used everywhere).
I've been seeing OpenDylan pass by on /r/lisp and HN the past few months. I've installed it, and it looks nice, but it could use some maturing and I'm not sure what the advantage over other LISPs is. Can someone explain it to me?
This can be a difficult thing to answer, as choice in programming language can be something very personal in that different things resonate in different ways with each of us. For me, some of the important things are: * The language is much smaller and cleaner than Common Lisp (and designed by some of the same people that participated in the CL standardization). * Because it has a smaller community and installed base…
Is the backend of the compiler outputting C or native assembly? Is there a way to use Dylan on ARM/Linux?
Earlier quoted context omitted.
This can be a difficult thing to answer, as choice in programming language can be something very personal in that different things resonate in different ways with each of us. For me, some of the important things are: * The language is much smaller and cleaner than Common Lisp (and designed by some of the same people that participated in the CL standardization). * Because it has a smaller community and installed base…
Point 1 & 3 are nice enough to convince me to try it out, but I kind of miss the bracey syntax. Is the backend of the compiler outputting C or native assembly? Is there a way to use Dylan on ARM/Linux?
The "HARP" backend outputs native code for x86-linux, x86-freebsd and x86-windows.
The C backend outputs C and works on x86_64-linux, x86_64-freebsd and Mac OS X.
We have an in-progress LLVM backend that will support all of the above platforms and more.
As for ARM/Linux, we have a port in progress for the C backend. In theory, it should work after a cross-compile or using cross-compilation tools, but we haven't quite tried it out yet ourselves (the person doing the port is getting married this weekend and going away for a couple of weeks).
If you would like to help out with Dylan on ARM/Linux, drop by #dylan on FreeNode IRC and I'll work with you. (The hack-a-thon this weekend is a great time for that.)
Otherwise, we plan to have this in the 2013.2 release (whenever that is).
Earlier quoted context omitted.
White space is required around operators. This allows the names of bindings (variables, methods or whatever) to be very flexible. Things that represent a boolean can end in '?'. Operations that mutate can end in '!'. In the Objective C bridge that I'm working on, I make use of '/' like: 'objc/class-responds-to-selector'. Type names are typically enclosed in ' ' like ' ' (but that's just a convention used everywhere).
Ah, ok, I had not seen the part about the mandatory whitespaces. I still think it has the potential to confuse, so if I were to write in languages that allow dashes, I'd probably still avoid them where possible (can't see the advantage over using underscores instead). Anyway, thanks for the info.
I've been seeing OpenDylan pass by on /r/lisp and HN the past few months. I've installed it, and it looks nice, but it could use some maturing and I'm not sure what the advantage over other LISPs is. Can someone explain it to me?
Apple designed the language to ease the move of experimental (typically Lisp or Smalltalk) code into production (where it had to run faster, in less memory, etc). Tey wanted a Lisp that ran as fast and as memory efficient as C, so that they could write the OS in Lisp. That's why they put a lot of thought into the sealing functionality ( http://jim.studt.net/dirm/interim-36.html ) and into limited types. For example,…
This was due to internal Apple politics, as Dylan was planed to be the system language for Newton, I don't remember any longer the full story but other group ended up getting the project.
Earlier quoted context omitted.
Ah, ok, I had not seen the part about the mandatory whitespaces. I still think it has the potential to confuse, so if I were to write in languages that allow dashes, I'd probably still avoid them where possible (can't see the advantage over using underscores instead). Anyway, thanks for the info.
Having plenty of experience both with languages that do and do not allow "operators" in variable names, it's not actually confusing in practice. You quickly learn that whitespace is very significant in those languages, and then you read them differently. This isn't any different than indentation in Python, line breaks in Ruby, or sigils in C++.
I also find that Dylan's convention of using brackets in class names rapidly grows on you. But maybe that requires working in Forth as a warming up.
And of course, hyphens not only look better than underscores, they are easier to type, too :-)