Re: Eu vs perl
David Cuny wrote:
>Everett Williams wrote:
>
>> The problem with programmer added prefixes is that they
>> are static and do not allow for multiple occurrences. If I have
>> a structure that describes a file, I may have three files with
>> the same structure open at the same time.
>
>I've used two different ways to deal with this. I can create a 'generic'
>sequence to hold everything:
snip
>
>Not entirely elegant, but it gets the job done. That's the approach Llama
>took. The double indexing is expensive, and using Get/Set makes it more so.
>Llama was rightly criticized as having a lot of overhead in the data
>structures.
>
>In my new toolkit, I take a slightly different approach:
>
> sequence name, ssn
> name = {}
> ssn = {}
>
> function newItem()
> name = append( name, "" )
> ssn = append( ssn, "" )
> return length( name )
> end function
>
>Working with objects is now:
>
> constant Fred = newItem()
> constant Joe = newItem()
>
> name[Fred] = "Fred"
> ssn[Fred] = "000-00-0000"
>
> name[Joe] = "Joe"
> ssn[Joe] = "111-11-1111"
A beautifully elegant way to be stuck at another static level. I must declare
a constant for each occurrence of the structure. The use of one sequence
per "field" is certainly a solution to the reference problem. Now, when I
wish to assemble the structure for IO, I must do just that...assemble it
one piece at a time.
>> Constants are not necessary in a "minimalist"
>> language.
>
>I don't share this dislike of constants. Writing:
>
> the[SSN]
>
>makes a lot more sense than:
>
> the[3]
Absolutely...anything that puts a name in place of a number where the
number is not directly indicative of relative occurrence is a positive. It still
is deceptive and causes much unneeded overhead. Now, there is the
germ of an idea here. If I could declare structures and have constants
implicitly assigned to the elements, I could use the[SSN] as a
substitute for prefixing in referencing fields. I'd still have to build "the" up
manually, but that is not overly difficult. If that were joined with my
null structures with initialization, It would produce less violence to the
current syntax. I don't see how it would deal with the namespace problem
and the collision of namespaces from various includes. So far, only
prefixes seem to answer that question. If prefixes are required there, then
there seems to be little problem in using them elsewhere. I'm open to
ideas...and I hope RDS is too...if we out here can come up with a
common set of proposals.
>> And I shouldn't accuse. I share some of Jiri's irritation with
>> the "way" that the libs you have written are headed ...
>
>I assume by 'the "way"', you are referring to GUI applications, as opposed
>to DOS applications. Jiri's complaints seem to be less that I'm writing GUI
>code, and more that a "DOS" forum is constantly polluted with Windows code.
>
>
>> but I also recognize that this language would be sitting
>> virtually unused if it wasn't for that very work.
>
>Looking at the huge number of DOS contributions on the Euphoria web page,
>I'd have to disagree.
I meant at the Windows application level. DOS is a self-limiting environment.
>> I'm not quite as irritable as Jiri, but after the third demand
>> for code I got a little crotchety.
I can't speak for Jiri, but one thing that we appear to share in common is
the inability to make it clear when we are passing out a back-handed
compliment.
>But I don't think it's an unreasonable demand. If you can't show me an
>example of code that demonstrates your claim, then it's difficult for me to
>believe there's an issue.
If the lengths to which you have gone in the code samples above is not
evidence of an issue, what poor samples that I would be capable of at
this point would suffice? You appear to be in the mode that I have spoken
of before..."to the man with a hammer, everything looks like a nail". You
have chosen to view everything from the position of existing coding
capabilities. I find what you have done above to be an elegant, but
questionably useful method of trying to get around a major hole in the
language. It works for you, but is not particularly intuitive or flexible IMO.
That is not a knock on you or your coding techniques. It merely shows
that one of the best coders in Euphoria still can't get past the inherent
problems.
>> but I have not seen much generic string
>> handling done in your programs...
>
>I'm not sure what you mean by 'generic string handling'. I've posted several
>programs with fairly complex parsers. eBasic converts QBasic code into
>Euphoria using an LL(1) grammar. PP is a pre-processor for Euphoria that
>'enhances' the language with a number of interesting constructs. Eu parses
>and executes Euphoria code. On a smaller scale, Fix functions much the same
>as Euphoria's Shroud routine, but correctly handles routine_id, and Res
>creates resource files by parsing source files. I've posted a couple generic
>pattern matching routines as well.
>
>-- David Cuny
I thought that I specifically excluded source code as generic text because of
it's inherently deterministic structure and grammar. Not that any of those
are easy or unimportant. They just don't represent generic text as symbol
system for spoken or written language, a particularly non-deterministic
grammar and structure. I will, however, look at those for further instruction.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
