at is part of sys.path.
Thanks for any hints - Joachim
--
https://mail.python.org/mailman/listinfo/python-list
plemented. I use Python to build
models of IP cores to be integrated into ASICs and FPGAs. Not using
MyHDL for the actual core generation (yet) though.
- --
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
aven't found this way yet.
I'd like to know how others cope with these problems. Maybe I'm just
missing the obviuos.
--
Hans-Joachim Widmaier
--
http://mail.python.org/mailman/listinfo/python-list
My mistake seems to be that I declared
char a, b;
instead of
int a, b;
Thank you for sorting this out.
Joachim
--
http://mail.python.org/mailman/listinfo/python-list
In the Ubuntu 9.10 version of Python 3.1 (using your patch), there's a
related bug:
>>> foo(b='b')
will set the value of a in the extension module to zero, thus clearing
whatever
default value it may have had. In other words, the optional character
arguments
that are skipped seem to be nulled by
thanks - the patch fixed my problem.
Joachim
On Dec 1, 5:51 am, casevh wrote:
> On Nov 30, 2:18 pm, Joachim Dahl wrote:
>
>
>
>
>
> > I think that "C" encoding is what I need, however I run into an odd
> > problem.
> > If I use the following C
args, kwrds, "|CC", kwlist, &a,
&b))
return NULL;
...
then the following works:
>>> foo('a')
>>> foo('a','b')
>>> foo(a='a',b='b')
but the following fails:
>>> foo(b='b'
quot;c", kwlist,
&foochar))
return NULL;
...
The question remains the same: why can't I pass a single character
argument to this function under Python3.1?
Thanks.
Joachim
On Nov 30, 9:52 pm, Joachim Dahl wrote:
> I am updating an extension module from Python2.6 to Python3.
>
I am updating an extension module from Python2.6 to Python3.
I used to pass character codes to the extension module, for example, I
would write:
>>> foo('X')
with the corresponding C extension routine defined as follows:
static PyObject* foo(PyObject *self, PyObject *args, PyObject *kwrds)
{
ch
tion?
- --
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson
r[pixel]
>
> Returns an iterator that iterates over all the pixels in the image,
> starting from the top line and scanning each line from left to
> right.
> See below for a description of the pixel objects.
Ah! I knew there was a reason for me wearing glasses. ;-)
Go PEP368!
f someone wants to modify a file of a distribution he can recreate
> the checksum as well,
> the only secured way to prevent that would be to use gpg keys but
> isn't that overkill for what we need ?
Actually, adding this type of security would IMHO be a good idea.
- --
Med vänlig hälsnin
process in an orderly and well documented way.
- --
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aloha!
Richard Brodie wrote:
> "Joachim Str�mbergson" wrote in message
> news:mailman.2422.1246418400.8015.python-l...@python.org...
>
>> Even so, choosing md5 in 2009 for something that (hopefully) will be
>>
is that md5 and SHA-1 are weak. The computational complexity of SHA-256
is bigger, but since it probably wont be done many thousands of times
during an egg installation, it shouldn't add a noticable delay.
- --
Med vän
p://diveintopython.org/
A well written, easy to understand and fun (yes) introduction to all
fantastic things in Python.
- --
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
Kryptoblog - IT-sä
ten, well document
Python code looks like.
Check for yourself though at:
http://trac.edgewall.org/browser/trunk/trac
- --
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
Kryptoblog - IT
In Python2.x, I used PyFile_Check(obj) to check if a parameter was a
file object.
Now, in Python3.0 the same object (obtained as open('file.bin','wb'))
is an
io.BufferedWriter object.
How do I perform type checking for such an object in the extension
module,
and how do I extract a FILE * object f
Fabio Zadrozny wrote:
Has anyone been able to use both Pydev and CDT to debug extension
modules?
The question was asked about a year ago on this list, and I am hoping
that
someone has figured it out in meantime.
Previous answers on that:
https://sourceforge.net/forum/message.php?msg_id
Has anyone been able to use both Pydev and CDT to debug extension
modules?
The question was asked about a year ago on this list, and I am hoping
that
someone has figured it out in meantime.
Joachim
--
http://mail.python.org/mailman/listinfo/python-list
forum:
http://groups.google.com/group/cvxopt
best regards
Joachim
On Sep 17, 5:57 am, Fett <[EMAIL PROTECTED]> wrote:
> On Sep 16, 9:44 pm, "Aaron \"Castironpi\" Brady"
>
>
>
> <[EMAIL PROTECTED]> wrote:
> > On Sep 16, 9:25 pm, Fett <[EMA
Tim Roberts schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>
>>> Xah Lee <[EMAIL PROTECTED]> wrote:
>>>> [...] PHP and Perl are practically identical in their
>>>> high-levelness or expressiveness or field of application (and
>&g
> Xah Lee <[EMAIL PROTECTED]> wrote:
>> [...] PHP and Perl are practically identical in their
>> high-levelness or expressiveness or field of application (and
>> syntax),
That must have been a very, very distant point of view with narrowly
squinted eyes.
Regards,
Jo
--
http://mail.python.org/ma
John Thingstad schrieb:
> Skrev Joachim Durchholz <[EMAIL PROTECTED]>:
>
>> However, for web applications, I found a far easier variant: I just
>> reload the page being debugged. (I have to make sure that the backend
>> is in the same state when reloadi
Paul Rubin schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>> Indeed. An additional case is interactive applications where setting
>> up the situation to be tested requires several time-consuming steps.
>
> At least for web development, there are a lot of a
George Neuner schrieb:
> I know not everyone
> works in RT, but I can't possibly be alone in developing applications
> that are hard to restart effectively.
Indeed. An additional case is interactive applications where setting up
the situation to be tested requires several time-consuming steps.
R
I don't know all three languages, but I know you won't get a useful
answer unless you say what purpose you want to learn any of these
languages for. To expand your mental scope? To improve your CV? To use
as a new workhorse for your daily work? If it's the latter: what kind of
work do you do?
Marc Espie schrieb:
> Apart from the fact that Knuth wrote a book series that is still THE
> definitive series on computer algorithms
I don't wish to diminish Knuth's work, but it's definitely not timeless.
For an alternative, see Sedgewick's "Algorithms in C/Pascal/whatever".
Not as rigorous ab
Wildemar Wildenburger schrieb:
> Joachim Durchholz wrote:
>> And yes, it sucks in major ways.
>>
> Oh my God, I don't want to, but I just have to ask: Why?
First of all, irregularities.
http://en.wikipedia.org/wiki/TeX#The_typesetting_system:
"[...]almost all of TeX&#
George Neuner schrieb:
>> 5. This is arguable and trivial, but i think TeX judged as a computer
>> language in particular its syntax, on esthetical grounds, sucks in
>> major ways.
>
> No one except you thinks TeX is a "computer language".
But it is.
It's Turing-complete.
And yes, it sucks in maj
Lew schrieb:
> I am afraid that your conclusion is quite mistaken. Knuth is, if
> anything, a huge success in the field of software engineering, whether
> you rate it as making a contribution to the art, or as being paid to
> perform the art.
Well, sort of.
Some of the code given is unreadable
Twisted schrieb:
> On Jun 11, 5:36 pm, Tim Bradshaw <[EMAIL PROTECTED]> wrote:
>> I think it's just obvious that this is the case. What would *stop*
>> you writing maintainable Perl?
>
> For starters, the fact that there are about six zillion obscure
> operators represented by punctuation marks,
Twisted schrieb:
> On Jun 11, 2:42 am, Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>> It is possible to write maintainable Perl.
>
> Interesting (spoken in the tone of someone hearing about a purported
> sighting of Bigfoot, or maybe a UFO).
>
> Still, extraordinar
Twisted schrieb:
> After all, you can't really take a language seriously if
> it's either impossible to write unmaintainable code in it
That's true for any language.
Substitute "not straightforward" for "impossible", and you have a
condition that actually distinguishes languages.
> OR impossibl
Tim Peters schrieb:
>
> O() notation isn't being used
I was replying to Gabriel's post:
> In fact it's the other way - losing a factor of 2 is irrelevant,
> O(2N)=O(N). The logN factor is crucial here.
Regards,
Jo
--
http://mail.python.org/mailman/listinfo/python-list
Tim Peters schrieb:
> [Joachim Durchholz]
>>>> Wikipedia says it's going from 2NlogN to N. If a sort is massively
>>>> dominated by the comparison, that could give a speedup of up to 100%
>>>> (approximately - dropping the logN factor is almost irrelevan
Gabriel Genellina schrieb:
> At Tuesday 29/8/2006 07:50, Joachim Durchholz wrote:
>
>> Wikipedia says it's going from 2NlogN to N. If a sort is massively
>> dominated by the comparison, that could give a speedup of up to 100%
>> (approximately - dropping the logN fact
Jim Gibson schrieb:
>
> The problem addressed by what is know in Perl as the 'Schwartzian
> Transform' is that the compare operation can be an expensive one,
> regardless of the whether the comparison uses multiple keys. Since in
> comparison sorts, the compare operation will be executed N(logN) t
Marshall schrieb:
> No. The variable is the table, not the records.
In your examples, yes.
> Relations are not arrays.
They are, in all ways that matter for aliasing:
They are a collection of mutable data, accessible via selector values.
> Records are not lvalues.
Agreed, but they have identi
Marshall schrieb:
> Chris Smith wrote:
>> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>> I *think* I understand Marshall here. When you are saying "assignment",
>> you mean assignment to values of attributes within tuples of the cell.
>> When Marsha
Rob Warnock schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
> +---
> | INSERT cannot be expressed in terms of assignment. INSERT creates a new
> | record; there's no way that assignment in a language like C can create a
> | new data structure!
Chris Smith schrieb:
> David Hopwood <[EMAIL PROTECTED]> wrote:
>> Chris Smith wrote:
>>> If checked by execution, yes. In which case, I am trying to get my head
>>> around how it's any more true to say that functional languages are
>>> compilable postconditions than to say the same of imperativ
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> Good point. Perhaps I should have said "relational algebra +
>>> variables with assignment." It is interesting to consider
>>> assignment vs. the more restricted update operators: in
Marshall schrieb:
>
> Good point. Perhaps I should have said "relational algebra +
> variables with assignment." It is interesting to consider
> assignment vs. the more restricted update operators: insert,
> update, delete.
Actually I see it the other way round: assignment is strictly less
power
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> I would say, records in SQL have value, and their
>>> identity is exactly their value.
>>
>> Definitely not. You can have two equal records and update just one of
>> them, yieldin
Marshall schrieb:
> Joachim Durchholz wrote:
>> As I said elsewhere, the record has an identity even though it isn't
>> explicit in SQL.
>
> H. What can this mean?
>
> In general, I feel that "records" are not the right conceptual
> level to thin
Marshall schrieb:
> Joachim Durchholz wrote:
>> You can have aliasing without pointers; e.g. arrays are fully sufficient.
>> If i = j, then a [i] and a [j] are aliases of the same object.
>
> I am having a hard time with this very broad definition of aliasing.
> Would we
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> What about my example of SQL? Mutation, no pointers, no aliasing.
>>> Yet: useful.
>> Sorry, but SQL does have aliasing.
>
> Well. I suppose we do not have an agreed upon definition
&
Marshall schrieb:
> Joachim Durchholz wrote:
>> It's just that I know that it's viable to give up destructive updates.
>> Giving up pointers is a far more massive restriction.
>
> Oddly, I feel the opposite. While it's true there are many domains
> for w
Marshall schrieb:
> By your definition, "pointer" and "variable" are synonyms. That doesn't
> seem like a good idea to me. (What if i and j end up in registers?
> I have not heard it said that registers have addresses.)
There are no registers in the JVM ;-P
More specifically, where Joe said "poin
Marshall schrieb:
> void foo() {
> int i = 0;
> int j = 0;
> j = 1;
> i = 2;
> // check value of j here. It is still 1, no matter what you filled
> // in above.
> // The assignment to i cannot be made to affect the value of j.
> }
>
> Those two local primitive variables cannot be ma
Marshall schrieb:
> What about my example of SQL? Mutation, no pointers, no aliasing.
> Yet: useful.
Sorry, but SQL does have aliasing.
E.g. if you have records that have name="John", surname="Doe", the
statements
SELECT * FROM persons WHERE name = "John"
and
SELECT * FROM persons WHERE na
Marshall schrieb:
> Mutability by itself does not imply identity.
Well, the implication certainly holds from identity to mutability.
The only definition of identity that I found to hold up for all kinds of
references (pointers, shared-memory identifiers, URLs etc.) is this:
Two pieces of data ar
Marshall schrieb:
> David Hopwood wrote:
>> This property is, after all, not something that the program should depend on.
>> It is determined by how good the static checker currently is, and we want to
>> be
>> able to improve checkers (and perhaps even allow them to regress slightly in
>> order t
Darren New schrieb:
> Joachim Durchholz wrote:
>> Actually, in a functional programming language (FPL), you write just
>> the postconditions and let the compiler generate the code for you.
>
> Certainly. And my point is that the postcondition describing "all valid
>
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> Joachim Durchholz wrote:
>>>> Marshall schrieb:
>>>>> I can see the lack of a formal model being an issue, but is the
>>>>> imperative bit really all that much of an o
Darren New schrieb:
> There are also problems with the complexity of things. Imagine a
> chess-playing game trying to describe the "generate moves" routine.
> Precondition: An input board with a valid configuration of chess pieces.
> Postcondition: An array of boards with possible next moves for
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> I can see the lack of a formal model being an issue, but is the
>>> imperative bit really all that much of an obstacle? How hard
>>> is it really to deal with assignment? Or does the iss
Marshall schrieb:
> So, what exactly separates a precondition from a postcondition
> from an invariant? I have always imagined that one writes
> assertions on parameters and return values, and those
> assertions that only reference parameters were preconditions
> and those which also referenced ret
Marshall schrieb:
> I can see the lack of a formal model being an issue, but is the
> imperative bit really all that much of an obstacle? How hard
> is it really to deal with assignment? Or does the issue have
> more to do with pointers, aliasing, etc.?
Actually aliasing is *the* hard issue.
Just
Darren New schrieb:
> As far as I understand it, Eiffel compilers don't even make use of
> postconditions to optimize code or eliminate run-time checks (like null
> pointer testing).
That's correct.
I think a large part of the reasons why this isn't done is that Eiffel's
semantics is (a) too c
Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> Now, I'm not fully up to speed on DBC. The contract specifications,
>>> these are specified statically, but checked dynamically, is that
>>> right?
>> That's how it's done
Marshall schrieb:
> Now, I'm not fully up to speed on DBC. The contract specifications,
> these are specified statically, but checked dynamically, is that
> right?
That's how it's done in Eiffel, yes.
> In other words, we can consider contracts in light of
> inheritance, but the actual verificat
Marshall schrieb:
> Joachim Durchholz wrote:
>> Chris Smith schrieb:
>>> For example, I wrote that example using variables of type int. If we
>>> were to suppose that we were actually working with variables of type
>>> Person, then things get a little mo
Chris Smith schrieb:
> I think
> there's something fundamentally important about information hiding that
> can't be given up.
Indeed.
Without information hiding, with N entities, you have O(N^2) possible
interactions between them. This quickly outgrows the human capacity for
managing the inter
Chris Smith schrieb:
> For example, I wrote that example using variables of type int. If we
> were to suppose that we were actually working with variables of type
> Person, then things get a little more complicated. We would need a few
> (infinite classes of) derived subtypes of Person that fu
Andreas Rossberg schrieb:
> AFAICT, ADT describes a type whose values can only be accessed by a
> certain fixed set of operations. Classes qualify for that, as long as
> they provide proper encapsulation.
The first sentence is true if you associate a semantics (i.e. axioms)
with the operations.
Oliver Bandel schrieb:
> Matthias Blume wrote:
>
>> Tin Gherdanarra <[EMAIL PROTECTED]> writes:
>>
>>
>>> Oliver Bandel wrote:
>>>
こんいちわ Xah-Lee san ;-)
>>>
>>> Uhm, I'd guess that Xah is Chinese. Be careful
>>> with such things in real life; Koreans might
>>> beat you up for this. Stay alive
Chris Uppal schrieb:
> 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 Un
Matthias Blume schrieb:
> Erlang relies on a combination of purity, concurrency, and message
> passing, where messages can carry higher-order values.
>
> Data structures are immutable, and each computational agent is a
> thread. Most threads consist a loop that explicitly passes state
> around.
Tim Roberts schrieb:
> "Xah Lee" <[EMAIL PROTECTED]> wrote:
>> C ? No.
>
> 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
Paul Rubin schrieb:
> It starts to look like sufficiently powerful static type systems are
> confusing enough, that programming with them is at least as bug-prone
> as imperative programming in dynamically typed languages. The static
> type checker can spot type mismatches at compile time, but the
Anton van Straaten schrieb:
> Joachim Durchholz wrote:
>> Anton van Straaten schrieb:
>>> There's a close connection between latent types in the sense I've
>>> described, and the "tagged values" present at runtime. However, as
>>> type
Darren New schrieb:
> Marshall wrote:
>> Also: has subtyping polymorphism or not, has parametric polymorphism or
>> not.
>
> And covariant or contravariant.
That's actually not a design choice - if you wish to have a sound type
system, all input parameters *must* be contravariant, all output
pa
Andrew McDonagh schrieb:
> Joachim Durchholz wrote:
>> Chris Smith schrieb:
>>> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>>>> Sorry, I have to insist that it's not me who's stretching terms here.
>>>>
>>>> All textbook
Pascal Costanza schrieb:
>> Another observation: type safeness is more of a spectrum than a
>> clearcut distinction. Even ML and Pascal have ways to circumvent the
>> type system, and even C is typesafe unless you use unsafe constructs.
>> IOW from a type-theoretic point of view, there is no real
[EMAIL PROTECTED] schrieb:
> Gabriel Dos Reis wrote:
>> |
>> | (Unfortunately, you can hardly write interesting programs in any safe
>> | subset of C.)
>>
>> Fortunately, some people do, as living job.
>
> I don't think so. Maybe the question is what a "safe subset" consists
> of. In my book, it e
[EMAIL PROTECTED] schrieb:
> Joachim Durchholz write:
>> Another observation: type safeness is more of a spectrum than a clearcut
>> distinction. Even ML and Pascal have ways to circumvent the type system,
>
> No. I'm not sure about Pascal,
You'd have to use a
Chris Smith schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>> Sorry, I have to insist that it's not me who's stretching terms here.
>>
>> All textbook definitions that I have seen define a type as the
>> set/operations/axioms triple I mention
Andreas Rossberg schrieb:
>
> Luca Cardelli has given the most convincing one in his seminal tutorial
> "Type Systems", where he identifies "typed" and "safe" as two orthogonal
> dimensions and gives the following matrix:
>
> | typed | untyped
>---+---+--
>safe
Anton van Straaten schrieb:
>> It seems we have languages:
>> with or without static analysis
>> with or without runtime type information (RTTI or "tags")
>> with or without (runtime) safety
>> with or without explicit type annotations
>> with or without type inference
>>
>> Wow. And I don't think
Marshall schrieb:
> It seems we have languages:
> with or without static analysis
> with or without runtime type information (RTTI or "tags")
> with or without (runtime) safety
> with or without explicit type annotations
> with or without type inference
>
> Wow. And I don't think that's a complete
Anton van Straaten schrieb:
> Marshall wrote:
>> Can you be more explicit about what "latent types" means?
>
> Sorry, that was a huge omission. (What I get for posting at 3:30am.)
>
> The short answer is that I'm most directly referring to "the types in
> the programmer's head".
Ah, finally th
Darren New schrieb:
> John W. Kennedy wrote:
>> 360-family assembler, yes. 8086-family assembler, not so much.
>
> And Burroughs B-series, not at all. There was one "ADD" instruction, and
> it looked at the data in the addresses to determine whether to add ints
> or floats. :-)
I heard that the
mind if there exists a way of perfoming the computation that requires
>> tags, the tag was there and that tag has been eliminated.
>
> Joachim Durchholz replied:
>> On a semantic level, the tag is always there - it's the type (and
>> definitely part of an axiomatic defi
[EMAIL PROTECTED] schrieb:
> Joachim Durchholz wrote:
>> > A type is the encoding of these properties. A type
>>> varying over time is an inherent contradiction (or another abuse of the
>>> term "type").
>> No. It's just a matter of definition,
Dimitri Maziuk schrieb:
> That is the basic argument in favour of compile time error checking,
> extended to runtime errors. I don't really care if it's the compiler
> or runtime that tells the luser "your code is broken", as long as it
> makes it clear it's *his* code that's broken, not mine.
You
George Neuner schrieb:
> The point is really that the checks that prevent these things must be
> performed at runtime and can't be prevented by any practical type
> analysis performed at compile time. I'm not a type theorist but my
> opinion is that a static type system that could, a priori, preve
Andreas Rossberg schrieb:
> (Btw, Pascal did not have it either, AFAIK)
Indeed.
Some Pascal dialects have it.
Regards,
Jo
--
http://mail.python.org/mailman/listinfo/python-list
Andreas Rossberg schrieb:
> Joachim Durchholz 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
>
Marshall schrieb:
> immutable = can't change
> vary-able = can change
>
> Clearly a contradiction in terms.
Not in mathematics.
The understanding there is that a "variable" varies - not over time, but
according to the whim of the usage. (E.g. if a function is displayed in
a graph, the parameter
Andreas Rossberg schrieb:
> 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 *not*
> happen.
No. A type is a set of allowable values, allowable operations
Pascal Costanza schrieb:
> Static type systems potentially change the semantics of a
> language in ways that cannot be captured by dynamically typed languages
> anymore, and vice versa.
Very true.
I also suspect that's also why adding type inference to a
dynamically-typed language doesn't give
Matthias Blume schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>
>> Matthias Blume schrieb:
>>> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>>>
>>>> Matthias Blume schrieb:
>>>>> Perhaps better: A language is static
Chris Uppal schrieb:
> Chris Smith wrote:
>> I think Marshall got this one right. The two are accomplishing
>> different things. In one case (the dynamic case) I am safeguarding
>> against negative consequences of the program behaving in certain non-
>> sensical ways. In the other (the static ca
Pascal Costanza schrieb:
> (It's really important to understand that the idea is to use this for
> deployed programs - albeit hopefully in a more structured fashion - and
> not only for debugging. The example I have given is an extreme one that
> you would probably not use as such in a "real-wor
Matthias Blume schrieb:
> Joachim Durchholz <[EMAIL PROTECTED]> writes:
>
>> Matthias Blume schrieb:
>>> Perhaps better: A language is statically typed if its definition
>>> includes (or ever better: is based on) a static type system, i.e., a
>>> sta
Andreas Rossberg schrieb:
> Rob Thorpe wrote:
>> Hmm. You're right, ML is no-where in my definition since it has no
>> variables.
>
> Um, it has. Mind you, it has no /mutable/ variables, but that was not
> even what I was talking about.
Indeed. A (possibly nonexhaustive) list of program entitie
Chris F Clark schrieb:
> In that sense, a static type system is eliminating tags, because the
> information is pre-computed and not explicitly stored as a part of the
> computation. Now, you may not view the tag as being there, but in my
> mind if there exists a way of perfoming the computation th
Matthias Blume schrieb:
> Perhaps better: A language is statically typed if its definition
> includes (or ever better: is based on) a static type system, i.e., a
> static semantics with typing judgments derivable by typing rules.
> Usually typing judgmets associate program phrases ("expressions") w
1 - 100 of 121 matches
Mail list logo
