On 14 May 2015, at 18:50, William Squires wrote:
> Swift shows promise, but - like all computer languages - it's a trade-off
> between generated code side, and the amount of abstraction the language
> presents to those using it, making it easier to turn ideas into code. Making
> a (more abstra
> On May 15, 2015, at 10:12 AM, Scott Ribe wrote:
>
> As in the olden days of OS 9 & before, when you could freely read & write
> through location 0, usually leading to great hilarity…
Especially since the 68k CPU interrupt vectors were stored in low memory a few
bytes from 0, so a memcpy or
On May 15, 2015, at 11:06 AM, Kyle Sluder wrote:
>
> It's not valid to dereference a null pointer, but what happens when you
> do is undefined.
As in the olden days of OS 9 & before, when you could freely read & write
through location 0, usually leading to great hilarity…
--
Scott Ribe
scott_
On Fri, May 15, 2015, at 11:31 AM, Jens Alfke wrote:
> Yes, but when you evaluate (cdr nil) doesn’t the interpreter trigger an
> exception? (Sorry, it’s been decades since I used LISP.) Similarly, in
> Smalltalk-80 ‘null’ is a real object, a singleton of class
> UndefinedObject, but trying to messa
> On May 15, 2015, at 4:34 AM, has wrote:
>
> Lisp has a `nil` object. That's not the same thing as a nil pointer. The
> first is an actual Thing; the second is a promise to give you a thing that
> instead drops you down a hole when you actually ask for it.
Yes, but when you evaluate (cdr nil
Jens Alfke wrote:
> Which is to say that, if you really want to engage in productive
debate or provide alternatives, you should spend some time learning the
theory behind languages and also looking at non-C-like languages,
especially functional ones.
This. C doesn't even have a typesystem: j
With all due respect, I think you’re falling into the common engineer pitfall
of jumping to the conclusion that there’s a trivial solution without first
understanding the problem. (Sometimes expressed as “any bug in your program is
trivial; any bug I have to fix is intractable.”) Which is to say
On May 14, 2015, at 10:52 , Kyle Sluder wrote:
>
> FWIW, NSNotFound is defined as NSIntegerMax, so it has the same value in
> both signed and unsigned contexts.
a. Oh, yeah, I knew that.
b. It kinda proves my point, though. I write enough Obj-C code that I shouldn’t
confuse myself about this,
On Thu, May 14, 2015, at 12:34 PM, Quincey Morris wrote:
> — It’s used in both signed and unsigned contexts, so it really has 2
> values
FWIW, NSNotFound is defined as NSIntegerMax, so it has the same value in
both signed and unsigned contexts.
--Kyle Sluder
_
On May 14, 2015, at 09:50 , William Squires wrote:
>
> Have the compiler/linker enforce that all variables are initialized to zero
> (Int, Float, Double), false (Bool), empty (String, array, dictionary), or nil
> (object reference) if the coder doesn't specify them. (in the case of an
> enume
or, to put it another way; "optional Optionals, a better " :)
Option 1 (1?):
Have the compiler/linker enforce that all variables are initialized to zero
(Int, Float, Double), false (Bool), empty (String, array, dictionary), or nil
(object reference) if the coder doesn't specif
11 matches
Mail list logo
