<egg|egg>
they have a specific rule for the association that's in a parameter
<egg|egg>
whereas in your grammar they shove that onto the rule for any association and have fun with that
<egg|egg>
and that can have types, since it can be a generic
<rqou>
hrm i think types must be used for "generic maps"
<rqou>
because vhdl isn't that hipster to have first-class types :P
<egg|egg>
rqou: in Ada genericity is at the package or subprogram level
<rqou>
yeah similar in vhdl i think
<egg|egg>
so if you want a generic type, you shove it in a generic package
<rqou>
it's not like python where you can manipulate metaclasses (type objects)
<rqou>
or some even more abstract and functional languages
azonenberg_work has quit [Ping timeout: 240 seconds]
<egg|egg>
so you'd have a generic package Generic_Skip_Lists with a type Skip_List in it, and instantiate your generic as Cat_Skip_Lists and use Cat_Skip_Lists.Skip_List.
<egg|egg>
it's a bit clumsy
<rqou>
ZOMG they made infinite lookahead unnecessary:
<rqou>
"Named associations can be given in any order, but if both positional and named associations appear in the
<rqou>
same association list, then all positional associations shall occur first at their normal position. Hence once a
<egg|egg>
but hey, they had generics quite early
<rqou>
named association is used, the rest of the association list shall use only named associations."
<egg|egg>
yes, same in Ada
<egg|egg>
rqou: but that's not for parsing reasons
<rqou>
no php-esque "you can mix them however you like, but it won't make sense afterwards" :P
<egg|egg>
rqou: that's because how the hell would that make s--- yeah
<rqou>
yeah herp derp this doesn't trip up an LR parser anyways
<rqou>
it can only trip up an LL parser
<rqou>
(this doesn't fix the "doesn't make much sense" problem :P )
<rqou>
wait so if i'm reading it right the "function call in the formal_part" is only allowed for port/generics
<rqou>
not functions
<rqou>
because how the heck would that work?
<egg|egg>
I have no idea what a port is, because obviously that's not a thing in Ada :-p
<rqou>
yeah obviously
<egg|egg>
same when it comes to the grammar of signals :D
<rqou>
who the heck decided that "smush as many ebnf rules together as you can" was a good idea?
<egg|egg>
rqou: the thing is it makes it usefully readable to write code
<rqou>
except where it doesn't
<egg|egg>
back when I wrote Ada I'd get errors pointing me to the RM, and I'd look at that and see task_name and understand what was going on
<rqou>
e.g. association_list
<egg|egg>
whereas if I go digging in the C++ standard's BNF I vomit, and then I cry
<egg|egg>
the declarator syntax is always horrifying
<egg|egg>
rqou: but association_list isn't a thing in Ada :-p
<rqou>
so i normally love to mock java for things like AbstractSingletonProxyFactoryBean, but VHDL has things like "interface package generic map aspect"
<egg|egg>
you have actual_parameter_part which is a bunch of parameter_association which are [formal_parameter_selector_name =>] explicit_actual_parameter
<rqou>
i guess "giant word jumble" isn't unique to java :P
<egg|egg>
rqou: that's nonsense in Ada, but Ada does have its own keyword strings
<rqou>
no, this isn't a keyword string
<rqou>
it's a name of a particular thing in the spec
<egg|egg>
oh
<egg|egg>
welp.
<rqou>
"An association list, other than one appearing in an interface package generic map aspect (see 6.5.5), ..."
<egg|egg>
type T is not null access protected function return Integer yields the longest keyword string in Ada 2005 iirc
<egg|egg>
maybe you can return an anonymous access and just loop that arbitrarily
<rqou>
unfortunately, unlike AbstractSingletonProxyFactoryBean, i actually have to deal with it in this case :P
<whitequark>
I think the part I like most about ASPFB is the documentation
<whitequark>
>Convenient proxy factory bean superclass for proxy factory beans that create only singletons.
<whitequark>
CONVENIENT
<rqou>
from HN: "My favorite part is that the first word is 'convenient.' At the point that you need this class, absolutely nothing about the situation could possibly be considered 'convenient.'"
<cr1901_modern>
GoF was a mistake
<whitequark>
nah, Java-the-language was (though it was still not that bad compared to contemporaries)
<whitequark>
you can have singletons, abstract classes and factories in rust
<whitequark>
you don't need to call them that, no one does!
<whitequark>
std::sync::mpsc::channel() is a factory.
<whitequark>
but you don't have to put it into a ChannelFactory.
<rqou>
i mean, my housemate and I love to joke about how not to do java inheritance: IPlantable -> AbstractFruit -> {Apple, Banana, Rice} :P
<rqou>
and Rice inherits from AbstractFruit to get the plant() method :P :P
<cr1901_modern>
are trait objects analogous to abstract classes?
<rqou>
somewhat?
<rqou>
they don't tend to turn into "random bags of shit" the way java abstract classes do
<whitequark>
rqou: wat
<whitequark>
can't it just inherit IPlantable
<whitequark>
cr1901_modern: trait objects are exactly the same thing as abstract classes
<whitequark>
well, no, traits
<whitequark>
trait objects are slightly different
<rqou>
the joke was that IPlantable got added later :P
<cr1901_modern>
The dynamic dispatch property was why I associated trait objects w/ abstract classes, but I might be confusing myself.
<cr1901_modern>
(what were you going to say, btw?)
<rqou>
whitequark: one way to fix the joke is to claim that some external module relies on receiving an AbstractFruit and can't be changed to receive an IPlantable instead :P
<whitequark>
cr1901_modern: abstract classes are useful even without dynamic dispatch
<whitequark>
because you can use them in bounds
<whitequark>
Foo<? extends IPlantable>
<rqou>
^ this
<whitequark>
well, java doesn't really have static dispatch
<whitequark>
but you get hte idea
<rqou>
also, as i understand it, in rust as long as you implement all the right methods you automatically will satisfy a trait bounds
<rqou>
you don't have to retrofit the IPlantable back onto the original type declaration
<whitequark>
rqou: no
<whitequark>
that might have been true in extremely old rust
<whitequark>
but no, traits are nominal today
<rqou>
hrm, you're right
<whitequark>
this is partly because traits can be parameterized
<rqou>
you have to specify which trait you're implementing
<cr1901_modern>
whitequark: I see. Cool!
<whitequark>
so in an impl<T> Foo<T> for Bar<T> { .. }
<rqou>
but you still don't have to change the original declaration for Bar
<whitequark>
you first abstract a new type variable T then use it twice
<whitequark>
also, marker traits are a thing
<whitequark>
impl Copy for T {}
<rqou>
right, but you can still "add on" traits to a type that you didn't originally write
<whitequark>
yes, coherence
<rqou>
unlike in java where this is extremely difficult
<whitequark>
it's limited
<whitequark>
you can't add traits you didn't write to a type you didn't write
<whitequark>
because someone else could have done that but differently
<rqou>
right, my housemate was telling me about that
<rqou>
and how not limiting it leads to exciting footguns
<whitequark>
haskell has hilarious coherence rules
<whitequark>
because all typeclasses are in scope all the time
<cr1901_modern>
Not sure this is good form in Rust, but I used dynamic dispatch in my first Rust app so that I could have a single new() function return a trait object implementing a trait T I use throughout the rest of my program. >>
<cr1901_modern>
I wonder if I could've done the same thing w/ static dispatch...
<rqou>
what's the deal with certain (older?) languages that have a distinction between "functions" and "procedures?"
<cr1901_modern>
Distinguish ref-transparent (i.e. the ones you study in precalc) functions from non-ref-transparent functions?
<cr1901_modern>
Just a guess
<rqou>
nope, pure/impure is an additional marker in VHDL
<rqou>
wait wtf
<rqou>
VHDL actually has a much more important distinction
<rqou>
"For those parameters with modes, the only modes that are allowed for formal parameters of a procedure are
<rqou>
in, inout, and out. If the mode is in and no object class is explicitly specified, constant is assumed. If the
<rqou>
mode is inout or out, and no object class is explicitly specified, variable is assumed.
<rqou>
For those parameters with modes, the only mode that is allowed for formal parameters of a function is the
<rqou>
mode in (whether this mode is specified explicitly or implicitly). The object class shall be constant, signal,
<rqou>
or file. If no object class is explicitly given, constant is assumed."
<rqou>
procedures can actually modify their arguments. functions can't
<cr1901_modern>
So it's like fortran then IIRC
<cr1901_modern>
and yea, not modifying input args wouldn't be a guarantee of ref-transparency, now that I think about it
<rqou>
egg|egg: in Ada can a function call look like "foo(type_conv_a(aaa) => type_conv_b(bbb))" ?
<egg|egg>
uuuuuuh what the hell would that mean
<rqou>
so in VHDL if you do this in a procedure (not a function)
<rqou>
it means that type_conv_b will be applied to bbb before passing the argument into the procedure
<rqou>
and if the procedure modifies it, type_conv_a will be applied to convert it back
<egg|egg>
the thing on the left is a selector_name in Ada, so selector_name ::= identifier | character_literal | operator_symbol
<egg|egg>
; and it's a formal_parameter_selector_name so probably it can't be a character literal?
<rqou>
hrm, so VHDL is totally different here
<egg|egg>
yeah, you can't specify conversions to an in out parameter
<rqou>
VHDL does specify that parameters to a function (not a procedure) can only be mode in (not out or inout)
<rqou>
and signals cannot have this type conversion at all
<egg|egg>
right, that's true in Ada until 2012
<egg|egg>
and stupid
<rqou>
however, it seems to me that even if type_conv_a can never get used (mode in) you can still have one
<egg|egg>
because to paraphrase somebody whom I forgot, functions can modify anything they want as long as they don't document it
<egg|egg>
(you don't have pure functions)
<egg|egg>
now Green did
<rqou>
VHDL does have a "pure" marker on functions
<egg|egg>
Green had procedures with return types
<egg|egg>
and functions, which were pure
<egg|egg>
procedures could have in out parameters
<egg|egg>
somehow that got lost
<rqou>
so apparently function args in vhdl can be constants, variables, signals, or files
<rqou>
signals and files cannot have conversion functions
* egg|egg
hides
<rqou>
but constants and variables can?
* egg|egg
should sleep too
egg|egg is now known as egg|zzz|egg
<rqou>
having one in the actual_part doesn't matter too much
<rqou>
but can you somehow have one in the formal_part?
<rqou>
even though it can't get used?
digshadow has quit [Quit: Leaving.]
aptyp_ has joined ##openfpga
aptyp_ has left ##openfpga ["Konversation terminated!"]
eduardo_ has quit [Quit: Ex-Chat]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
amclain has quit [Quit: Leaving]
_whitelogger has joined ##openfpga
digshadow has joined ##openfpga
eduardo has joined ##openfpga
Hootch has joined ##openfpga
_whitelogger has joined ##openfpga
pie__ has quit [Quit: Leaving]
Hootch has quit [Ping timeout: 260 seconds]
Hootch has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
promach has joined ##openfpga
digshadow has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
promach has quit [Ping timeout: 258 seconds]
promach has joined ##openfpga
promach has quit [Ping timeout: 258 seconds]
Toastbomb has joined ##openfpga
zino has quit [Remote host closed the connection]
digshadow has quit [Quit: Leaving.]
Toastbomb has quit [Ping timeout: 240 seconds]
zino has joined ##openfpga
Hootch has quit [Read error: Connection reset by peer]