Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

tibleiz.net

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#41

Post by Groxx »

scott_s wrote: post #37
Groxx wrote: post #36

Earlier quoted context omitted.

> If keywords are allowable in identifiers Big "if" (why shouldn't it disallow them?), and completely resolved by modifying your naming scheme in those situations: EndOfFile is unambiguous, as is end_of_file, ifSuccess, etc.

It's unusual as most programming languages allow keywords to appear in identifiers (for example, new_thing is a legal C++ identifier). Further, if I understand the language correctly, the literal "end_of_file" becomes the same identifier as "end of file". And the stated purpose of allowing white space in identifiers is to avoid camel case and underscores.

I don't think that's the case. I think the example was just to show how you can write with spaces instead of underscores. I could be wrong though, I haven't tried the language.

The documentation doesn't state one way or the other, but it does include underscores as part of identifiers, and doesn't mention any stripping. Only that spaces are ignored entirely.

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#42

Post by mahmud »

thesz wrote: post #5

Another Zinc: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6... That one is more popular, it eventually became OCaml.

The Zinc paper is one of my all time implementation papers, right up there with Dybvig's thesis, Rabbit and Orbit papers on Scheme, Reppy's thesis on Concurrent ML, and SPJ's Tagless paper.

The Zinc Experiment is Leroy at his best; compiler hacking lore meets programming language research (no hand-waving past performance issues, with a critical eye towards foundations.)

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#43

Post by kranner »

scott_s wrote: post #24
nene wrote: post #18

Earlier quoted context omitted.

I already have hard time parsing this code. The main problem I see, is that to read the code I have to know every single keywords in the language. For example I was wondering if "new" is a keyword. If it is, then "new string ()" might be something interesting, otherwise it's just a function call. Similarly this raises a question of whether I can write the following code: if end of line (str) This might or might not b…

I thought of the recognizing a keyword issue, but then I dismissed it: syntax highlighting make it a non-issue. The ambiguity with using keywords in identifiers is valid, though.

Syntax highlighting is not available everywhere, e.g. in black-and-white print.

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#45

Post by stcredzero »

jerf wrote: post #32
stcredzero wrote: post #31

Earlier quoted context omitted.

Actually, bytecodes for langs like Smalltalk can get you down to controlling all of your runtime state down to the level of bits. (Squeak actually runs bit-identical on something like 50 environments!) As for precisely what runtime instructions are executed, most of the time, we can consider this to be an implementation detail. In the case of superscalar processors, you can't necessarily tell me what order your assem…

You've really missed my point. I pretty much defined high level and low level by how they expanded out from simple instructions. You can't cite examples to prove this is wrong, by definition you've classified your definitions wrong. That this is not a universal definition doesn't bother me one little bit, because there is not universal definition of any non-trivial software engineering term.

Your definition classifies some widely recognized "high level" languages as low level.

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#46

Post by tianyicui »

kranner wrote: post #43
scott_s wrote: post #24

Earlier quoted context omitted.

I thought of the recognizing a keyword issue, but then I dismissed it: syntax highlighting make it a non-issue. The ambiguity with using keywords in identifiers is valid, though.

Syntax highlighting is not available everywhere, e.g. in black-and-white print.

Usually black-and-white print use bold to indicate the keywords.

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#47

Post by humbledrone »

I guarantee that I would confuse the types "byte" (uint8_t) and "octet" (int8_t). The typical distinction between a byte and an octet has to do with the number of bits in the representation (a byte usually has 8, an octet always has 8). I don't know of any convention for bytes being unsigned and octets being signed.

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#48

Post by speleding »

jerf wrote: post #10
psnj wrote: post #6

I 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.

That strikes me as giving lie to the "Ruby-like syntax" claim; ask a Ruby programmer what that line means and you will not get the correct answer for Zinc. 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…

Although I agree that it isn't really possible to have a "Ruby-like" syntax for a low level language since a lot of the syntax depends on Ruby being dynamic, it still seems like valid ambition, as long as you know that limitation.

I would love to have a form of C / C++ with iterators and blocks and without all the curly braces and assorted cruft like 5 different ascii symbols being used in 20 different contexts (actually, Ruby does that too, when will language designers start using a few additional symbols to improve cognitive load?).

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#49

Post by Retric »

jerf wrote: post #32
stcredzero wrote: post #31

Earlier quoted context omitted.

Actually, bytecodes for langs like Smalltalk can get you down to controlling all of your runtime state down to the level of bits. (Squeak actually runs bit-identical on something like 50 environments!) As for precisely what runtime instructions are executed, most of the time, we can consider this to be an implementation detail. In the case of superscalar processors, you can't necessarily tell me what order your assem…

You've really missed my point. I pretty much defined high level and low level by how they expanded out from simple instructions. You can't cite examples to prove this is wrong, by definition you've classified your definitions wrong. That this is not a universal definition doesn't bother me one little bit, because there is not universal definition of any non-trivial software engineering term.

If you want to redefine a commonly used term your doing something wrong. What you need to do is define a new term. Replace "High Level Languages" with "Abstract Languages" and nobody would have a problem with what you said. It might not mean anything, but at least it's clear. However, when you, redefine an existing term and you can be wrong and people will call you on it.

Re: Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

#50

Post by joubert »

humbledrone wrote: post #47

I guarantee that I would confuse the types "byte" (uint8_t) and "octet" (int8_t). The typical distinction between a byte and an octet has to do with the number of bits in the representation (a byte usually has 8, an octet always has 8). I don't know of any convention for bytes being unsigned and octets being signed.

You're right that with "byte" there isn't an official size specification, although the de facto size is 8 bits, unlike with "octet", which was specifically defined as 8 bits (for interoperability between different systems).

Regarding the question of signed/unsigned - I'll try to explain:

byte - unsigned

On page 37 of the C99 standard: "A byte contains CHAR_BIT bits, and the values of type unsigned char range from 0 to 2^CHAR_BIT - 1)"

i.e. according to the C99 standard, a byte is unsigned.

octet - signed

Think of an octet in two ways: the concept of something that is exactly 8-bits on the one hand, and on the other hand, the technical representation of this concept.

When you read the literature you'll notice that an octet refers simply to the size of something (8 bits) and not is signedness. For example, octets arguably arose in the networking world, and the NDR (Network Data Representation) refers to octet in sign-neutral way.

On page 256 of the C99 standard: "The typedef name int N _t designates a signed integer type with width N, no padding bits, and a two’s-complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits."

Now, how would you go about representing the concept of an "octet" (which is sign-neutral)? If you used an unsigned 8 bit integer, you can't represent the sign of the (conceptual) octet, while a signed 8 bit type can.

Post reply on HN