Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
1–10 of 51 posts
Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#2Edit: the HLA web site always used to be a decent place to learn assembly language. I don't remember it being so mauve though: http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.h...
Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#3Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#4Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#5That one is more popular, it eventually became OCaml.
Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#6 Identifiers Can Have Blanks
open_window_with_attributes(...)
becomes:
open window with attributes (...)
I think I actually felt that wrongness in my stomach. Like a more intense version of seeing our corporate network shared drive's files with spaces and parens in them.I guess I'm old.
Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#7I was surprised by my almost-panicky reaction to seeing: Identifiers Can Have Blanks open_window_with_attributes(...) becomes: open window with attributes (...) I think I actually felt that wrongness in my stomach. Like a more intense version of seeing our corporate network shared drive's files with spaces and parens in them. I guess I'm old.
An implementation exists, so the author has something working, but I'm wondering how robust the parsing is. I haven't seen many code examples (only short fragments on the page), so I don't know what potential issues, if any, there are. But, this is the sort of thing that could significantly complicate adding new language features that requires additional syntax.
edit: I'm perusing the source for the compiler, which is of course written in Zinc. This code from the main driver of the compiler perhaps gives a better feel for how it may look in practice:
while i
From an aesthetic point of view, it doesn't look that bad. In this example, I think "is equal", "out filename", "to OS name" and "include path" are all identifiers. But I'm still wondering what kind of parsing and lexing issues that may arise.Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#8I was surprised by my almost-panicky reaction to seeing: Identifiers Can Have Blanks open_window_with_attributes(...) becomes: open window with attributes (...) I think I actually felt that wrongness in my stomach. Like a more intense version of seeing our corporate network shared drive's files with spaces and parens in them. I guess I'm old.
"I did this because I hate uppercase characters in the middle of identifiers and I'm too lazy to type shift to get the '_'. In addition, I find it more readable."
just-use-lisp-style-identifiers-then
Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#9I was surprised by my almost-panicky reaction to seeing: Identifiers Can Have Blanks open_window_with_attributes(...) becomes: open window with attributes (...) I think I actually felt that wrongness in my stomach. Like a more intense version of seeing our corporate network shared drive's files with spaces and parens in them. I guess I'm old.
From the article: "I did this because I hate uppercase characters in the middle of identifiers and I'm too lazy to type shift to get the '_'. In addition, I find it more readable." just-use-lisp-style-identifiers-then
hitting - is not significantly easier than hitting _ when compared to hitting the spacebar.
Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax
#10I was surprised by my almost-panicky reaction to seeing: Identifiers Can Have Blanks open_window_with_attributes(...) becomes: open window with attributes (...) I think I actually felt that wrongness in my stomach. Like a more intense version of seeing our corporate network shared drive's files with spaces and parens in them. I guess I'm old.
Actually the connection with Ruby is tenuous anyhow; Ruby and assembler just don't go together. An assembler should produce a very clear one-to-one correspondence of instruction to machine language opcode, pretty much by definition. A high-level language can turn a simple statement into arbitrarily-complicated run-time code, pretty much by definition. Neither of these are criticisms by any means, it's just what they are. There isn't much syntax cross-talk to be had there.