Joachim Durchholz wrote:
> > This is implementation-defined in C. A compiler is allowed to accept
> > variable names with alphabetic Unicode characters outside of ASCII.
>
> Hmm... that could would be nonportable, so C support for Unicode is
> half-baked at best.
Since the interpretation of char
Chris Smith wrote:
> Perhaps, if you wanted to be quite careful about your distinctions, you
> may want to choose different words for the two. However, then you run
> into that same pesky "you can't choose other people's terminology" block
> again.
There may be more flexibility in this area than
Chris Smith wrote:
> But then, I
> dislike discussion of strong/weak type systems in the first place. It
> doesn't make any sense to me to say that we verify something and then
> don't do anything if the verification fails. In those cases, I'd just
> say that verification doesn't really exist or
Marshall wrote:
[me:]
> > But, as a sort of half-way, semi-formal, example: consider the type
> > environment in a Java runtime. The JVM does formal type-checking of
> > classfiles as it loads them. In most ways that checking is static --
> > it's treating the bytecode as program text and doing
Andreas Rossberg wrote:
> So what you are suggesting may be an interesting notion, but it's not
> what is called "type" in a technical sense. Overloading the same term
> for something different is not a good idea if you want to avoid
> confusion and misinterpretations.
Frivolous response: the wor
Pascal Costanza wrote:
> Sorry, obviously I was far from being clear. ACL2 is not
> Turing-complete. All iterations must be expressed in terms of
> well-founded recursion.
How expressive does that end up being for real problems ? I mean obviously in
some sense it's crippling, but how much of a
Chris Smith wrote:
[me:]
> > I think we're agreed (you and I anyway, if not everyone in this thread)
> > that we don't want to talk of "the" type system for a given language.
> > We want to allow a variety of verification logics. So a static type
> > system is a logic which can be implemented bas
David Hopwood wrote:
> > But some of the advocates of statically
> > typed languages wish to lump these languages together with assembly
> > language a "untyped" in an attempt to label them as unsafe.
>
> A common term for languages which have defined behaviour at run-time is
> "memory safe". For
Anton van Straaten wrote:
> In that case, you could say that the conceptual type is different than
> the inferred static type. But most of the time, the human is reasoning
> about pretty much the same types as the static types that Haskell
> infers. Things would get a bit confusing otherwise.
O
Eliot Miranda wrote:
[me:]
> > Taking Smalltalk /specifically/, there is a definite sense in which it
> > is typeless -- or trivially typed -- in that in that language there are
> > no[*] operations which are forbidden[**],
>
> Come one Chris U. One has to distinguish an attempt to invoke an
> o
Andreas Rossberg wrote:
> Chris Uppal wrote:
> >
> > > > It's worth noting, too, that (in some sense) the type of an object
> > > > can change over time[*].
> > >
> > > No. Since a type expresses invariants, this is precisely what may
&g
Joe Marshall wrote:
> What we need is an FAQ entry for how to talk about types with people
> who are technically adept, but non-specialists. Or alternatively, an
> FAQ of how to explain the term `dynamic typing' to a type theorist.
You could point people at
"a regular series on object-orient
Chris Smith wrote:
> Some people here seem to be
> saying that there is a universal concept of "type error" in dynamic
> typing, but I've still yet to see a good precise definition (nor a good
> precise definition of dynamic typing at all).
How about this, at least as a strawman:
I think we're
I wrote:
> It would be interesting to see what a language designed specifically to
> support user-defined, pluggable, and perhaps composable, type systems
> would look like.
Since writing that I've come across some thoughts by Gilad Bracha (a Name known
to Java and Smalltalk enthusiasts alike) he
Andreas Rossberg wrote:
[me:]
> > It's worth noting, too, that (in some sense) the type of an object can
> > change over time[*].
>
> No. Since a type expresses invariants, this is precisely what may *not*
> happen. If certain properties of an object may change then the type of
> the object has to
Chris Smith wrote:
> > It would be interesting to see what a language designed specifically to
> > support user-defined, pluggable, and perhaps composable, type systems
> > would look like. [...]
>
> You mean in terms of a practical programming language? If not, then
> lambda calculus is used in
David Hopwood wrote:
> When people talk
> about "types" being associated with values in a "latently typed" or
> "dynamically typed" language, they really mean *tag*, not type.
I don't think that's true. Maybe /some/ people do confuse the two, but I am
certainly a counter-example ;-)
The tag (if
Darren New wrote:
[me:]
> > Personally, I would be quite happy to go there -- I dislike the idea
> > that a value has a specific inherent type.
>
> Interestingly, Ada defines a type as a collection of values. It works
> quite well, when one consistantly applies the definition.
I have never been v
Anton van Straaten wrote:
> But a program as seen by the programmer has types: the programmer
> performs (static) type inference when reasoning about the program, and
> debugs those inferences when debugging the program, finally ending up
> with a program which has a perfectly good type scheme. I
Chris Smith wrote:
> > Easy, any statically typed language is not latently typed.
>
> I'm actually not sure I agree with this at all. I believe that
> reference values in Java may be said to be latently typed. Practically
> all class-based OO
> languages are subject to similar consideration, as i
[apologies to the whole flaming crowd for sending this to the whole flaming
crowd...]
Geoffrey Summerhayes wrote:
> After you kill Navarth, will it be nothing but gruff and deedle
> with a little wobbly to fill in the chinks?
Where does that come from ? It sounds like a quote, and Navarth is a
Fred Gilham wrote:
> BTW, one time I tried a little social engineering to get rid of an
> irrelevant cross-posted thread. I replied to the messages in the
> thread (an irrelevant political thread posted in rec.audio.tubes) with
> (somewhat) inflammatory replies but deleted my newsgroup from the
>
Bill Atkins wrote:
> My favorite macro is ITERATE [...]
Thanks for the examples.
-- chris
--
http://mail.python.org/mailman/listinfo/python-list
Petr Prikryl wrote:
> for element in aCollection:
> if element > 0:
> return True
> return False
[I'm not sure whether this is supposed to be an example of some specific
language (Python ?) or just a generic illustration. I'll take it as the
latter, si
Pisin Bootvong wrote:
> Slippery Slope::
>"Argumentation that A is bad, because A might lead to B, and B
> to C, and we all know C is very bad."
For the Slippery Slope criticism to be applicable, there would have to be some
suggestion that removing anonymous functions /would actually/ (te
Alex Martelli wrote:
> I think it's reasonable to make a name a part of functions, classes and
> modules because they may often be involved in tracebacks (in case of
> uncaught errors): to me, it makes sense to let an error-diagnosing
> tracebacks display packages, modules, classes and functions/m
Bill Atkins wrote:
> But why should I have to worry about any of this? Why can't I do:
>
> (with-indentation (pdf (+ (indentation pdf) 4))
> (out-header)
> (out-facts))
>
> and then within, say out-facts:
>
> (with-indentation (pdf (+ (indentation pdf) 4))
> (write pdf "some tex
Tagore Smith wrote:
> It's much easier to use a killfile than to complain to an ISP, and I
> think that that should be the preferred response to messages you don't
> like.
I'm inclined to agree. The problem is not Xah Lee (whom I have killfiled), but
the people who insist on making my killfile u
28 matches
Mail list logo
