Syntax, mark two
Oct. 3rd, 2006 10:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
I wish I could write in two or three languages at once. Witness the following hypothetical example which might be used to disassemble machine code:
Now compare with the Pascal I'd prolly have to write:
Uhhhhh... yeah.
This sort of want happens to me a lot. Can you count how many languages I've plagiarised? How about the number of features missing from C++ or Delphi?
Myself, I see a little Smalltalk, Lisp, C++, even Perl and (oh gods) INTERCAL. There are literal lists, tri-valued booleans, hashes, class fields, and closures with named parameters.
I know people are going to tell me, 'learn LISP.' And I would agree, but there needs to be an infix expression syntax for numerical work. Haskell is interesting that way, as it sort of has both.
The lack of closures alone pains me so much, I can't imagine why anyone would leave them out! I love them in JavaScript. JS also has some great LISPy structured literals. These really should be a standard language feature--literal code, structures, and arrays, just like literal numbers or strings.
I don't know there's any language that does what I want. That's the thing... they all have different strengths. It would be great to be able to use the right syntax/structure for the right problem.
Hurrrf. Guess I'll be expecting that right around the time programmers stop treating language and technique as religion...
(decoderGroup new: `x86ArithmeticRegOps memberWhen: `($code[0] ~ @00?????? && $code[0] !~ @00????11) memberIndex: `($code[0] takeBits: %00111000) members: [ADD OR ADC SBB AND SUB XOR CMP] details: [ `(if `($code[0] ~ @???????1) ($dataSize = [32 16] choose: (bits16 in $cpuMode ^^ toggleSize in $prefixes)) ($dataSize = 8) ) `($args = ($code[0] takeBits: %00000110) selectFrom: [ (ModRMArgs bytes: code[1..] dest: regOrMem src: reg) (ModRMArgs bytes: code[1..] dest: reg src: regOrMem) (ImmedArgs bytes: code[1..] dest: ([8:regAL 16:regAX 32:regEAX] choose: $dataSize)) ]) ])
Now compare with the Pascal I'd prolly have to write:
type TX86ArithRegOpDecoder = class(TX86Decoder) public function TryDecode(codes: String): TX86Instruction; override; end; function TX86ArithRegOpDecoder.TryDecode(codes: String): TX86Instruction; const arithOps: array[0..7] of TX86Operation = ( xopADD, xopOR, xopADC, xopSBB, xopAND, xopSUB, xopXOR, xopCMP ); begin Result := nil; if not ($00 <> codes[1] and $c0) or ($03 = codes[1] and $c3) then Exit; Result := TX86Instruction.Create; with Result do begin oper := arithOps[codes[1] shr 3 and 7]; if $00 = codes[1] and $01 then dataSize := 8 else if Boolean(Integer(bits16 in cpuMode) xor Integer(toggleSize in prefixes)) then dataSize := 16 else dataSize := 32; case codes[1] and $06 of $00: args := TX86ModRMArgs.Create(codes, argRegOrMem, argReg) $02: args := TX86ModRMArgs.Create(codes, argReg, argRegOrMem) $04: begin case Result.dataSize of 8: args := TX86ImmedArgs.Create(codes, argAL); 16: args := TX86ImmedArgs.Create(codes, argAX); 32: args := TX86ImmedArgs.Create(codes, argEAX); end; end; end; end; end;
Uhhhhh... yeah.
This sort of want happens to me a lot. Can you count how many languages I've plagiarised? How about the number of features missing from C++ or Delphi?
Myself, I see a little Smalltalk, Lisp, C++, even Perl and (oh gods) INTERCAL. There are literal lists, tri-valued booleans, hashes, class fields, and closures with named parameters.
I know people are going to tell me, 'learn LISP.' And I would agree, but there needs to be an infix expression syntax for numerical work. Haskell is interesting that way, as it sort of has both.
The lack of closures alone pains me so much, I can't imagine why anyone would leave them out! I love them in JavaScript. JS also has some great LISPy structured literals. These really should be a standard language feature--literal code, structures, and arrays, just like literal numbers or strings.
I don't know there's any language that does what I want. That's the thing... they all have different strengths. It would be great to be able to use the right syntax/structure for the right problem.
Hurrrf. Guess I'll be expecting that right around the time programmers stop treating language and technique as religion...