Gpc March 2016

gpc@gnu.de

12 participants
23 discussions

Inverse ord
by Paul Isaacs 07 Mar '16

07 Mar '16

Hello Waldek, Thanks, I should have looked longer and more carefully. I am retired now but spent my working years with micro/embedded processors. I want to keep my mind alive so I am setting forth to write a 10206 compliant compiler for embedded backends. Pascal should be a good fit for Arduino and Raspberry-Pi experimentalists. It is not as obscure as C and not as complex and picky as ADA. I am currently writing a 10206 compliant parser to produce a stream of lexically correct terminals from Pascal source. If I ever complete the lexical analysis, I will move on to semantically checking the results and producing a stream of intermediate opcodes for a backend. I know that I will need to feed extra information through the parser ( e.g. an "interrupt" directive for an interrupt procedure and "peek" and "poke" procedures for hardware I/O ) so I am looking for ways to do that and still be 10206 compliant. Thus the language lawyer interest. Thanks for your time. Maybe someday I will be able to make a contribution to the contributions section of the gpc web site. Regards, Paul Isaacs

1 0

Thanks
by Paul Isaacs 07 Mar '16

07 Mar '16

Hello Gale and Waldek, Thank you for your extensive replies. I will change over to using "gp". I notice that "inverse ord" is mentioned in the spec as an addition. However, other than a single mention, the spec is silent on inverse ord. Was such a thing implemented? The Gnu Pascal manual does not include the word "inverse". I would like to do a binary search on a set of keywords whose value is specified in a "TokenTypes" enumeration. The range of the array that stores the keywords and their value is the enumeration. Is it possible to compute the enumeration that is midway between two other enumerations? In other words is it possible to find an enumeration from its "ord" value? Regards, Paul Isaacs

2 1

Importing
by Paul Isaacs 07 Mar '16

07 Mar '16

Hello, I noticed that imports done outside the interface-specification-part are not dependency checked by --automake. This creates problems for first time gnu pascal uses such as myself. I started placing imports outside the interface-specification-part to avoid circular dependencies and it took a while to understand that --automake was no longer finding the import dependencies. I also assumed that the reason for the, rather awkward, multiple interface capability was to get around the module circular dependency problem. Ada resorted to the kludgy 'limited with' workaround. Gnu pascal seems to have resorted to the import 'in' workaround. However, having filenames in the source code does not seem to me to be a good idea. Would "import modulename_interfacename" work? The first '_' character would take on special meaning but the change would be 10602 specification compliant and having the module name and interface name combined into one identifier would eliminate the need for file names in the source code. Regards, Paul Isaacs

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc March 2016