 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16-10-2010 4:51, nemesis wrote:
> Orchid XP v8<voi### [at] dev null> wrote:
>> Oh wow. 42 years later, it still exists:
>>
>> http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF
>>
>> "Go to considered harmful."
>
> a classic! I'm glad you've been interested in the evolution of programming
> formalisms -- and all by yourself! Next on, the lambda papers! ;)
>
>> I also note, with some interest, what looks suspiciously like Haskell
>> syntax, in a letter typed 42 years ago. Obviously it's not after
>> Haskell, but rather whatever mathematical formalism Haskell borrowed the
>> notation from. Still, interesting none the less...)
>
> bwahahahaha
>
> you must be talking about `conditional expressions as introduced by J.McCarthy
> ("B1 -> E1, B2 -> E2,....., Bn -> En")'... although it looks like currying
> haskell notation, it's actually what it's told: John McCarthy's conditional
> expressions for Lisp!
>
> (cond
> ((null? ls) 0)
> ((zero? (car ls)) 0)
> (#t (/ n (car ls))))
>
> cond was blowderized and adapted to all other programming languages in the
> simplified form if-then-else... even Lisp provides it as well as cond!
Dijkstra's guarded commands does not have a if-then-else, I know it is a
rather obscure language, but not in this context.
I find the if-then-else case interesting because it shows so clearly
that there was a trade off between having a language that has some
relation to maths and one that is understandable for below average IQ
humans*. Dijstra's version, the McCarthy version he mentions here and
the LISP version all are homologues of the disjuction. If-then-else is
more like human reasoning using a decision tree. I am not surprised that
the latter is the more common now, but I don't think I am happy with it.
*) there is also that if-then-else is more close to the conditional jump
of most processors at the machine level, but mentioning that might spoil
my point.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> If you see something like this in C++:
> void foo()
> {
> FILE* infile = std::fopen("file.txt", "r");
> then you should immediately see "DANGER! DANGER!", because whatever follows
> that will *not* be exception-safe (well, not unless the very next line is
> 'try').
By the way, I honestly wonder what's the "proper" way of doing that
in Java, given that Java has exceptions and no scope-bound lifetime of
objects. Do you always have to follow file handle creation with a 'try'
block to guard against exceptions? Or is there some other trick to make
such code exception-safe?
(I understand that in C# this is handled with a 'using' block, which
automatically and immediately disposes of objects when the block is
exited. Is that the proper way of making file handles exception-safe
there?)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> But, it only gets worse when some joker does what was done in a few
> versions of basic
Roll back to when BASIC actually was edited line by line, with line numbers
and all that, and the only form of the IF statement was
300 IF Z < W THEN 500 ELSE 800
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Maybe the fact that C++ basically removed the need for manual cleanup of
> resources (if you use its constructs properly) made it much safer and
> cleaner to use early returns.
Exactly the point I'm making. In C++, "return" doesn't mean return from the
function any more. It means basically "branch to all the clean-up code for
anything allocated in any of the scopes I'm nested in." :-)
> If you see something like this in C++:
Yep. Rather than "checked and unchecked exceptions", I think Java (and C#)
would have been better off issuing warnings or errors for potential leaks of
disposable items.
If you have a file handle in C#, you're supposed to put it inside a "using"
so it gets closed if you exit the scope.
using (FileHandle handle = File.Open(...))
{
handle.read(); handle.write(); ...
}
Any time you exit the block after you've created the file handle, it'll get
cleaned up (in the sense that the Dispose call will be made). Kind of
poor-man's C++ destructors. If they were going to do that, they should have
put in some mechanism to keep you from accidentally making a handle (or
anything else that inherits Disposable) without clearly disposing it.
Sing# does something much like this by basically making it so that kind of
object can't get assigned to more than one variable at once (i.e., you can't
have two pointers/references to the same value), and it tracks and enforces
this at compile time. So "File.Open" would declare it returns a new file
handle, "File.Close" would declare it consumes the handle, and everything in
between would be unable to overwrite it or copy it or whatever (outside of,
of course, passing it to subroutines, etc).
The destructor semantics is one of the things I think C++ really did get
just right. It's really all the C compatibility that makes it awkward, I find.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> By the way, I honestly wonder what's the "proper" way of doing that
> in Java, given that Java has exceptions and no scope-bound lifetime of
> objects.
try {
handle = open(...);
} finally {
if (handle != null) handle.close();
}
Even uglier because you obviously have to declare the handle outside the
block, check to see if the assignment worked, etc.
> Do you always have to follow file handle creation with a 'try'
> block to guard against exceptions? Or is there some other trick to make
> such code exception-safe?
try/finally is what you use for making code exception safe.
> (I understand that in C# this is handled with a 'using' block, which
> automatically and immediately disposes of objects when the block is
> exited. Is that the proper way of making file handles exception-safe
> there?)
Yep. You're basically supposed to put anything with a "Dispose" method
inside a using block. (Well, unless you're assigning it to something more
global, etc.) More elegant than Java, but certainly not elegant, especially
since it's not always obvious what classes have a Dispose method without
reading the documentation, so it's easy to miss something if you're working
with a new library.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> and everything in between would be unable to overwrite it or
> copy it or whatever (outside of, of course, passing it to subroutines,
> etc).
Well, not quite. I mean, there are a lot of rules making it usable, but
they're the obvious rules. (You can overwrite the value with a newly
allocated value if you dispose of the old value in the same routine, etc.)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Yeah, I was trying to remember some of the others. Something perl-like,
> certanily (python, Perl, bash, Tcl, etc).
python, perl and tcl are very unlike each other despite the scripting moniker.
While I dig python better for the crystal-crisp syntax and iteration constructs,
perl is much more formidable as far as plain linguistic flexibility goes... it
truly is a marvel to behold in all of its C, shell, Lisp, forth summarizing of
ideas goes...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Yeah, I was trying to remember some of the others. Something perl-like,
>> certanily (python, Perl, bash, Tcl, etc).
>
> python, perl and tcl are very unlike each other despite the scripting moniker.
Fairly so, yes. But the concepts of a "scripting language" (i.e., the
primary data structure being a hashtable, the idea that "evaluating a
definition" is pretty much what creates code rather than strictly
compilation, the baroque scoping rules, etc) is what's more important than
the fact that (for example) regex is a literal in Perl and not in the others.
> truly is a marvel to behold in all of its C, shell, Lisp, forth summarizing of
> ideas goes...
Errr, Perl has something to do with FORTH? You'll have to clarify that one,
because, like, it really doesn't, as far as I can tell.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Yeah, I was trying to remember some of the others. Something perl-like,
> >> certanily (python, Perl, bash, Tcl, etc).
> >
> > python, perl and tcl are very unlike each other despite the scripting moniker.
>
> Fairly so, yes. But the concepts of a "scripting language" (i.e., the
> primary data structure being a hashtable, the idea that "evaluating a
> definition" is pretty much what creates code rather than strictly
> compilation, the baroque scoping rules, etc) is what's more important than
> the fact that (for example) regex is a literal in Perl and not in the others.
regex is a literal in ruby too. I also like perl scoping with my and our. :)
> > truly is a marvel to behold in all of its C, shell, Lisp, forth summarizing of
> > ideas goes...
>
> Errr, Perl has something to do with FORTH? You'll have to clarify that one,
> because, like, it really doesn't, as far as I can tell.
like forth, it doesn't need to operate on named arguments, which is taken then
to be the first in the "stack"... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> The destructor semantics is one of the things I think C++ really did get
> just right.
The proper name for that mechanism would be "RAII" (which might be
somewhat of a misnomer, as it doesn't fully express what it means).
(In principle RAII is not incompatible with garbage collection, so
conceivably you could have both in the same language.)
According to wikipedia, C++ is not the only language using RAII, and
mentions Ada as another one. I didn't know that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
