Are Python's reserved words reserved in places they dont need to be?

Discussion in 'Python' started by metaperl, Sep 12, 2006.

  1. metaperl

    metaperl Guest

    --> python -i
    >>> class = "algebra"

    File "<stdin>", line 1
    class = "algebra"
    ^
    SyntaxError: invalid syntax
    >>>



    Why isn' t the parser smart enough to see that class followed by an
    identifier is used for class definition but class followed by equals is
    a simple assignment?

    Also, I had a bug where I tried to set the attributes "user" and "pass"
    in an object but "pass" would not work because it is a reserved word.
    Again pass should be reserved in certain contexts but not others.

    Is Python 3k going to fix this sort of thing?
     
    metaperl, Sep 12, 2006
    #1
    1. Advertising

  2. Re: Are Python's reserved words reserved in places they dont needto be?

    metaperl schrieb:
    > --> python -i
    >>>> class = "algebra"

    > File "<stdin>", line 1
    > class = "algebra"
    > ^
    > SyntaxError: invalid syntax
    >
    >
    > Why isn' t the parser smart enough to see that class followed by an
    > identifier is used for class definition but class followed by equals is
    > a simple assignment?
    >
    > Also, I had a bug where I tried to set the attributes "user" and "pass"
    > in an object but "pass" would not work because it is a reserved word.
    > Again pass should be reserved in certain contexts but not others.


    Most parsers are written in a way that makes keywords reserved,
    regardless of their occurrence. That is because it is way easier to do
    so. And the few reserved words won't matter usually.

    > Is Python 3k going to fix this sort of thing?


    Don't think so.

    Diez
     
    Diez B. Roggisch, Sep 12, 2006
    #2
    1. Advertising

  3. "metaperl" <> wrote in message
    news:...

    > Why isn' t the parser smart enough to see that class followed by an
    > identifier is used for class definition but class followed by equals is
    > a simple assignment?


    Because it's simpler to reserve words than worry about possible
    ambiguities in all past and future use cases. If you could use it
    as an identifier, it wouldn't be a reserved word by the normal
    definition of the term.
     
    Richard Brodie, Sep 12, 2006
    #3
  4. metaperl wrote:
    > --> python -i
    > >>> class = "algebra"

    > File "<stdin>", line 1
    > class = "algebra"
    > ^
    > SyntaxError: invalid syntax


    Designing a syntax to avoid all possible newbie errors is impractical
    because as soon as you are finished with one iteration the new newbies
    will start making different kinds of errors...

    Take solace in the fact that you've been immediately notifed of the
    error while its fix: renaming pass to passwd is trivial ...

    i.
     
    Istvan Albert, Sep 12, 2006
    #4
  5. metaperl

    metaperl Guest

    Istvan Albert wrote:
    > metaperl wrote:
    > > --> python -i
    > > >>> class = "algebra"

    > > File "<stdin>", line 1
    > > class = "algebra"
    > > ^
    > > SyntaxError: invalid syntax

    >
    > Designing a syntax to avoid all possible newbie errors is impractical
    > because as soon as you are finished with one iteration the new newbies
    > will start making different kinds of errors...
    >
    > Take solace in the fact that you've been immediately notifed of the
    > error while its fix: renaming pass to passwd is trivial ...


    The error message is not very explicit - "class is a reserved word"
    will make far more sense to a new programmer than SyntaxError.
    Especially since the expression is rather innocent looking and
    correct-looking.
     
    metaperl, Sep 13, 2006
    #5
  6. metaperl

    metaperl Guest

    Diez B. Roggisch wrote:
    > metaperl schrieb:
    > > --> python -i
    > >>>> class = "algebra"

    > > File "<stdin>", line 1
    > > class = "algebra"
    > > ^
    > > SyntaxError: invalid syntax
    > >
    > >
    > > Why isn' t the parser smart enough to see that class followed by an


    > the few reserved words won't matter usually.


    woe be unto the ORMs who try to map database columns to Python
    attributes.
     
    metaperl, Sep 13, 2006
    #6
  7. metaperl

    metaperl Guest

    Istvan Albert wrote:
    > metaperl wrote:
    > > --> python -i
    > > >>> class = "algebra"

    > > File "<stdin>", line 1
    > > class = "algebra"
    > > ^
    > > SyntaxError: invalid syntax

    >
    > Designing a syntax to avoid all possible newbie errors is impractical
    > because as soon as you are finished with one iteration the new newbies
    > will start making different kinds of errors...


    You are missing the point: the point is that the above could be
    considered correct if the rules of Python were that an assignment
    statement takes
    IDENTIFIER '=' LVALUE

    Also "class" IDENTIFIER COLON could also be considered correct.

    >
    > Take solace in the fact that you've been immediately notifed of the
    > error while its fix: renaming pass to passwd is trivial ...


    Again in certain automatic mapping circumstances (ORMs being the most
    obvious, CSV to Python data another), it is not always convenient or
    desirable or semantically articulate to do so.

    >
    > i.
     
    metaperl, Sep 13, 2006
    #7
  8. metaperl

    Steve Holden Guest

    Re: Are Python's reserved words reserved in places they dont needto be?

    metaperl wrote:
    > Istvan Albert wrote:
    >
    >>metaperl wrote:
    >>
    >>>--> python -i
    >>>
    >>>>>>class = "algebra"
    >>>
    >>> File "<stdin>", line 1
    >>> class = "algebra"
    >>> ^
    >>>SyntaxError: invalid syntax

    >>
    >>Designing a syntax to avoid all possible newbie errors is impractical
    >>because as soon as you are finished with one iteration the new newbies
    >>will start making different kinds of errors...
    >>
    >>Take solace in the fact that you've been immediately notifed of the
    >>error while its fix: renaming pass to passwd is trivial ...

    >
    >
    > The error message is not very explicit - "class is a reserved word"
    > will make far more sense to a new programmer than SyntaxError.
    > Especially since the expression is rather innocent looking and
    > correct-looking.
    >

    Well maybe, but one might as well have the interpreter complain that
    '"=" is an invalid class name'. Once an unmatchable token is encountered
    which parsing it's often difficult from inside the parser to determine
    exactly what the programmer's intent was.

    Otherwise you could try and fix the error, like the PL/1 F-level
    compiler used to. This would usually work when all that was wrong was a
    missing semicolon, but it frequently went completely berserk in other
    cases, leading to strange and implausible error reports.

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://holdenweb.blogspot.com
    Recent Ramblings http://del.icio.us/steve.holden
     
    Steve Holden, Sep 13, 2006
    #8
  9. metaperl

    Robert Hicks Guest

    metaperl wrote:
    > Istvan Albert wrote:
    > > metaperl wrote:
    > > > --> python -i
    > > > >>> class = "algebra"
    > > > File "<stdin>", line 1
    > > > class = "algebra"
    > > > ^
    > > > SyntaxError: invalid syntax

    > >
    > > Designing a syntax to avoid all possible newbie errors is impractical
    > > because as soon as you are finished with one iteration the new newbies
    > > will start making different kinds of errors...

    >
    > You are missing the point: the point is that the above could be
    > considered correct if the rules of Python were that an assignment
    > statement takes
    > IDENTIFIER '=' LVALUE
    >
    > Also "class" IDENTIFIER COLON could also be considered correct.
    >


    Yes it could but it isn't and isn't likely to be. Simply do not use
    reserved words. That rule is hardly limited to Python.

    Robert
     
    Robert Hicks, Sep 13, 2006
    #9
  10. metaperl

    Cliff Wells Guest

    Re: Are Python's reserved words reserved in places they dont needto be?

    On Tue, 2006-09-12 at 18:05 -0700, Robert Hicks wrote:
    > metaperl wrote:
    > > Istvan Albert wrote:
    > > > metaperl wrote:
    > > > > --> python -i
    > > > > >>> class = "algebra"
    > > > > File "<stdin>", line 1
    > > > > class = "algebra"
    > > > > ^
    > > > > SyntaxError: invalid syntax
    > > >
    > > > Designing a syntax to avoid all possible newbie errors is impractical
    > > > because as soon as you are finished with one iteration the new newbies
    > > > will start making different kinds of errors...

    > >
    > > You are missing the point: the point is that the above could be
    > > considered correct if the rules of Python were that an assignment
    > > statement takes
    > > IDENTIFIER '=' LVALUE
    > >
    > > Also "class" IDENTIFIER COLON could also be considered correct.
    > >

    >
    > Yes it could but it isn't and isn't likely to be. Simply do not use
    > reserved words. That rule is hardly limited to Python.


    I'm surprised so many people misunderstand his complaint. It isn't as
    simple as "don't do it". The OP is referring to autogenerated code and
    attributes. This means you must tell the source of the generated items
    (perhaps a database table) that it can't have a column named "class" or
    "pass" or add hacks in to work around it (an easy one would be to prefix
    autogenerated attributes, which also helps work around the lack of
    private attributes in Python).

    Whether or not this should be changed is tangential to the OP's point.
    It must be a bit frustrating to state the obvious over and over and see
    it misinterpreted each time. Python has shortcomings. This is one of
    them, whether there's valid reasons for it or not. It's better to
    acknowledge it and offer something useful rather than "that isn't the
    Python way, don't do it."


    Cliff

    --
     
    Cliff Wells, Sep 13, 2006
    #10
  11. metaperl

    Carl Banks Guest

    metaperl wrote:
    > --> python -i
    > >>> class = "algebra"

    > File "<stdin>", line 1
    > class = "algebra"
    > ^
    > SyntaxError: invalid syntax
    > >>>

    >
    >
    > Why isn' t the parser smart enough to see that class followed by an
    > identifier is used for class definition but class followed by equals is
    > a simple assignment?


    Hmm. Someone called "metaPERL" is asking why Python doesn't have a
    more complicated grammar. Why does this not surprise me? :)

    Seriously, Python is that way deliberately. The developers consider it
    a good design to reserve keywords. It is not in any way considered a
    flaw, nor an oversight, nor a case of laziness.

    Besides, what you ask is impossible in general. Consider this code:

    return(1,2,3)

    Are you returning the tuple (1,2,3), or are you calling the function
    "return" with arguments 1,2,3? There is no context-free grammar in the
    universe that can divine which one is meant. It'd have to use context
    to even guess, and in a highly dynamic language like Python, you can
    never be wholly sure of the context. (Is there an identifier named
    "return" in scope? Don't know until you run the code...)


    > Also, I had a bug where I tried to set the attributes "user" and "pass"
    > in an object but "pass" would not work because it is a reserved word.
    > Again pass should be reserved in certain contexts but not others.
    >
    > Is Python 3k going to fix this sort of thing?


    Nope. PEP 3099 (which lists changes that won't be made in Python
    3000), states that the Python grammar will not be more complex than
    LL(1), and says that simple grammars are more desirable than complex
    ones. There is no hope of this being "fixed".

    In fact, the opposite is going to happen: the one keyword that can
    currently moonlight as a symbol, "as", is going to become a full-time
    keyword in Python 3000.


    > woe be unto the ORMs who try to map database columns to Python
    > attributes.


    A ha. First of all, consider whether you ought to be using dictionary
    keys instead. That is, columns["Name"] rather than columns.Name. It
    most cases keys are preferrable, because unless you know what the
    columns are ahead of time, you'll be using getattr and setattr to get
    at the attributes, which defeats the whole point of attributes. (And
    if you do know what the columns are ahead of time, no need to
    automatically map the names.)

    The one legitimate use case I can think of for wanting to use
    attributes instead of keys is if you intend to have user-supplied
    Python code operating on the columns (and even then you should consider
    whether the user would be better off using keys). In this case you're
    pretty much stuck with workarounds.

    You can automatically rename any keywords when mapping the column
    names, and advise the user that colums with keyword names will have
    (for example) and appended underscore:

    import keyword

    def column_attribute_name(name):
    if keyword.iskeyword(name):
    return "%s_" % name
    return name


    Carl Banks
     
    Carl Banks, Sep 13, 2006
    #11
  12. metaperl <> wrote:

    Yes, keywords are always reserved. The one major language that tried to
    do otherwise was PL/I, where you could code, e.g.:

    if if = if then then = else else else = if

    ((of course, '=' was also polimorpically read as either assignment OR
    comparison -- I gather that most Basic dialects still do that!-)).

    IBM (PL/I's inventor and rabid defender) found out the hard way that
    making the parser more complicated, slow and bug-prone in order to allow
    such absurd obfuscation was NOT a popular trade-off -- despite IBM's
    alleged monopoly power, PL/I is now basically dead while the older,
    crankier languages that PL/I wanted to replace, Cobol and particularly
    Fortran, are still quite alive (and with reserved words ALWAYS reserved
    -- like in C, Python, Java, C#, Haskell, and basically every language
    that's even halfway sensible;-).


    > Is Python 3k going to fix this sort of thing?


    Fortunately not, or we'd all be busy studying Ruby or Boo!-)


    Alex
     
    Alex Martelli, Sep 13, 2006
    #12
  13. metaperl <> wrote:

    > Diez B. Roggisch wrote:
    > > metaperl schrieb:
    > > > --> python -i
    > > >>>> class = "algebra"
    > > > File "<stdin>", line 1
    > > > class = "algebra"
    > > > ^
    > > > SyntaxError: invalid syntax
    > > >
    > > >
    > > > Why isn' t the parser smart enough to see that class followed by an

    >
    > > the few reserved words won't matter usually.

    >
    > woe be unto the ORMs who try to map database columns to Python
    > attributes.


    I'm gonna skip my usual anti-ORM rant, because there ARE valid case for
    "mapping external names to Python identifiers" -- e.g., remote protocols
    such as XML-RPC, automatic constructers of FF interfaces, etc. Such
    code generators -- targeting ANY language currently alive -- obviously
    have to possess some minimal knowledge of the target language's syntax,
    and the obvious solution is to systematically transform identifiers
    which would otherwise be keywords. The one most popular convention is
    to append an underscore -- so that 'pass' becomes 'pass_', and so on.


    Alex
     
    Alex Martelli, Sep 13, 2006
    #13
  14. Re: Are Python's reserved words reserved in places they dont need to be?

    Steve Holden <> wrote:

    > Otherwise you could try and fix the error, like the PL/1 F-level
    > compiler used to. This would usually work when all that was wrong was a
    > missing semicolon, but it frequently went completely berserk in other


    Ah, yeah, I forgot that particularly endearing aspect of PL/I (to go
    with the language having no keywords) -- many compilers bent over
    backwards to double-guess what you meant, resulting in deep
    misunderstandings by many programmers about what the language was
    SUPPOSED to be, mysterious error messages and (worse!) program
    misbehavior, etc etc -- all, of course, at the price of making the
    compilers ever more intricate, bug-prone, extremely heavy in resource
    cosumption, slow, and laughably bad at optimization (when compared to
    compilers of the same era for sensibly SIMPLE languages, such as
    Fortran).

    Thanks for reviving the memories: it makes me SO ineffably glad that
    nowadays I'm using a language which, among its guiding principles, has
    "in the face of ambiguity, refuse the temptation to guess"!!!-)


    Alex
     
    Alex Martelli, Sep 13, 2006
    #14
  15. metaperl

    Roy Smith Guest

    In article <1hlkidf.fm1voc1b64uy5N%>,
    (Alex Martelli) wrote:

    > metaperl <> wrote:
    >
    > > Diez B. Roggisch wrote:
    > > > metaperl schrieb:
    > > > > --> python -i
    > > > >>>> class = "algebra"
    > > > > File "<stdin>", line 1
    > > > > class = "algebra"
    > > > > ^
    > > > > SyntaxError: invalid syntax
    > > > >
    > > > >
    > > > > Why isn' t the parser smart enough to see that class followed by an

    > >
    > > > the few reserved words won't matter usually.

    > >
    > > woe be unto the ORMs who try to map database columns to Python
    > > attributes.

    >
    > I'm gonna skip my usual anti-ORM rant, because there ARE valid case for
    > "mapping external names to Python identifiers" -- e.g., remote protocols
    > such as XML-RPC, automatic constructers of FF interfaces, etc. Such
    > code generators -- targeting ANY language currently alive -- obviously
    > have to possess some minimal knowledge of the target language's syntax,
    > and the obvious solution is to systematically transform identifiers
    > which would otherwise be keywords. The one most popular convention is
    > to append an underscore -- so that 'pass' becomes 'pass_', and so on.
    >
    >
    > Alex
    >


    Also, keywords are only reserved in the context of identifiers. They can
    certainly appear as string literals used as dictionary keys:

    attributes["class"] = "algebra"
     
    Roy Smith, Sep 13, 2006
    #15
  16. metaperl

    Carl Banks Guest

    Alex Martelli wrote:

    > IBM (PL/I's inventor and rabid defender) found out the hard way that
    > making the parser more complicated, slow and bug-prone in order to allow
    > such absurd obfuscation was NOT a popular trade-off -- despite IBM's
    > alleged monopoly power, PL/I is now basically dead while the older,
    > crankier languages that PL/I wanted to replace, Cobol and particularly
    > Fortran, are still quite alive (and with reserved words ALWAYS reserved
    > -- like in C, Python, Java, C#, Haskell, and basically every language
    > that's even halfway sensible;-).


    Except Fortran doesn't have any reserved words either:

    PROGRAM KWDS
    REAL REAL,WRITE
    WRITE=1.0
    REAL=2.0
    WRITE(*,*)WRITE,REAL
    END

    (Not sure whether it's true in Fortran 9x.)


    Carl Banks
     
    Carl Banks, Sep 13, 2006
    #16
  17. metaperl

    Roy Smith Guest

    In article <>,
    "Carl Banks" <> wrote:

    > Alex Martelli wrote:
    >
    > > IBM (PL/I's inventor and rabid defender) found out the hard way that
    > > making the parser more complicated, slow and bug-prone in order to allow
    > > such absurd obfuscation was NOT a popular trade-off -- despite IBM's
    > > alleged monopoly power, PL/I is now basically dead while the older,
    > > crankier languages that PL/I wanted to replace, Cobol and particularly
    > > Fortran, are still quite alive (and with reserved words ALWAYS reserved
    > > -- like in C, Python, Java, C#, Haskell, and basically every language
    > > that's even halfway sensible;-).

    >
    > Except Fortran doesn't have any reserved words either:
    >
    > PROGRAM KWDS
    > REAL REAL,WRITE
    > WRITE=1.0
    > REAL=2.0
    > WRITE(*,*)WRITE,REAL
    > END
    >
    > (Not sure whether it's true in Fortran 9x.)
    >
    >
    > Carl Banks


    As I remember, you didn't need the whitespace either. IIRC, your example
    above could have been written as:

    PROGRAMKWDS
    REALREAL,WRITE
    WRITE=1.0
    REAL=2.0
    WRITE(*,*)WRITE,REAL
    END

    and worked just as well. I have nightmares thinking about writing a
    fortran parser. Oh yeah, spaces were the same as zeros on input, too.
    What a wonderful language.

    Isn't it wonderful how nothing you write ever gets lost once google gets
    it's hands on it:

    http://mirrorspace.org/python/doc/humor/index.html#habits

    (personally, I think the one about the little girl buying a wabbit in the
    pet store is the best of the collection).
     
    Roy Smith, Sep 13, 2006
    #17
  18. metaperl

    Paddy Guest

    Cliff Wells wrote:
    > On Tue, 2006-09-12 at 18:05 -0700, Robert Hicks wrote:
    > > metaperl wrote:
    > > > Istvan Albert wrote:
    > > > > metaperl wrote:
    > > > > > --> python -i
    > > > > > >>> class = "algebra"
    > > > > > File "<stdin>", line 1
    > > > > > class = "algebra"
    > > > > > ^
    > > > > > SyntaxError: invalid syntax
    > > > >
    > > > > Designing a syntax to avoid all possible newbie errors is impractical
    > > > > because as soon as you are finished with one iteration the new newbies
    > > > > will start making different kinds of errors...
    > > >
    > > > You are missing the point: the point is that the above could be
    > > > considered correct if the rules of Python were that an assignment
    > > > statement takes
    > > > IDENTIFIER '=' LVALUE
    > > >
    > > > Also "class" IDENTIFIER COLON could also be considered correct.
    > > >

    > >
    > > Yes it could but it isn't and isn't likely to be. Simply do not use
    > > reserved words. That rule is hardly limited to Python.

    >
    > I'm surprised so many people misunderstand his complaint. It isn't as
    > simple as "don't do it". The OP is referring to autogenerated code and
    > attributes. This means you must tell the source of the generated items
    > (perhaps a database table) that it can't have a column named "class" or
    > "pass" or add hacks in to work around it (an easy one would be to prefix
    > autogenerated attributes, which also helps work around the lack of
    > private attributes in Python).
    >
    > Whether or not this should be changed is tangential to the OP's point.
    > It must be a bit frustrating to state the obvious over and over and see
    > it misinterpreted each time. Python has shortcomings. This is one of
    > them, whether there's valid reasons for it or not. It's better to
    > acknowledge it and offer something useful rather than "that isn't the
    > Python way, don't do it."
    >
    >
    > Cliff
    >
    > --

    Hi Cliff, You would also not be allowed to have a column name with a
    space,comma,*,;,... in them. It might be best to assume that column
    headings might end up with any arbitrary unicode character string and
    program from that.
    If the OP knows the full extent of his input data and knows that column
    names are valid identifiers PLUS Python reserved words then yes, It
    stops him from autogenerating identifiers in tht way - but others in
    this thread have suggested work-arounds.

    And yes, Python is not perfect, but its sweet spot is oh so tasty :)

    (Which also applies to AWK, for a different sweet flavour)

    - Paddy.
     
    Paddy, Sep 13, 2006
    #18
  19. On Tue, 12 Sep 2006 23:49:09 -0400, Roy Smith <> declaimed
    the following in comp.lang.python:

    > and worked just as well. I have nightmares thinking about writing a
    > fortran parser. Oh yeah, spaces were the same as zeros on input, too.


    Especially parsing something like

    D O1 0 L=3 . 14 15 9
    vs
    D O1 0 L=3 , 14 15 9
    --
    Wulfraed Dennis Lee Bieber KD6MOG

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
     
    Dennis Lee Bieber, Sep 13, 2006
    #19
  20. On 2006-09-13, Carl Banks <> wrote:
    > metaperl wrote:
    >> --> python -i
    >> >>> class = "algebra"

    >> File "<stdin>", line 1
    >> class = "algebra"
    >> ^
    >> SyntaxError: invalid syntax
    >> >>>

    >>
    >>
    >> Why isn' t the parser smart enough to see that class followed by an
    >> identifier is used for class definition but class followed by equals is
    >> a simple assignment?

    >
    > Hmm. Someone called "metaPERL" is asking why Python doesn't have a
    > more complicated grammar. Why does this not surprise me? :)


    Would a solution for this always make the grammer more complicated?

    > Seriously, Python is that way deliberately. The developers consider it
    > a good design to reserve keywords. It is not in any way considered a
    > flaw, nor an oversight, nor a case of laziness.
    >
    > Besides, what you ask is impossible in general. Consider this code:
    >
    > return(1,2,3)


    This is just an idea of mine, nothing I expect python to adapt.
    But just suppose the language allowed for words in bold. A word
    in bold would be considered a reserved word, a word in non bold
    would be an identifier.

    > Are you returning the tuple (1,2,3), or are you calling the function
    > "return" with arguments 1,2,3? There is no context-free grammar in the
    > universe that can divine which one is meant. It'd have to use context
    > to even guess, and in a highly dynamic language like Python, you can
    > never be wholly sure of the context. (Is there an identifier named
    > "return" in scope? Don't know until you run the code...)


    With my idea, you would just look whether "return" was written in
    bold or not.

    >> Also, I had a bug where I tried to set the attributes "user" and "pass"
    >> in an object but "pass" would not work because it is a reserved word.
    >> Again pass should be reserved in certain contexts but not others.
    >>
    >> Is Python 3k going to fix this sort of thing?

    >
    > Nope. PEP 3099 (which lists changes that won't be made in Python
    > 3000), states that the Python grammar will not be more complex than
    > LL(1), and says that simple grammars are more desirable than complex
    > ones. There is no hope of this being "fixed".


    This idea won't make python more complex than LL(1).

    --
    Antoon Pardon
     
    Antoon Pardon, Sep 13, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Miel Bronneberg

    reserved words

    Miel Bronneberg, Nov 26, 2004, in forum: XML
    Replies:
    1
    Views:
    548
    Martin Honnen
    Nov 26, 2004
  2. Delaney, Timothy (Tim)
    Replies:
    10
    Views:
    688
    Jason
    Sep 14, 2006
  3. Steve Holden
    Replies:
    0
    Views:
    403
    Steve Holden
    Sep 13, 2006
  4. Tricky

    Newer reserved words

    Tricky, Dec 2, 2008, in forum: VHDL
    Replies:
    2
    Views:
    628
  5. Replies:
    3
    Views:
    189
    osmium
    Nov 6, 2013
Loading...

Share This Page